Business Process Mapping
An AI assistant bought for an entire department does not speed up the process, because most of the process time sits in queues and handoffs between people, not in the work itself. The assistant cuts touch time (the time someone is actually working on a task) and leaves elapsed time (time from task start to finish, including waiting) untouched. To see where those queues are, you need three to four weeks to map the real process: not the one described in the procedure manual, but the one that actually runs inside the systems of record. Then every step gets one label from four buckets: delete, code, agent, human. Only after that does agent assembly begin, and a significant share of the effect comes from the reassembly, not from AI.
Why an assistant on top of an old process speeds up a bad process
Michael Hammer, in Harvard Business Review, July-August 1990, cited figures from an insurer: an application spent 22 days in process, and the actual work on it was 17 minutes. If you halve the time of every working step, you save about 8.5 minutes out of 17 minutes of work, and the 22 days of waiting remain. This arithmetic comes from Vas, CEO of Varick Agents, whose cases follow below, applied to Hammer's data. Hammer stated the conclusion plainly: companies invest in technology to automate old ways of working and leave the process untouched, merely accelerating it. "It is time to stop paving the cow paths," he wrote.
What changed since then, and what stayed the same, is shown by the UK Department for Business and Trade evaluation report on the Microsoft 365 Copilot pilot, published September 2025. The pilot ran from October to December 2024 with 1,000 licenses issued. The three-month average was 72 assistant actions per user, that is 1.14 actions per working day across 63 working days. 72% of users were satisfied or very satisfied. The report concludes: "We did not find robust evidence to suggest that time savings are leading to improved productivity." The authors caveat: measuring productivity was not the primary goal of the evaluation. Our reading of these figures: the problem is not speed within a step, but how many steps exist and how many handoffs between people sit between them.
Xiaoyin Qu, founder of Agentsky, in an X post of October 5, 2026, added an observation: existing corporate processes are designed around people, not agents; implementation engineers automate the status quo because it is easy to sell. Qu qualifies that he does not consider himself an expert on the topic, but the mechanics are clear: an agent embedded inside a step speeds up that step, while the loops and handoffs between people remain.
Hammer in the same 1990 article told the story of Mutual Benefit Life, the 18th-largest life insurer in the US. Before reengineering, the process included up to 30 steps, 5 departments, 19 people, a cycle of 5 to 25 days, most of it spent passing paperwork between departments. After reengineering around one case manager with an expert system, the minimum cycle became 4 hours, the average 2 to 5 days, and throughput more than doubled. None of these versions included an "AI assistant for every employee." There was a process reassembly, and that is what produced the effect.
How to find the real process in three to four weeks
According to Vas, CEO of Varick Agents, in the Startup Ideas Podcast write-up of October 1, 2026, a public software company with $5 billion revenue and more than 150 products had its previous consulting project describe the proposal preparation process as 7 steps: gather, send, deal desk, approve, send to client, negotiate, sign. Process mining, the analysis of action logs in systems of record that shows how the process actually runs, found 20 steps and 7 loops. 61% of requests were sent back to an early step, lawyers returned 12%, and in 30% of cases a new proposal went through approval again. This is Vas's statement, without independent verification.
A second case from the same write-up: an accounting firm of 60 people, $12 million revenue, 400 clients, 4 systems. Every client sent documents in their own format, including photos of a notebook. The firm believed it had 6 steps. The export from the systems of record showed 14. A repeat request for documents from the client happened in 70% of cases, and a partner returned work in 35%. Vas relays this case secondhand.
The method Vas describes in the Startup Ideas Podcast write-up of October 1, 2026, has three parts. First, interviews with the heads of one department. In finance that means accounts payable, accounts receivable, reconciliations, billing, banking, planning. Five questions: why do you do it this way; who decides; which step is done for appearances; what happens when there is an exception; how often. Second, access to the systems of record for 3 to 4 weeks, to see what data goes in and how often people correct it. Third, reading what lives outside systems: shared drives, Notion, messengers, email, spreadsheets. A large company has ten years of history in its CRM; a small one keeps most of its knowledge in people's heads.
In his X article "Applied AI Doesn't Work" of September 4, 2026, Vas lists seven details a department map must contain. First, the happy path, the main route. Second, exceptions with volume share, cost of error, and processing time. Third, what sits upstream and downstream in the flow. Fourth, all systems of record (the CRM, ERP, or accounting program where the official version of data lives) and which one wins when they disagree. Fifth, differences by region and legal entity. Sixth, touch time versus elapsed time for each step. Seventh, the level of AI familiarity among the people involved. The two methods, process mining and interviews, give the full picture only together.
Majento's recommendation for cases where there are no logs for process mining (accounting in spreadsheets, 1C without change history): build the map from interviews and a spot check of 20 to 30 real documents from the past month, with the date of each step. This gives a rough estimate of queues instead of a precise export, but it already shows where the process stalls.
From system logs of one company, Vas cites a figure: opening a client case takes 25 minutes of work, while the cycle from input to activation runs from 2 days to 2 weeks. The gap between 25 minutes and two weeks is queues and handoffs that an assistant does not touch.
Four buckets: delete, code, agent, human
Every step on the map gets one label. Delete: the step should disappear from the process. Example: forwarding an invoice from the manager to the accountant vanishes if the invoice enters the system of record directly. Code: a rule "if X then Y" with no judgment; several variants means several such rules with no exceptions. Example: looking up a contract by taxpayer ID and matching the invoice amount against the purchase order. Agent: judgment is needed and there is a history of decisions: an invoice line "monitors" probably belongs to office expenses, except for certain suppliers; assembling a commercial proposal also fits here. Human: the cost of error is too high: approval, negotiation, signature, payment. An agent that pays invoices end to end without a person makes the company vulnerable to phishing. In Vas's proposal example, 5 of 20 steps went to agents.

You hand a step to an agent based on how easy it is to verify the result of its action, not on how complex the reasoning is. If the step output is a yes or no, a routing decision about who handles it, a flag for review, or a match on reference data, give the step to an agent and measure every result. If the output is a five-page document a person will read in full anyway, you need a hybrid: the agent drafts, the person edits. The human in the loop receives all evidence at the moment of decision. The agent finds a mismatch between invoice and order and offers three options: approve, reject, return with comment. The person decides in 30 seconds instead of 40 minutes of searching email and notes.
Vas reports a result: a process of 25 steps becomes three agents, with ordinary rule-based automation before and after them, and two human touchpoints.
Vas cites a case from Varick's practice (self-reported): reconciliation of more than 300 bank accounts in an international company, over 12,000 open items. Four of twelve steps were waiting: collecting statements for four days at the start of the month, emailing a controller in another time zone, waiting for a reply, sending a reminder. The other eight were reconciliation and merging regional files. Rebuilt into three steps: statements arrive automatically via feed (nothing to do with AI); everything that reconciles by rule reconciles automatically, otherwise the agent assembles a case with history and evidence; the human works through an exceptions queue. If you only speed up the reconciliation itself, savings amount to hours, and the process still takes weeks.
The "delete" bucket is the role reassembly Qu pointed to. If after sorting no step is deleted, you merely accelerated the process rather than reassembling it. Reassembly starts with some work disappearing, and people redistribute to the remaining steps where judgment is needed.
Illustrative example: paying a supplier invoice in 12 steps
Illustrative example, composed by the editors. A trading company of 200 people, accounting in 1C, approvals in Telegram. The steps as accounting sees them:
- Invoice reaches the purchasing manager by email.
- Manager forwards it to the accountant.
- Accountant searches for the contract on the shared drive.
- Matches the invoice against the purchase order.
- Messages the warehouse to confirm goods arrived.
- Warehouse replies the next day.
- Accountant enters the invoice into 1C.
- Sends it to the director in Telegram for approval.
- Director asks what this invoice is for.
- Manager explains.
- Director writes "ok."
- Accountant prepares the payment order for the bank.
| Step | Bucket | Why |
|---|---|---|
| 1, 3, 4, 7 | Code | One automatic step: receive invoice into system, find contract, match against purchase order and goods receipt, create document in 1C |
| 2 | Delete | Forwarding disappears if the invoice enters accounting directly |
| 5-6 | Code and agent | Automatic request for goods receipt status; on mismatch the agent assembles a case with evidence |
| 8 | Code | Notification to the director in Telegram with contract, purchase order, and goods receipt attached |
| 9-10 | Delete | Explanations disappear if the notification includes contract, purchase order, and goods receipt |
| 11 | Human | Approval: cost of error too high for an agent |
| 12 | Human | Payment: an agent without a person creates phishing risk |
Result: 12 steps become 5, of which two are human touchpoints. The five final steps: receive invoice into system and automatic matching against contract, purchase order, and goods receipt; agent assembles a case on mismatch; notification to the director in Telegram with documents attached; director approval; payment by the accountant. The agent at steps 5-6 does not replace a person; it gathers evidence so the person at step 11 can decide in 30 seconds.
Build inside the systems that already exist
Agents read the CRM and act in the CRM; when a human decision is needed, it arrives as a message in the corporate messenger. Staff work where they worked, no retraining. Vas notes that clients spent years and millions migrating from one ERP to another ($10 million in one case); proposing a move to a new "AI-native" system means losing the client. The exception is small businesses that have no CRM yet.
A single ERP is not required; what is required is one formulation of the process and one owner across the company. Agents tolerate mismatches between systems. Vas gives an example: integrations broke when two systems disagreed on what a vendor record was. On how to set up the environment for agents (access, memory, verification), see the article on the corporate AI harness.
From Majento's deployment practice in Uzbekistan: accounting is most often in 1C, sales in Bitrix24 or spreadsheets, approvals run through Telegram. The agent's approval requests can go to that same Telegram. Working with what exists is faster and cheaper than moving a company to a new platform.

Which metrics to record before launching agents
Vas measures value in three categories: savings, revenue growth, risk reduction. Which of the three to show depends on who is deciding. For the CFO: month-end close takes 22 days to 6 weeks, target is 4 to 8 days at the same or lower cost. Each metric's baseline is recorded before assembly; at 6 months you show before/after. How to put a money value on a task before work starts is described in the article on valuing a task before work begins.
Vas cites an anonymous supplier invoice payment process, mapped in 2 to 3 weeks: 17 steps became 7, cycle shortened from 24 days to 6, exception loops dropped from 6 to 1, the share of invoices handled without manual intervention rose from 18% to 87%, cost per invoice fell from $31 to $6. According to Vas, most of the effect came from fixing the process itself.
Audit and concept validation take four weeks, agent assembly another four, results shown at three and six months. Pilots fail when AI is layered on top: licenses for everyone, or an agent that misunderstood the process. How to choose a process for deployment and validate the first version is covered in the piece on choosing a process for implementation.
Start with the process that has the most handoffs between people, not the one with the largest volume. Across Varick's deployments combined (self-reported, measured with clients): month-end close of 18 to 22 days shortened to 7 to 9; supplier invoice exceptions of 600 to 800 per month dropped to fewer than 50; payroll corrections decreased by 90%.
Why 1990s reengineering failed and what changed since
Hammer and Champy in 1993 recorded that 50 to 70% of organizations that attempted reengineering did not reach their goals. According to Vas's retelling, Hammer later acknowledged he underestimated the human dimension: removing a handoff meant firing the person whose job was that handoff, and the software of the time did not support the change. What differs today: an agent in the system of record performs the handoffs that used to depend on people. The first thing removed is coordination (reminders, waiting, escalations), and the remaining work requires judgment. The FDE model, engineers who deploy agents inside the client's company, and the boundaries where it breaks, are examined in the article on the FDE model.
Questions and answers
We already bought assistant licenses for all employees. What do we do with them?
Keep them. The assistant is useful for work inside a step: drafting text, parsing an email, assembling a draft. It does not solve the queue and handoff problem. But while the process map and reassembly are underway, the assistant cuts touch time on the steps that remain. The problem was never the license; it was buying it as a solution rather than as a tool inside a step.
How long does the process map take and who participates?
Three to four weeks. In that period the department head answers five questions, the analyst gets access to the systems of record and reads shared drives, messengers, email. In a large company with ten years of CRM history (per Vas), process mining gives the main picture; in a small company most knowledge is in heads, and interviews matter more than the export. The output is a map with happy path, exceptions, systems of record, and the share of time spent waiting. If you need help with the map and subsequent assembly, the Majento AI implementation service starts at exactly this stage.
Can we trust an agent with invoice payment?
End to end, no. The agent gathers evidence, finds the mismatch between invoice and order, suggests an expense category, and offers three action options. The person approves or rejects. An agent that pays without a person creates phishing risk: a forged invoice, a substituted account number, a compromised channel. Approval and payment stay with a human, but with ready evidence in the same message rather than 40 minutes of searching.
How is this different from 1990s reengineering, which often failed?
The reassembly mechanism is the same; the executor of handoffs changed. Today an agent in the system of record performs reminders, escalations, document collection, and forwarding in the right format on its own, the coordination that in the 1990s depended on people and could not be removed without layoffs. The process stays on the same platform: agents work inside the existing CRM and ERP, they do not require a migration.
Majento builds AI agents and deploys them inside companies. If you want to sort your own process into the four buckets, write to us on Telegram t.me/shimaoz or by email hello@majento.ai.