AI exception handling for legacy companies: start here

Why chatbots miss the first problem

Most delays in older companies do not come from a lack of answers. They start when something is missing, wrong, or waiting on someone. A form arrives without one field. An invoice has the wrong code. A contract needs one more signature. A manager has not approved a routine step.

The team usually knows what to do next. It just cannot move until someone fixes the gap.

That is why chatbots often disappoint as the first AI project. A chatbot can answer questions quickly, but many teams are not stuck because they lack information. They are stuck because work sits in a queue while people chase documents, ask for corrections, and wait for approval.

Think about a finance team that receives 200 invoices a week. Most are simple. A few arrive without a purchase order number, with the wrong vendor name, or with terms that do not match the system. Nobody needs a clever chat reply. Someone needs to spot the exception, send the right follow-up, remind the right person, and move the item forward when the fix arrives.

That is where hours disappear. People spend them checking what is missing, sending the same follow-up again, waiting for signatures, correcting fields by hand, and asking who owns the next step.

A chatbot may still help later. It can help employees find policies or draft replies. But if the real bottleneck is a pile of exceptions, the main queue stays untouched. The team gets a new tool and keeps the same delay.

Older companies feel this pain more than newer ones because their work often runs across email, PDFs, shared drives, old systems, and manual approval chains. The answer may already exist in five places. The problem is that nobody closes the loop quickly.

For a first AI project, exception handling usually pays sooner. It focuses on the friction people face every day. It can detect missing data, flag mismatches, send reminders, route approvals, and track what still blocks each item. That is less flashy than a chatbot, but it often saves more time in the first month.

If a team spends half its morning chasing forms and signatures, that is the first problem to fix.

What exception handling looks like

Most office work does not fail in dramatic ways. It stalls on small misses. An invoice arrives with no purchase order number. A supplier sends everything except the tax form. A contract is fine except for one old clause. A manager forgets to approve a discount before the quote expires.

Exception handling fits these cases because it does not try to replace the whole process. It watches for items that fall out of the normal path, then pushes them back into motion.

In an older company, these slowdowns usually live in email threads, shared folders, and someone else's memory. One person notices the problem, sends a message, waits, follows up, and then asks again. The work is not hard. It is repetitive, easy to miss, and expensive when it piles up.

A simple setup does a few plain things. It checks documents for missing fields or broken rules, sends the item to the right person, follows up after a deadline, and escalates when nobody responds.

Picture a normal day in finance and operations. An invoice lands in the inbox, but the purchase order number is blank. The system flags it, pauses payment, and asks the supplier or internal buyer for the missing number.

Later, a sales rep submits a discount request. The amount is above the team limit, so the request goes to the right manager instead of sitting with the wrong one. If the manager does not reply by the deadline, the system sends a reminder and then escalates it.

Procurement sees the same pattern with supplier records. A vendor wants to stay active, but its tax form is missing or outdated. Instead of waiting for a person to notice, the system sends the request, tracks the reply, and keeps the case open until the form arrives.

Legal work follows the same logic. A contract may be ready except for one clause that uses old wording. The system sends it back for that correction only, rather than restarting the whole review.

This is why exception handling makes a better first move than a chatbot in many companies. The workflow is narrow, the delay is real, and the result is easy to measure. When it works, people feel it within days because fewer tasks sit idle and fewer staff waste time chasing the same answer twice.

Where time disappears each week

Legacy teams rarely lose hours on one big failure. They lose them in small stalls that repeat all week. A request lands in email, someone asks a question, another person forwards it, and nobody knows who owns the next step.

That gap sounds minor until it touches money or delivery. One missing attachment can stop a payment run, hold a shipment, or send a customer order into review. The work itself is often simple. The delay comes from chasing the missing piece.

A common example is an invoice that arrives without a purchase order or signed approval. Finance spots the issue, emails procurement, procurement asks the requester, and the requester is in meetings all afternoon. By the next day, three people have touched the same problem, but the invoice still sits there.

The waste usually shows up in familiar places. Email threads split the history across inboxes. Staff type the same correction into the ERP, a spreadsheet, and a ticket. Managers receive approval requests with no summary, so they postpone them. Teams discover the problem only after a vendor or customer asks why nothing moved.

Managers slow things down too, often without meaning to. If an approval arrives with no contract, no amount, and no short reason for the spend, it drops to the bottom of the pile. Most people will not approve a fuzzy request quickly.

Retyping makes the problem worse. Staff copy the same fix into several systems because each tool holds one part of the process. Five minutes per case does not sound like much until the team handles fifty cases a week.

That is why AI for approvals and exception handling usually beat a chatbot as the first project. The pain is already clear, the trigger is easy to spot, and the result is easy to judge. If the system catches missing documents, asks the right person, adds context for approval, and logs the fix once, teams get time back almost immediately.

You do not need a full rebuild to see the gain. You need fewer stalls, fewer chase-ups, and a cleaner path from issue to decision.

Start with accounts payable

A good first project is accounts payable. Most older companies already receive hundreds of invoices every week, and the work is repetitive enough to map but messy enough to waste real time.

Picture a finance inbox that fills up all day with PDFs, scans, and email attachments. Some invoices have the wrong vendor name. Some miss a purchase order number. Some have totals that do not match the line items. A person still has to open them, compare fields, send emails, wait for replies, and keep nudging people.

This is where exception handling pays off early. The system reads each invoice first and checks simple items before a clerk ever sees it: totals, vendor names, dates, tax amounts, duplicate invoice numbers, and missing fields. Most documents either pass or fail for clear reasons.

When something is missing, the system sends a follow-up right away. It can ask the vendor for the missing document, request a corrected invoice, or ask an internal approver to confirm a cost code. That alone cuts a surprising amount of idle time because the chase starts in minutes instead of two days later.

The clerk still matters, but the job changes. Instead of touching every invoice, the clerk reviews only the unusual cases: a total that does not make sense, a new vendor with incomplete details, or a mismatch between the invoice and the purchase order. That is a much better use of judgment than typing the same reminder email forty times a week.

Track a few plain numbers from day one. Watch the average cycle time from receipt to approval, the number of invoices sent back for fixes, any late fees or missed discount windows, and the hours staff spend on follow-ups. Those numbers show whether the workflow is working. They also make the next step easier, because finance can point to less rework and fewer delays instead of talking about AI in the abstract.

This kind of project is small enough to ship quickly and useful enough to matter.

Choose a workflow you can judge quickly

The best first workflow is usually dull, repetitive, and easy to judge. That is good news. If a team can explain in one minute why an item moves forward, gets approved, or gets kicked back, you probably found a strong starting point.

Start where people spend time chasing paperwork. Missing forms, unsigned contracts, invoice mismatches, expired vendor documents, and customer onboarding files are common examples. Document chase-outs work well here because the rules are visible and the handoffs are already painful.

Volume matters more than prestige. A process that creates thirty similar cases a week will teach you more than a flashy project that appears once a month. Repetition gives you patterns, and patterns make automation much easier to test.

Ownership matters too. Pick a queue with a named owner, a deadline, and a clear outcome. If nobody owns the inbox, nobody will clean up edge cases, fix bad rules, or decide what should happen when the system gets stuck.

Do not replace a whole system in round one. Keep the ERP, CRM, email inbox, or even the shared spreadsheet if that is where the work lives today. Add a small layer around it that checks documents, routes exceptions, and reminds the next person. Teams get into trouble when they mix process automation with a full platform move.

Before you choose any tool, write down the most common exception types. Keep the list short and real: missing signature, wrong purchase order number, expired certificate, approval over limit, missing tax document. This list tells you two things very quickly. It shows whether the rules are clear enough to automate, and it shows where people still need to step in.

If every exception turns into an argument, skip that workflow for now. Pick the one where the team already agrees on what went wrong and what should happen next.

Roll out the first pilot

Start with real work, not a workshop. Pull thirty days of exceptions from one team and look at the cases that got stuck, bounced back, or waited too long on someone.

That sample is usually enough to show the pattern. In most companies, the same few problems appear again and again: missing data, wrong data, and approvals that sit in an inbox.

Use those groups as your first map. Give each case type one action and one owner. If data is missing, the system asks for the exact field and sends the request to the person who can provide it. If data is wrong, the case goes to the person who can correct it. If someone must approve it, the system routes it to that approver and follows up if they do not respond.

Keep it this plain at the start. Good exception handling is boring on purpose. It should move work to the right person quickly, with a clear next step.

Do not try to automate every strange case. Keep a human review path for edge cases, rule conflicts, and messy documents. If a case looks unusual, send it to a reviewer instead of forcing the model to guess.

Run the first version as a small pilot with one team, one workflow, and a limited case count. Two to four weeks is often enough. A finance team handling invoice corrections or a sales operations team chasing missing contract details is a good place to begin because the delays are easy to see.

Measure only a few things at first: turnaround time, rework rate, and response rate from the people who need to act. Those numbers tell you whether the workflow actually removed friction. If turnaround time drops but rework climbs, the routing is too loose. If response rate stays low, the follow-up step or the owner is wrong.

Treat the pilot as a test of behavior, not a test of the model. The goal is not to prove that AI is smart. The goal is to clear routine blockers faster than the old process did.

Mistakes that slow the project

Most first AI projects stall for plain reasons. Teams pick the most visible idea, try to automate too much at once, and then wonder why nothing sticks.

The first mistake is starting with a chatbot because everyone can see it. It looks modern, but it often leaves the real bottlenecks untouched. If people still wait three days for approvals, the chatbot did not fix much.

The second mistake is giving the workflow no owner. When five people touch the same process and no one decides what happens next, the tool just moves confusion around faster.

The third mistake is mixing two hard changes together. If the team is moving to a new ERP, changing approval rules, and adding AI at the same time, nobody will know which problem caused the failure.

Another common mistake is trying to automate arguments. If staff do not agree on what counts as a valid exception, the system will not fix that disagreement. It will simply surface it sooner.

Teams also get distracted by model quality and forget to measure the queue. A pilot succeeds when fewer items sit idle, fewer reminders go out by hand, and fewer people retype the same fix. That is what matters.

Quick checks before you automate

Most first projects fail for a simple reason: the team tries to automate a messy process it cannot describe in plain language.

Start with the exceptions you already see every week. If nobody can name the five that take the most time, spend two weeks counting them in email, tickets, and shared sheets. A rough count is enough. You need patterns, not a perfect report.

Each exception also needs one owner. One person or one role decides what happens next. If operations blames finance and finance waits for sales, the tool will only move the confusion faster.

Approval rules need the same clarity. If three managers approve the same request in three different ways, automation will copy that inconsistency. Write the current rule in one sentence. If you cannot do that, fix the rule before you add software.

Missing documents deserve special attention because they create quiet delays. A team should know right away when a file is incomplete, unreadable, or absent. If people notice the problem only at the last review step, the process has already lost hours or days.

A short checklist helps. Count the most common exception types from recent work. Assign one clear owner to each exception. Compare how different staff approve the same case. Define what makes a document complete at intake. Pick one team that can test a new flow on its own.

That last point matters more than many teams expect. Company-wide change slows everything down. One small team can test faster, give feedback in real time, and show whether the idea works.

Accounts payable in one business unit is a good example. The team keeps chasing missing purchase orders, wrong totals, and unsigned forms. Those problems repeat, the owner is clear, and the result is easy to measure. That is usually a stronger first move than a company chatbot.

What to do next

Pick one approval or document chase-out flow you can fix this month. Keep it boring on purpose. Invoice approvals, missing contract signatures, or chasing a manager for a purchase order are better starting points than a company chatbot because you can measure the result.

Map the current path on one page. Write down who starts it, what document or request moves, where it stalls, who approves it, and what "done" means. If the map spills into several pages, the workflow is probably too big for a first pilot.

Give one person clear ownership for thirty days. That person does not need to build everything. They need to keep the scope tight, answer questions quickly, and make sure the team reviews real cases instead of abstract ideas.

A small pilot works better when the rules stay simple: one team, one workflow, one source of truth, and one weekly review. During the pilot, review the same numbers every week. Count how many items entered the flow, how many got stuck, how long people spent chasing them by hand, and how often a person had to step in.

A simple example makes the point. If finance waits on three missing vendor documents before payment, start there. Let the system spot the missing file, send the first reminder, and pass the case to a person only when something does not match the rule. That alone can save hours each week.

If you need an outside view, Oleg Sotnikov at oleg.is works as a fractional CTO and startup advisor on AI-first software development and automation. For a first rollout, the useful part is not a big transformation plan. It is choosing one workflow, fitting the solution around the systems you already have, and proving the result in a month.

Aim for a small win you can judge after thirty days. If the flow moves faster and people do less chasing, you have your next project.