Imagine an ordinary meeting at work.
“I need a ‘Prepare Proposal’ button,” the commercial director explains. “The salesperson clicks it, gets a document, sends it to the customer. How hard can that be?” Forty minutes later, he knows all about the company's complicated architecture, legacy constraints, and a team overloaded with some kind of technical debt. The button, of course, has not materialized. But at least it is now much clearer why its absence is the result of serious, painstaking work.
To be fair, the technical team is right. Prices live in one system, discounts in another, inventory updates arrive late, and special terms for important clients exist mainly in the head of Sergey, the account manager. Ah yes, Sergey... He is on vacation, which means part of the corporate knowledge base is temporarily unavailable. To produce a correct proposal, someone will have to collect, connect, and verify all of this. And let's not forget Sergey: a brave soul will eventually have to dismantle that tower of knowledge. All this even if drawing the actual rectangle on the screen really would take five minutes.
That evening, the director opens an AI tool, describes the same idea, and attaches a screenshot of the application. He gets a mock-up, asks to rearrange the fields, add a comparison of options, then remove half of what has just been added. “No, actually, put it back the way it was. Just not exactly like that.” Have you noticed that you can type something as vague as “do it differently” or “not like that,” and sometimes that is enough? The model keeps revising. Gradually it turns out that what he needs is not a button at all, but a small assistant for the sales team. Nobody sighs heavily into their microphone, rolls their eyes over a raf coffee made with alternative milk, or reminds him that yesterday's requirements were different.
It would be easy to announce a glorious victory for AI over slow software development. I won't, though; that would make for a rather short article. Seriously, the engineers were explaining how to build a working system, while the model helped show what the system might look like. It is still too early to sell anything at the prices in the mock-up: the special terms are still with Sergey, and Sergey is still enjoying his holiday. But the director has achieved something important. He has tried an idea, seen it, and clarified what he actually wants without organizing a small production process around it.
AI did the job of a good presales specialist.
I think this is where business starts to fall in love with AI. Sometimes a manager needs to see what an idea could become before being able to explain it convincingly enough to get permission to see it. Not every half-formed idea deserves a project. But not every idea should have to compete for the right to enter the backlog, either.
The interest among Russian companies is visible in research, too. In a 2025 study by Yakov & Partners and Yandex, 71% of respondents reported using generative AI in at least one business function. That tells us something about adoption among the study participants. It does not tell us anything about profit.
Because there can be an enormous gap between “we implemented it” and “we made money from it.” That's what I want to look at next.
Business Buys the Right to Change Its Mind Without Writing a Memo
Suppose a team spends a week preparing a solution. On Friday, the customer takes a look and says, “Now I understand what I need.” You can generally tell from the team's faces just how delighted they are by this intellectual breakthrough. Formally, the requirements have changed. In practice, the work needs to be redone, deadlines moved, and someone has to explain why none of this could have been figured out on Monday.
This is why preliminary analysis, prototyping, and agreement on requirements have a very clear economic purpose: they stop expensive work from starting before there is enough clarity. But sometimes the customer genuinely cannot formulate the answer in advance. They need to see an option to understand why it is wrong. “Show me something and I'll tell you what's wrong with it” is irritating for the person doing the work, but it can be a fairly accurate description of how a business forms its view.
With AI, some of this exploration can happen before full implementation. You can try several mock-ups, compare scenarios, draft a calculation, and discover that the idea does not deserve to go any further. It is easier to throw away a bad option while little time has been spent on it and nobody has yet presented it as a strategic initiative. After that, a simple “we tried it; it didn't work” may require an explanation strategy all of its own.
For me, the most important part is being able to find out more cheaply what is actually worth doing. When the first attempt is easy to undo, it is easier for the customer to admit they were wrong and for the team not to defend work just because it has already been done. But the boundaries of the experiment need to be very real: changing your mind about a mock-up and changing your mind after revising the terms of thousands of contracts are two very different expense items. AI can make it cheaper to test a hypothesis. It does not have to make the consequences of acting on that hypothesis cheap.
Can You Buy 0.07 of a Specialist?
Small businesses periodically need expertise that does not justify creating a full-time position. Today someone needs to sort out some data, tomorrow analyze sales, and next week build a small internal tool. There is not enough work for a permanent hire, but there is more than enough to keep something regularly stuck without that expertise.
Consultants and hourly billing existed long before neural networks. But you still have to find the person, explain the task, and transfer the context. “It's literally half an hour's work,” says the customer. Two meetings later, everyone has figured out where to look — and that they need a different specialist. Nobody was sitting idle, but the price of that half-hour has grown considerably.
AI can perform some of this work without a separate hire: produce an initial analysis, prepare a draft, test a few assumptions. Access to certain capabilities becomes more granular, and you can adjust how much you use the tool to what you actually need. Today you need it all day, tomorrow for twenty minutes, and the day after not at all. There is no need to invent a new job title for it because last week's project ended. Naturally, the cost of reviewing and maintaining the results may not scale quite as neatly.
This is where it becomes particularly tempting to compare a specialist's salary with the price of a subscription and rush off to get the savings approved. I would first calculate who will check the output, correct mistakes, connect the data sources, and keep the solution running. A subscription does not include professional accountability, and the person who provides that accountability usually expects a salary, too. The financial model becomes less festive after this adjustment, but considerably more useful.
For a manager, the interesting opportunity is to combine permanent staff with on-demand tools in a different way. People can focus on work that requires knowledge of the business, independent judgment, and responsibility, while preparatory tasks become cheaper. But first you have to understand what the result is actually made of. An organization chart alone makes it difficult to see which activities you can hand over to a tool and which ones depend on an individual person's experience.
AI Works Around the Clock. The Committee Meets on Thursdays.
Take a hypothetical sales proposal. Preparing the document takes four working hours; collecting information and waiting for approvals takes another thirty-six. The total cycle is forty hours. Now suppose AI reduces the drafting time to half an hour, while everything else stays exactly the same.
At the next management meeting, you can say with complete honesty that the task became eight times faster. The only catch is that the customer will receive the proposal after 36.5 hours instead of 40. The entire cycle has improved by roughly 9%. That may still be useful, but the customer is unlikely to share all our technological excitement. They never saw the demo. They were simply waiting for their proposal.
To get a bigger effect, you have to deal with the remaining time. Why is the salesperson waiting for the latest price list? Why must the director approve every standard discount? Which checks could run in parallel? Why do people ask a colleague for information that the colleague simply retrieves from a system available to everyone? At that point, the neural network may no longer be the main character in the transformation, which makes life a little harder for those who believe every problem can be solved by purchasing another technology.
What's more, speeding up one step can increase the queue at the next one. If analysts used to prepare five reports a week and can now produce twenty, their manager does not suddenly acquire the ability to make decisions four times faster. The pile of unread documents just gets bigger. Of course, we could add another AI to summarize the first one's documents, then a third to extract the key points from the summaries. At some point, though, it might be worth finding out what decision we were planning to make.
That is why I would separate two questions: what became cheaper to produce, and what could the company actually do as a result? If proposals start reaching customers sooner and deals stop being lost to delays, the connection is clear. If documents are now prepared faster but sit in the same queue, the tool is already useful, but the business benefit is still waiting to happen. The bottleneck has moved, and that is where the manager's next job begins.
AI Can Help You Be Wrong — Very Convincingly
Imagine a manager planning to launch a new service and asking a model to produce the business case. A tidy document appears: target audience, benefits, launch stages, expected results. “Yes, that's more or less what I had in mind,” thinks the manager. Their confidence grows with every paragraph, even though what has mainly been tested so far is the tool's ability to expand on the idea it was given.
This is when someone who is prepared to ruin a perfectly nice meeting can be quite useful. Why do we think customers need this? Who will deliver what we're promising? What happens to our existing service commitments? Could we solve the problem without a new product, department, or IT system? Such a specialist is less pleasant to talk to than the model, but they help stop an elegant justification from being confused with a tested hypothesis. They may be invited to fewer meetings afterwards, of course, but that says more about the quality of management than the quality of the specialist.
You can use the model to challenge ideas, too. But checking assumptions needs to be a separate part of the work, with clear criteria — not just a hope that the person doing the task will independently discover everything the requester forgot to mention. If the special terms for a customer are known only to Sergey, asking the model to “think like the world's best commercial director” will not replace a conversation with Sergey. It certainly looks more impressive in the chat history, though.
A useful example is a 2023 experiment involving 758 BCG consultants. On tasks that fell within the capabilities of the GPT-4 model used, participants working with AI were faster and received higher quality scores. On another deliberately selected task, the share of correct answers among those using AI was 19 percentage points lower. This is the result of a particular experiment, not an assessment of every model available today. But it shows why a tool needs to be tested on the actual work you plan to give it.
My management conclusion is simple: the easier it becomes to produce convincing answers, the more important it is to organize their verification. The reviewer needs knowledge, time, and the authority to stop a launch. If someone hands them fifty pages ten minutes before submission and says, “Just have a quick look and make sure it's all fine,” human oversight exists mainly in the policy document. In practice, the company has only decided whose name will appear under the result.
What Managers Need to Change Besides the Model Version
I would start with one repeatable process and a few very specific decisions. These are harder to show off with a spectacular AI prompt, but they make it possible to understand what the company actually wants to achieve and who will have to do some work to make that happen. Our sales proposal is a good example: there is a customer, a deadline, mistakes, and money involved. That gives us something to improve beyond the impression left by a demo.
Start with the Queue, Not the Purchase of Licenses
“Introduce AI into sales” is a wonderfully broad instruction: you could spend years successfully organizing activities under that banner. It is more useful to follow the path from a customer request to a sent, approved proposal and look at several dozen recent cases. How long did the work take? How much time was spent waiting? Where did things go back for revision, and which errors had to be corrected? Don't settle for “we're usually pretty fast.” First agree on how this “usually” is going to be measured.
The result should be a simple diagram showing working time and waiting time at each stage. A proposal completed in two hours and one completed in ten days may have gone through formally the same process. Find out what happened in the second case: was information missing, were special terms needed, or did an email simply get lost between participants? Those problems require different solutions, even if they all end up in the same attractive average.
If most of the delay comes from finding current prices, start with prices. A company is entirely entitled to solve the problem without a neural network, even if the project has already been christened “Intelligent Sales 2030.” Renaming a presentation is usually cheaper than deploying a tool in the wrong place and then heroically proving why it was necessary.
Check Whether the Work You Want to Accelerate Needs Doing at All
Before automating each step, I would ask: what would happen if we stopped doing it? Maybe a weekly report has been carefully prepared and circulated for years, but when someone asks, “What decision did you make based on it last time?”, a small silence follows. Perhaps the report should be less frequent, sent to a different person, or presented differently. The time to speed up its production is after that conversation, not instead of it.
In our example, the company could approve a range of standard commercial terms in advance and send only exceptions for separate review. AI can help prepare the proposal, while a change in the rules means nobody has to wait for the director's signature on every standard deal. A substantial part of the benefit comes from a decision about authority, not a better prompt.
But first, it is worth understanding why the old restriction exists. Some checks genuinely protect money, customers, and system stability. Others may be leftovers from a story no one remembers except the person who wrote the policy, and they've changed jobs three times since. Neither the age of a rule nor employees' irritation proves whether it is useful. It needs to be examined, not swept away in another campaign to “remove all bureaucracy.”
Appoint an Owner Who Is Actually Allowed to Change Something
The project needs one person accountable for the whole process, not just for connecting a new tool. In our example, that means responsibility for the timing and quality of the proposal the customer receives. The owner needs the authority to negotiate changes with sales, finance, and IT. Otherwise, you create a familiar job title: person responsible for the outcome, with permission to send follow-up reminders.
Define in advance which decisions this person can make independently, which ones require escalation, and who will resolve conflicts. “Work it out among yourselves” sounds like delegation right up to the point where the parties have incompatible priorities and neither has the authority to change them. If everybody can reject a change but nobody owns the total delay, the new technology will simply receive detailed instructions for serving the old way of working.
Agree on life after the pilot, too: who updates the rules, monitors quality, handles exceptions, and pays for support? Name people and allocate time, not just departments. “We'll figure it out after launch” means the launch has been designed more carefully than what happens next. The vendor will deliver, the working group will disband, and customer requests will, for some inexplicable reason, keep arriving.
Separate the Right to Prepare from the Right to Act
Drafting an email, sending it to a customer, and changing the terms of a deal are different levels of authority. The fact that technically they may all be one button apart does not make them equivalent tasks. Before a pilot, decide which data the tool may access, which sources are current, and which actions it may take without asking permission. That is easier than discussing it after a customer has happily accepted terms the company never intended to offer.
Prices and discounts should come from approved sources, and calculations are worth checking separately from how convincing the prose sounds. Initially, you can leave the actual sending to a human. I would increase the system's independence based on test results, not on the confidence with which it answers. Critical actions need logging and a clear way to stop or reverse an operation.
You also have to assemble the context: current rules, exceptions, constraints, and who is responsible for disputed cases. You do not have to document the entire company down to the last office kettle, but the information needed for this particular process has to be put in order. If a folder contains “Price_Final,” “Price_New,” and “Send_This_One,” the model should not have to guess which file survived the last meeting. Neither should a human, for that matter.
Explain What the Saved Hours Will Turn Into
Before launch, agree on what the savings are supposed to achieve. Will salespeople handle more requests? Will the team absorb growth without additional hiring? Will overtime, contractor spending, or lost deals decrease? Those are different objectives. “Our people will become more productive” is a nice thing to say, but not very useful when it comes to verifying the result.
Released time should not automatically be booked as a cost reduction. Twenty minutes saved for each of thirty employees makes ten hours in total, but it does not create one person who is free for ten hours. You may have to reassign work to make use of that capacity. Otherwise, the savings appear in a report while the person you plan to give extra work to is still completely busy.
It is worth talking to employees in advance, too. If a rollout begins with a cheerful presentation about how many people will soon no longer be needed, expecting open knowledge-sharing is rather optimistic. You don't have to promise that no role will ever change. You do have to explain which tasks are going away, what people will need to learn, and how their work will now be evaluated. Otherwise Sergey may come back from vacation, look at the presentation, and suddenly discover that documenting all the exceptions he knows is an extraordinarily complex task requiring several years of thoughtful work, right up to retirement.
Allow the Pilot to Fail
Set the criteria for success before the experiment. For example, the end-to-end time to handle a request should fall without unacceptable loss of quality, and the cost of an accepted result should include model usage, review, corrections, integrations, and ongoing support. It is better to agree on this before showing management a slide with the victory already drawn on it. After that slide, the conversation can quietly change from “What did we learn?” to “What should we call the result so that it counts as success?”
Test ordinary work, including the awkward cases. Three carefully chosen successful examples mainly prove that someone can select three good examples. If an experienced employee spends evenings correcting AI output, their work belongs in the calculation, too. “It runs automatically, Marina just checks it a little afterwards” becomes an especially interesting sentence if you ask Marina how long “a little” actually takes.
Three outcomes must be allowed: expand the use, change the approach, or stop. A pilot that cannot be shut down because of promises already made is no longer an experiment. The company has started defending a previous decision instead of testing a new tool, and by then the technology has very little to do with it.
If the experiment shows that reviewing the output consumes all the time saved, that is useful information. You can narrow the use case, change the process, or abandon the deployment. Part of the pilot budget was spent so you could learn this before scaling. It is much worse to discover the same problem after the whole company is connected and the date of the celebratory results presentation is already in the calendar.
Sometimes the Bottleneck Is Closer Than It Looks
Business has good reasons to love AI: it helps people try ideas faster, change their minds more cheaply, and get some work done without mounting a separate expedition to find every specialist they need. But technology will not decide for the manager which steps are unnecessary, who can be trusted with decisions, or how the time freed up should be used. That management work determines whether the acceleration remains a nice little episode or actually changes the company's result.
I would assess an AI initiative by how it changes the whole journey from a need to a useful outcome. Perhaps the next stage really does need a more capable model. Perhaps the data needs cleaning up, or people need to work differently. And sometimes it turns out the proposal has been ready for ten minutes and is now spending the next three days waiting for the signature of the person who approved the automation budget.
And there is the treasure. Sure, you can fire all the junior engineers and cut the analysts — quick savings. Just make sure there is still someone who can review the AI's work.
Sound familiar? Of course: assembly lines, Kanban, and muda.
By the way, they did build the button in the end. It works, proposals get assembled, and Sergey no longer has to be involved in every standard deal. He's doing fine, though. He has moved on to developing tiered client discounts based on a whole range of parameters. AI suggested some of those parameters, which made him very happy. After all, AI is the world's accumulated experience in a single prompt.
Just think about it: the whole world's experience answering your question. No kidding.
Now we only need to work out why the next meeting still features the words, “Colleagues, we need to move faster.” It may well be the person whose signature everybody is waiting for. They will have to change something, too — and this time it won't be the subscription plan.