Chat Records Are Running Your Process
A customer asks why their order shipped nine days late. The answer exists. It's in a thread from three weeks ago, between two people, one of whom is now on holiday, and finding it depends on remembering roughly what words they used.
That's the whole problem. The decision was made. The reasoning was sound. It just ended up in chat records rather than anywhere you could look it up six months later.
At Mygom.tech (opens in new tab) we spend a lot of time mapping how work actually moves through a business, and this is one of the most consistent patterns we find: the official process lives in the ERP or CRM, and the real process - the exceptions, the approvals, the judgment calls - lives in chat records nobody planned to rely on. That isn't a discipline problem, and you cannot fix it with a reminder.
So: why work migrates into chat, what chat cannot hold and what that costs you, how to test whether it's costing you anything yet, how to move the record out without asking your team to stop talking to each other, and where AI actually helps.
Chat wins in the moment because it has no schema
Your ERP or CRM has a form. The form has required fields, allowed values, and a fixed set of statuses. That's what makes it useful, and it's also why the exception doesn't fit. And if you don't have an ERP at all - the form is a spreadsheet, and the fixed set of statuses is in someone's head - nothing changes except that you hit this sooner.
A customer wants a partial shipment. A supplier slipped two days and the job needs resequencing. A regular client asks for a discount slightly outside the standard band. The form has no field for any of them. So somebody types the situation into a channel, someone else replies, a decision gets made, and work continues.
Chat accepts anything. That's precisely why it wins at 4 p.m. on a Thursday, and precisely why it fails months later when someone needs to reconstruct what happened.
Four patterns show up almost everywhere we look:
- Approval by reaction. A thumbs-up emoji is the sign-off on something with money attached.
- Exception handling with no trace. "This one's urgent, skip the second check." Reasonable call. Nothing in the system says the check was skipped, or why.
- Status that never travels. The team knows the order is on hold. The system still says in production.
- No final version. Three revisions went back and forth in the thread. Nobody can say which one the customer actually received.
All four are people keeping work moving with the fastest tool available. But the fastest tool available is not the same thing as the place the information should live.
What chat records can hold, and what they can't
Chat records are genuinely good at discussion, context, and speed. What they cannot do is hold state. There's no status you can filter on, no owner field you can assign, no due date that can expire and escalate, and no value you can count.
Here's the test we use: can you count last month's exceptions without reading anything?
If answering "how many orders needed a manual override last month, and what were the three most common reasons" means scrolling and reading, you don't have anything you can count. You have an archive. Archives are useful for disputes. They're useless for improving a process, because you can't run the numbers on prose.
That's also why better search isn't the answer. Search retrieves what you already know to look for. A structured record lets you ask questions you hadn't thought of yet.
What it costs when decisions live in chat
The answer nobody can verify. Someone asks what was agreed. Now a person has to go and find out. The problem is not how long that takes - it is what they come back with.
Microsoft's 2025 workplace data (opens in new tab) shows the average worker receives 153 chat messages and 117 emails every working day. The thread you need from three weeks ago is one of several thousand. So the search usually ends one of two ways. You find something that looks right but turns out not to be the last word. Or you give up and go ask the person who was there, and that person is on holiday.
Both endings lead to the same place. Somebody answers the customer while still unsure. Often the guess holds. Sometimes it doesn't, and you correct it a week later in front of that customer.
That is the real cost. Not the time spent looking. The answer you gave before you were certain.
Worth being honest about the source: that is Microsoft's own product data, it measures office-based knowledge workers, it leaves out EU customers, and Microsoft sells the tool it recommends as the fix. If your team works on a shop floor or in a field rather than at a desk, the volume is lower. The record is worse. A decision made over the phone or across a workbench never becomes a message at all, so there is nothing to search in the first place.
The numbers that leave things out. This is the one that costs real money. It is also the one nobody notices.
If an exception gets handled in chat, it never reaches your data. Your override rate, your late-delivery reasons, your discount frequency - every one of them reads lower than the truth, because the system only counted the cases that fit the form.
Say your dispatch report shows four late shipments last month. Three more slipped too, but someone spotted them early, agreed a new date with the customer in a group chat, and delivered on that. The system only ever saw the new date, so those three never counted as late.
Seven orders missed the date you first promised. Your report shows four.
Four looks tolerable. So you spend the quarter tightening the packing step, while the actual cause - a supplier who confirms late - never shows up in anything you read.
The record that disappears. Chat records run on a clock. Database records do not.
If the approval sits in someone's personal WhatsApp or Messenger, it walks out with them when they leave. It is on their phone. You have no right to ask for it back.
Even a tidy setup has a deadline. Slack lets an admin delete messages on a schedule (opens in new tab), and on free workspaces (opens in new tab) your team can only see the last 90 days. If a supplier dispute comes up in month five, the approval you were counting on may simply be gone.
Nobody deleted it on purpose. It aged out.
There's a fourth cost we've covered elsewhere, so we won't repeat it here: when the only copy of a decision rule lives in one person's head and their sent messages, that person is a single point of failure. We wrote about it in When the Whole Business Runs on One Person (opens in new tab).
Try this on your last three exceptions
Before changing anything, find out whether this is costing you. Think of the last three things that didn't go the standard way - an override, a late shipment, a price outside the usual band, a rush job. For each one, answer four questions using only your systems. No asking colleagues. No opening chat.
- Who decided? Not who typed it in. Who had the authority and used it.
- When? A timestamp you could show a customer or an auditor.
- On what basis? The reason, in a form you could count across all three.
- What changed downstream? Did the price, date, or route actually update where it needed to?
Answer honestly. If all four come out clean on all three cases, your process is in better shape than we usually find, and this article is not your priority.
If your honest answer to any of them is "I'd have to ask someone," you already have your result. The record is in chat, and those exceptions are missing from every report you make decisions from.
You can't fix this by telling people to stop messaging
Attempts to solve this by policy usually fail, and the reason is simple. The exception still doesn't fit the form. Telling people to stop using chat just means the exception stops getting handled. Speed wins, and it should.
So do the opposite. The system holds the record. Chat carries the conversation.
In practice that means a small number of unglamorous decisions:
- One owner field, one status field. Both required, both from a fixed list.
- Exception reason as a picked value, not free text. Five to eight options and an "other." This single change is what turns exceptions from anecdotes into numbers.
- A timestamp created by the system, not typed by a person.
- A link back to the thread. Keep the conversation. It's genuinely useful context. The chat record just stops being the only copy.
One rule decides where things go: anything that changes what happens next belongs in the system. Anything that only explains it can stay in chat.
Not every exception deserves this. If a category comes up a handful of times a year, has no money attached, feeds no report, and nobody downstream needs to know it happened, structuring it is overhead for its own sake. Leave it in chat and spend the effort elsewhere. We would rather say that than sell you a project.
And keep the form small. The instinct is to design a thorough exception record with a field for everything, which nobody completes, which sends everyone back to chat within two weeks. The list above is three fields a person fills - owner, status, reason - and two the system fills by itself. Start there. Add a fourth once the first three are habit.
Once your reason list exists, read it once a quarter. If "other" is the most common reason, the list is missing an option. If one reason accounts for a third of everything, that isn't an exception any more, and it belongs in your standard flow.
Where AI genuinely helps, and where it shouldn't touch this
This is one of the cleaner cases for AI in an operations workflow, because the problem matches what models are actually good at.
The input is unstructured human language. It arrives in no agreed format, and the meaning is obvious to a person and invisible to a database. That is real ambiguity, not disorganisation, and turning it into structure is exactly the job. A model can read a resolved thread and propose the record: exception type, affected order, who decided, what was agreed, what changes downstream. A person confirms it or corrects it in one click.
That matters more than it sounds. It removes the actual reason people skip the form. Nobody avoids structured records on principle. They avoid retyping something they just explained in three messages. If the record drafts itself from the conversation, the friction that pushed the work into chat is gone.
We've built on this pattern before. MYGOM Invoices (opens in new tab) does the same thing with invoices that arrive as PDFs, photos, spreadsheets and email text, from hundreds of suppliers, in no consistent format.
What AI should not do here is decide. Approval limits, discount bands and routing rules are deterministic, so they stay deterministic. You don't want a probabilistic answer deciding whether a €40,000 order clears. You want a rule, a validation and a log. Use the model where language is messy. Use plain logic where authority is involved. The longer argument for that split is in Process Automation Starts After Process Repair (opens in new tab).
What it looks like when it works
Once the record exists, the day goes differently. The customer asks why the order shipped nine days late. Someone opens the order and sees the exception, the reason, who approved it and when. The answer takes thirty seconds, and nobody has to remember anything.
The same record helps in two other places. Your exception numbers start telling the truth, so the reports you plan from are actually about your business. And the next person to meet a case like this can see how the last one was decided, without asking anyone.
Not sure whether your process lives in your system or in your chat records?
The test earlier tells you whether the problem is there. It doesn't tell you what to do about it, and that is the harder question. Some of this is worth fixing and some of it isn't, and the difference is rarely obvious from the inside.
That's what our free 3-minute diagnostic (opens in new tab) is for. It sorts out whether you need AI, a cleaner process, or a connection between two systems you already pay for.
If you'd rather talk it through, get in touch (opens in new tab), or see how we approach this kind of work in AI Integration & Automation (opens in new tab).
