Three questions for every process
Before you draw any workflow, ask each candidate process three questions:
- How often does it happen? A process that runs four times a year does not deserve a workflow. One that runs forty times a week almost certainly does.
- Can you write the rules down? If you can write on one page what happens in each case, you can automate it. If the answer is “it depends” and nobody knows on what, not yet.
- What does a mistake cost? A ticket routed to the wrong person gets forwarded. A payment approved by mistake, or an email with another customer’s data, cannot be undone.
To start, look for high volume, clear rules and cheap mistakes. Leave for later anything that rarely happens, depends on someone’s judgment and is expensive when it fails.
A simple matrix to decide
| Type of process | If a mistake is cheap | If a mistake is expensive |
|---|---|---|
| High volume and clear rules | Automate it now | Automate it, with a human approval at the sensitive step |
| Low volume or fuzzy rules | A template or a checklist is enough | Do not automate it: write the procedure first |
Score each candidate from 1 to 3 on the three questions and rank them. You do not need more precision: the conversation with the people doing the work today matters more than the number.
Examples by department
| Area | Good first candidate | Better to wait |
|---|---|---|
| Purchasing | Purchase requests with approval based on the amount | Choosing a new supplier |
| HR | Onboarding a new hire, with tasks for IT, admin and their manager | Evaluating the probation period |
| Customer service | Sorting and assigning what comes in, and confirming receipt | Answering a sensitive complaint |
| Quality | Opening a nonconformance with its checklist and owner | Deciding the root cause |
| Finance admin | Approving expenses with their receipts | An out-of-policy expense that needs judgment |
| Maintenance | Creating the work order when a reading goes out of range | Deciding whether to repair or replace a piece of equipment |
The pattern repeats: you automate the movement, meaning who gets what, when and with which data. Judgment stays with people.
Where AI belongs, and where it does not
AI fits steps where someone has to read free text and mistakes can be corrected. It does not fit where a written rule does the same job, or where a mistake is expensive.
| Yes | No |
|---|---|
| Sorting an incoming email: order, complaint or question. If it gets it wrong, someone reclassifies it. | Approving an expense or a payment. A rule based on the amount is cheaper, more predictable and easier to audit. |
| Summarizing a long thread or transcribing a voice note before the next step. | Choosing the path of a process with formal requirements, such as closing a nonconformance. |
| Detecting the tone of a message to prioritize it. | Writing to a customer without review on a sensitive topic. |
A simple test: if the rule fits on one line (“if the amount is over $3,000, the director approves”), you do not need AI. Save it for what does not fit on one line. There is more in what works and what fails with AI in customer service.
How to start without breaking anything
- Pick a single process from the “automate it now” box.
- Map it with the people who do it today, not with the people who manage it. Steps will show up that were never in any procedure.
- For two weeks, measure how long it takes and how often it gets stuck.
- Build it, test it with real cases and turn it on for one team.
- After a month, review the run history: where it stalls and which exceptions show up.
Exceptions are the valuable part. If many runs end with someone fixing things by hand, the rules were not as clear as they looked.
Three common mistakes
- Automating a broken process. If nobody knows today who approves, the workflow will just make the mess faster.
- Starting with the most complex one “because it hurts the most.” It takes the longest to build and is the most likely to fail.
- Leaving no trail. An automated process without a history is a black box: when it fails, nobody will know why.
A simple process that runs on its own every day teaches you more than a big project stuck halfway. Start there, and let the exceptions tell you which one comes next.
Last updated: