An important email has sat in a shared inbox for three days. Two colleagues saw it, and each thought the other would reply. When the customer writes again, the team starts asking who is “to blame”. A more useful question is: at what point should that incoming message have become someone’s specific next action?
A business process is a repeated route from an event to a defined outcome, with clear steps, owners and handovers. “Read the email” is one task within a process. The full process may begin with an enquiry and end with a reply, an order or a deliberate refusal. Without a named outcome, nobody knows whether the work is finished.
For a small business, this does not require six months of consulting or a diagram covering an entire wall. Take one route that already hurts: enquiry to offer to payment, order to delivery, recruitment to first working day, or invoice to payment confirmation. Describe what actually happens, then decide what can be removed or automated. I would begin where a person is waiting for an answer while the team believes the request is “already being handled by someone”.
The example is GrandMa’s internal Klar case study. This email-triage system covered five work mailboxes across three companies. We measured emails, threads, tasks created and summaries sent. We did not measure payroll savings, revenue or response speed, so this article makes no claims about them.
1. How a process differs from a to-do list
A list saying “check email, reply, create task” does not show what happens if an email covers two subjects, the owner is on holiday or the classification is wrong. A process answers four more questions: what triggers it, who owns the next step, how an exception is handled and what proves completion.
For Klar, the trigger is a new email or thread in a connected mailbox. The outcome can include a priority in a summary and a created task visible to a person. The system should not independently promise a customer that they will receive a reply. A person remains responsible for the subsequent decision and communication.
IBM describes process mapping as a way to see steps, owners and opportunities for improvement. You can draw that map with boxes and arrows. Formal BPMN from OMG is available when many participants need a shared, detailed notation. For a small team’s first conversation, a table with four columns is enough. If everyone understands where the email gets lost after an hour, the map has done its job.
2. The “email to task” process before Klar
Work email for PILLAR, Betsa and GrandMa arrived in five separate accounts. Important threads mixed with less important messages. The next action depended on who saw the message first and whether that person moved it into a work system. This is a simple map of the situation before automation. It reflects the documented principle of manual sorting, not every click by every employee:
| Lane | What happened | Where the handover could fail |
|---|---|---|
| Sender | Wrote to a company inbox, sometimes continuing an old thread | They could not know who was responsible internally. |
| Inbox | Received the email among other messages | Importance did not separate itself from noise. |
| Person reviewing the inbox | Read it, judged its importance, forwarded it or kept it in mind | The next action could remain only in someone’s head or email thread. |
| Person doing the work | Learned about the task if it was explicitly handed over | No shared record ensured the work was visible. |
A missed email does not always mean an employee was careless. If nobody owns the handover from “inbox” to “task”, two people can both sincerely believe the other will do it. Handover gaps often cost more than the individual actions.
The first step in business process improvement here need not involve AI. One person could be responsible for checking the shared inbox daily and recording next actions. Automation becomes interesting when volume and repetition make that manual step expensive and routing rules are clear enough.
3. What Klar automated and what people still did
Once the mailboxes were connected, Klar classified incoming threads, helped turn next actions into tasks and sent scheduled digests. Read this map as a boundary of responsibility, not a claim that the system wrote every reply:
| Lane | Automated or human step | What to check |
|---|---|---|
| New messages and threads enter the connected flow | Are all required mailboxes connected, and are connection errors visible? | |
| Klar | Classifies threads and produces structured results | Do category and priority make sense, and what happens when confidence is low? |
| Tasks and digest | Creates a task or includes an important item in a summary | Did the record actually appear and get delivered, rather than merely being scheduled? |
| Person | Reviews the next action and decides how to reply | Is an owner named, and does the system avoid claiming to have answered the customer? |
The public case records 615 processed emails and 426 threads from 12 to 26 June 2026. The 91 tasks created and 148 digests sent were measured over 13 June to 8 July 2026. These are different periods. Dividing one figure by another to produce a supposed “email-to-task conversion rate” would be wrong. Some messages should not become tasks, and the time windows do not match.
The figures show that an internal process received and structured work at this volume. They do not show how many hours the team saved, how quickly every email was answered or how many sales followed. The valuable boundary is clear: the system makes a next action visible without replacing the person who decides what to do.
4. Describe your own process in one hour
Do not begin with a presentation about every department. Choose one recent incident the team remembers and bring in the people who hand work between them. IBM recommends checking a process map with those who actually work in it. A manager’s diagram and the real route can differ.
First 10 minutes: define the trigger and final outcome. For an incoming enquiry, they might be “someone sent a request” and “they received an answer or a confirmed reason we cannot serve them”. If the endpoint is merely “a CRM record was created”, you can optimise record creation and still leave people unanswered.
Next 20 minutes: reconstruct the most recent real case, from message to outcome. Do not draw the ideal route from memory. Open timestamps of the email, handover and reply, task entries and moments when someone had to find context. Record every manual copy-and-paste step.
Next 15 minutes: assign an owner to each step and mark exceptions. What if there is no contact detail? What if two managers see the enquiry? What if the automatic record is not created? At which point will someone learn about a failure?
Final 15 minutes: choose one gap and agree on a simple change for one week. Name an owner, a review date and a measure. For example, replace “improve email” with “every important email has an owner and a visible next action by the end of the working day”. Next week, inspect actual emails rather than how everyone feels about the new diagram.
One-page process-map template
Copy these fields into a document or spreadsheet for one route:
- Process name: what moves from beginning to end?
- Trigger: which event starts the work?
- Outcome for a person or the business: how do we know the work is finished?
- Steps: event → action → handover → decision → completion.
- Owner of each handover: who is accountable when work passes between two people?
- Where it is recorded: email, CRM, task, document or payment system.
- Exception: what happens when data is missing, a step fails or the owner is unavailable?
- Current problem: how often did it occur in recent real cases?
- Check after the change: which same measure will we inspect in a week or month?
This map is useful without specialist software. It can become a short working rule: who takes each step and what counts as done. Once the process is stable, it can move into a tool without losing its meaning.
5. Which process to automate first: a four-criterion matrix
Score each candidate from 0 to 2 on four criteria. Zero means “barely present”, one “partly”, two “clearly present”. This is a working way to discuss priorities, not an objective ranking of all business processes.
| Criterion | Question to ask | Example for Klar email triage |
|---|---|---|
| Frequency | How often does the same beginning and a similar set of steps repeat? | 2: five mailboxes supplied a regular stream of emails. |
| Clarity of rules | Can we describe what to do in ordinary and failed cases? | 1: classification can be defined, but difficult email stays with a person. |
| Cost of an error | Is a customer, money or trust noticeably at risk when a step gets lost? | 2 as an editorial assessment of risk: an important next action could become invisible; financial loss was not measured. |
| Data readiness | Is there a dependable input, access, way to record an outcome and way to see errors? | 1 initially: the mailboxes existed, but a shared task and summary layer had to be built. |
This illustrative score is 6 out of 8. It is not a measurement from the case study; it only shows how to fill in the matrix. Another owner may choose different scores. A high-frequency process with unclear rules should first be organised manually. A low data-readiness score often means the first investment belongs in a shared record or access, rather than AI.
Compare two or three candidates: incoming enquiries, repeat orders, invoices or monthly closing. Choose one whose difference the team can see in its own records. If messages get lost between messengers, our guide to CRM and spreadsheets for enquiries may help. If the gap lies between an enquiry, the work and payment, see our map of that route.
6. What not to automate yet
Do not hand a machine a rule people have not agreed on. If managers define an “urgent enquiry” differently, automatic classification will only apply that disagreement faster. Agree on a meaning, test it against real examples, then put it into a system.
Do not automate decisions requiring personal judgement without oversight and a way to stop the action. A disputed refund, contract exception or difficult complaint can be prepared with data and a draft. The named person remains responsible for the decision. And do not measure success by the number of tasks created automatically. If nobody takes them, the process has not improved.
Before connecting systems, specify what happens when something fails. The mailbox is unavailable, a record is duplicated or a digest does not go out. Who notices? How are missed items recovered? An elegant automatic route without failure handling can be less reliable than a simple manual rule.
Start measuring before the change. Choose a small but consistently defined period, such as the last two working weeks. Count all incoming messages, those that needed action, those assigned an owner and those actually answered. Repeat the same definitions over a comparable period afterwards. If the week’s email volume doubled, that alone could explain part of a difference. Do not call the team’s rough impression “hours saved”; that number requires separate timing of the same operations before and after.
7. Your first step this week
Take one email, enquiry or order that was delayed. Trace it backwards from the outcome to the original event. Note who held it at each step and where the next action disappeared. Agree on one seven-day change: an inbox owner, a required task for a certain message type or an end-of-day checklist. Compare similar cases before and after.
If it feels as though the entire working day vanishes into small handovers, we have broken that pattern down separately. For a more complex integration, you can discuss automation with GrandMa: bring one real route, its exceptions and data we can use to assess a change. “Automate the business” is not a starting task. An email that must become someone’s action is.