AI for business operations pays off one process at a time: a billing queue or an exception backlog, rebuilt so AI closes the routine cases and people decide the rest. Starting narrow has a reason. Gartner predicted in July 2024 that at least 30% of generative AI projects would be abandoned after proof of concept by the end of 2025.
The reasons Gartner gave were poor data quality, inadequate risk controls, escalating costs or unclear business value. Each of those is an operations problem, and operations leaders are the people who can fix it. For a COO or head of operations at a company with thousands of staff, holding a long list of AI ideas and one budget, the case is for a narrow start. Pick one manual, critical process. Rebuild it around an AI system with a person on the exceptions. Run it as part of the operation, with an owner and weekly numbers, from the first day.
What does AI actually do in business operations?
In operations, AI earns its place by taking over part of a running process. An impressive answer in a meeting proves a capability and nothing more, and the distance between the two is the distance between operational AI and AI that demos well. An operational system reads from and writes to the systems of record, acts within written limits, hands the cases it should not decide to named people, and is measured on the process's own numbers.
What changed in the last few years is reading. Older automation could follow rules on structured data. It could not read the email, the PDF remittance, the customer's description of the problem or the free-text note an agent left last month. Most operational work, and most exceptions, arrive in exactly those forms. AI can now read them, decide whether a case is routine, gather the context from several systems, take a permitted action and explain what it did.
So the unit of change is the whole process. Automating one keystroke-heavy step leaves the queues and hand-offs untouched, and in many back-office processes the waiting between steps takes longer than the work inside them. The table below shows the process families where operations leaders usually find their first candidate.
| Process family | Where the manual load sits | What AI takes on | What a person keeps |
|---|---|---|---|
| Billing inquiries and disputes | Investigating charges across billing, CRM and payments | Explaining charges from account data; credits within limits | Disputes above limits, hardship, regulatory complaints |
| Exception management | Unmatched payments, rejected orders, failed postings | Triage, context gathering, known fixes | Write-offs, customer disputes, new exception types |
| Back-office processing | Invoices, claims, onboarding, reconciliations | End-to-end handling of routine cases | Decisions with money or relationship risk |
| CRM data cleansing | Duplicates and stale records that break billing and service | Matching, verifying and updating records continuously | Ambiguous merges, ownership disputes, deletions |
| Customer contact | Questions that need one customer's own data | Answers and actions inside authenticated channels | Complaints, vulnerable customers, judgment calls |
Customer contact runs through several of these. Self-service handles general questions well and account-specific ones poorly, and the questions that escape it are about one customer's bill, order or case, which is why call deflection only works when the answer comes from the customer's own data.
Which process should you start with?
Manthle's working definition of a good first process has three parts: it is too important to stay manual, too specific for off-the-shelf software and too complex for basic automation. Each part rules something out. A process that is not important does not justify the effort of doing it properly. A standard process is better served by a product. A process with fixed rules and structured inputs is better served by plain automation.
Within that space, score candidates against these questions:
- Volume. Does it handle enough cases each week that the routine share is worth taking over?
- Cost of failure. When it goes wrong, does it show up as cash, customer loss, regulatory exposure or audit findings?
- Written rules. Is there a policy, a contract, a tariff or a tolerance that defines a correct outcome?
- Measurability. Can you baseline cycle time, backlog, error rate and rework today?
- One owner. Does one leader own the process end to end, or will every decision need a committee?
- Reachable data. Can the systems involved be read and written through interfaces, or only through screens?
- Identifiable exceptions. Can experienced staff describe which cases need judgment and why?
Most strong candidates sit in the back office, the functions nobody sees until they break. Back-office work tends to score well on every question above: steady volume, written policies, queues that can be measured and a leader who already answers for them.
Industry shapes the shortlist. Carriers usually start with telecom billing inquiries and disputes, where a billing dispute is often a question nobody answered; the broader view is on AI in telecom. National retail operations start with returns exceptions, vendor deductions and records. Public transit agencies start outside the safety-critical path, with customer contact and report intake. Wherever customer records drive billing or service, CRM data quality and the daily practice of CRM data hygiene are often the hidden first problem.
A quick comparison shows how the questions sort candidates. Consider three hypothetical options at one company:
| Candidate | Volume | Cost of failure | Written rules | One owner | Verdict |
|---|---|---|---|---|---|
| Billing inquiries and disputes | High, peaks after each bill run | Calls, credits, churn, complaints | Plan terms and credit policy | Billing operations | Strong first candidate |
| New-vendor onboarding | Moderate | Payment fraud, compliance gaps | Procurement and finance policy | Shared by procurement and finance | Good, once one owner is named |
| Marketing copy generation | High | Low, and visible before release | Brand guidelines only | Marketing | Useful, but outside operations |
The third option may be worth doing. It is a poor first operations project: nothing in the operation runs on it, a failure costs little, and so it teaches the organization nothing about running AI under load.
Red flags for a first process: nobody can say what a correct outcome is; the process is about to be replaced by a new platform; its volume is a few dozen cases a month; or its owner does not want it changed.
How do you rebuild a process instead of automating the old one?
Automating a process as it stands preserves its waste: approvals that never reject anything, hand-offs that exist because two teams once disagreed, checks done late that could be done at entry. The lesson of business process reengineering applies, and the broader case is made in the business process automation guide.
Manthle's method runs in five steps: See, Rethink, Engineer, Harden and Run. The AI implementation guide covers each step in depth. For an operations leader, three decisions inside those steps matter most, and none of them should be left to the builders.
- What the process actually is. The procedure manual describes the intended process. System logs, read with process mining, and an afternoon beside the team show the real one, workarounds included. Build on the real one.
- What the AI may do. Which case types it may close, which it may only prepare, and which go straight to a person. That is a policy decision, written down before anything is built, and it belongs to the process owner.
- What evidence will prove it is safe. Agree the test before the build: the historical cases it must get right, the abuse cases it must refuse, the guardrails that stop it at its limits, and the controls finance and audit will ask for.
The builders can answer everything else in the method once those three answers exist.
What stays with people?
The design principle is old. Frederick Winslow Taylor described the "exception principle" in Shop Management: managers should see condensed, comparative reports with the exceptions pointed out, "both the especially good and especially bad exceptions." Management by exception was hard to practice because someone had to read everything to find the exceptions. AI now does the reading.
In a rebuilt process, people keep four kinds of work:
- Judgment calls: cases outside the written limits, novel situations, conflicting policies.
- Decisions with money or risk attached: write-offs, large credits, payments to changed bank details, anything touching fraud.
- Relationships: customers in hardship, complaints with regulatory weight, supplier disputes.
- Ownership of the rules: setting and changing the limits, reviewing samples of routine decisions, and deciding when the process itself should change.
The hand-off is where most designs fail. A person who receives an exception with no context starts the investigation again, and the AI has saved nothing. A good hand-off delivers the case, the evidence, the policy that applies, the AI's recommendation and the reason it stopped. Designing that hand-off, with named roles, authority and response times, is the practical meaning of human in the loop. In back-office terms the result is exception management: a queue that shrinks, where each item arrives ready to decide.
How do you run AI as an operation instead of a project?
A project ends at go-live. An operation starts there. The difference shows up in five places.
Ownership. One operations leader owns the process's results, including the AI's part. IT owns the platforms; the vendor or builder owns the system's engineering. Nobody can say "the model did it."
Measures. The weekly numbers are the process's numbers: cycle time, backlog, share of cases closed without a person and how many of those were later reversed, exception aging, error and rework rates, and the cost of the errors that escaped. Model accuracy is an input to those, never a substitute.
Change. Operations change every month: new products, prices, suppliers, regulations. The system has to change with them, on the same day, which means somebody is assigned to keep it current. Staff roles change too, from doing the routine work to deciding exceptions and improving the rules, and that shift needs planning with the team.
Commercial shape. A pilot sized as an experiment ends with a report. A pilot sized as the first phase of an operation ends with a running process. Manthle structures it that way: a pilot on one process becomes a monthly operations contract once it works, and Manthle's engineers stay in the operating review after launch.
Expansion. The second process goes faster than the first, and not because the AI is reusable everywhere. The connectors to the systems of record, the exception queue, the review routine and the habit of running an AI system as part of the operation all carry over. Choose the second process the same way as the first, by scoring it, and resist the pull to launch five at once. A company with one process running well has something to copy. A company with five pilots has five reports. Why so many pilots never make that transition is argued in AI pilot to production, and the AI agents for business guide covers how to decide what an agent may own.
When is AI the wrong tool for an operations problem?
Being honest about this saves the budget for the processes that need it.
- The rules are fixed and the inputs are structured. Plain RPA or the platform's own workflow engine will be cheaper and easier to maintain.
- A packaged product matches the process. Accounts payable, expense management and reconciliation tools are mature. If your process is standard, buy one.
- One upstream defect causes most of the work. Fix the bill design, the validation rule or the integration. No AI system beats not creating the problem.
- The volume is small. A well-trained team with good procedures is the right answer for a few dozen cases a week.
- Nobody owns the outcome. Without an owner, an AI system will be built, launched and left to decay. Find the owner first.
When none of those apply, and the process is important, specific and too complex for basic automation, it is a candidate. Start with one. Get it running. Then take on the next.