Process automation

How to bring AI into real business processes

Aleksandr Lukashevich August 1, 2026

Everyone is writing about AI in business right now. The problem is that it's mostly about demos: someone built a bot over the weekend, it answered three questions, looks great. Then the real work begins, and nobody writes about it, because it isn't pretty.

I've been down this road with my own product and with clients. Below is what actually happens between "let's bring in AI" and "it works and makes money". No promises that you'll cut costs in half in a month.

How many businesses have already adopted AI, and how many got burned

The numbers look impressive, but only as long as you look at the first one.

Here's how to read this: almost everyone adopted it, almost no one turned it into money. And it's important not to conclude "so AI doesn't work". It does. It's just that what lies between "we tried it" and "it shows up in the report" isn't technology, it's ordinary, boring work on processes.

Why a pilot never makes it to production

A pilot lives in a greenhouse: one channel, ten examples, and someone sitting next to it to fix things. Production is when a client messages you at night in a messenger that wasn't in the tests, about an order that isn't in the database.

Here's what kills projects most often:

• No source of truth. The model answers nicely, but not with what's written in your guidelines. A week later someone gets an answer that contradicts the delivery terms, and the project gets shut down.
• No one to hand a hard case to. If the AI has no clear way to say "I'm not sure, get a person", it will lie confidently.
• The pilot isn't connected to your systems. There's an answer, but nothing shows up in the CRM. So a manager still does the work, only now they're duplicating it too.
• Nobody measured the "before". Three months later it's impossible to prove things got better, because nobody knows what they were like.

None of these points is about the model. All four are about the process around it.

Don't start with AI

The most common opening line: "we need an AI assistant". The most useful first step: look at what's actually happening in your systems.

We did this kind of audit for a client, a print products manufacturer. We connected to their live Bitrix24 and counted. The result was unpleasant and very clear:

• 87.7% of deals were marked "in progress" but hadn't moved for months;
• 7,490 times managers manually created a "contact the client" task for themselves;
• 53% of deals had no source, meaning nobody knew which ads brought in the money.

None of these numbers needs AI to be seen. But they're exactly what shows where to put it. Seven and a half thousand identical manual tasks isn't "there's some routine somewhere". It's a specific amount of work with a clear price.

What turned up in someone else's CRM

An audit breakdown: which numbers came up, what was automated first and what came of it in five weeks.

Read the breakdown

Three processes to automate first

Don't start with the hardest. Start with the most repetitive.

1. Receiving and sorting incoming messages

Messages come in from messengers, email, website forms. The first thing worth doing is to bring them into one queue and learn to understand, before replying, who wrote, about what and how urgent it is. These aren't auto-replies yet. It's just order, and that alone saves people hours.

2. Answers to standard questions

"Where's my order", "how do I upload my layout", "what are the delivery terms". The key rule: no confirmed source, no auto-reply. Five to ten scenarios, each with its own document in the knowledge base. Everything else goes to a person.

3. Routine actions in your systems

Set a task, fill in the source, close a stalled deal, follow up with a client who's been silent for three weeks. Boring, mechanical, thousands of times a year. The perfect candidate.

Vibe coding: why "we'll build it ourselves over the weekend" doesn't work

According to Stack Overflow, the vast majority of developers, around 84%, use or plan to use AI tools. At the same time, their trust in the accuracy of the output is dropping: almost half say they don't trust it.

I'll be honest, from my own experience. I can code. I spent a month working fourteen hours a day, tried a dozen vibe-coding approaches and still couldn't build a production-ready product on my own. A team of four experienced developers did it in a month and a half.

Vibe coding is great at building a prototype and bad at building a system that will survive five hundred requests a week.

The takeaway isn't "don't use it". It's this: use it where the cost of a mistake is low, like prototypes, internal tools, testing ideas. Where a mistake reaches a client, you need a proper engineering setup: tests, monitoring, rollback, a queue.

What breaks when you have too many tools

A typical picture after six months of experiments: a Telegram bot from one contractor, a website chat from another, a spreadsheet with the knowledge base, a separate mailing service and a CRM that knows nothing about any of it.

Each tool works on its own. Things break at the seams:

• a client wrote in two channels and became two different people in the database;
• the bot promised a discount, and the manager doesn't know about it;
• there's a reply, but no task in the CRM;
• nobody can say how many requests you handled in a week at all.

This isn't an argument for "buy one big system". It's an argument for having one place where the whole client journey is visible. When receiving messages, the knowledge base, CRM actions and handover to a person all live in one setup, there are simply no seams left, and nothing to break.

Where data and accounts actually get lost

People rarely ask about this, but they get caught by it regularly.

Data leaks through prompts

There are no public statistics on "how many companies lost data because of AI". Nobody publishes reports like that about themselves. But there are high-profile cases: employees paste pieces of internal code and documents into a chatbot, and it ends up outside. The best known is the Samsung source code leak, after which the company banned employees from using public chatbots.

The fix isn't bans, it's engineering: sensitive data is masked before it reaches an external model, inside your own setup. Phone numbers, documents, bank details shouldn't leave the perimeter in plain form.

Accounts get banned for automation

There's no honest number here either, and anyone who quotes one most likely made it up. But here's a fact: Instagram and WhatsApp rules directly restrict automated messaging, and getting a business account blocked is a very real outcome. You need to work through official APIs, not through gray-area workarounds, however cheap they might seem.

How to measure results

The main rule: measure before you start. Not later, not "once it's working". Now. Otherwise in three months you won't be able to tell the effect of automation from seasonality.

A minimal set that works in almost any business:

• Share of requests closed without a person. The main number. It directly answers the question "how much work was taken off us".
• Average time to first reply. The one clients notice most.
• Volume of manual actions, those very tasks that get created by hand.
• Share of unlabeled data: deals with no source, clients with no phone number. Shows whether you're fixing the cause, not the symptom.

And track this week by week, not as one number at the end. For the client I mentioned above, the share of automatic closures went from 7.5% to 51.8% in five weeks. But it only looks good on a weekly chart. A single "it's now 52%" won't show you the dip in week two, or the moment when everything started going up.

In short

• Almost everyone adopted AI, almost no one turned it into money, and it's not about the models.
• Start with an audit, not with AI: the numbers will show you where the routine is.
• The first things to automate are incoming messages, standard answers and mechanical actions in your systems.
• No confirmed source, no auto-reply.
• Vibe coding is good for a prototype and bad for production.
• The fewer seams between tools, the fewer places where things will break.
• Measuring the "before" is a must. Without it you'll have nothing to prove.