What changes when systems stop just filing things away

For thirty years, company systems did one thing: store. Information went in, stayed there, and whoever needed it went and fetched it. All the interpreting — working out what it meant and what to do next — was down to people.

What's changing now is that boundary. The system starts reading what it holds and saying something about it. It's not a change of tool: it's a change in the division of labour, and it has consequences on both sides.

Three scenes, before and after

In customer service. Before: a request comes in, someone reads it, works out what it's about and routes it. After: the request arrives already classified, with that customer's history alongside it and a suggested reply underneath. Whoever handles it now reviews rather than starts from scratch.

In operations. Before: you find out an order is late when the customer calls. After: the system notices that job has been sitting still longer than usual for that type of work and flags it before anyone outside the company notices.

In management. Before: the monthly report says what happened. After: it says what happened and flags that three customers have a buying pattern that's out of the ordinary. It's still management that decides whether that matters.

The work that disappears

It's almost always the same thing: the work of preparing information for someone else to use.

Exporting, cross-referencing, formatting, rewriting the same reply for the twentieth time, digging through a history to find that one conversation. It's work nobody misses once it's gone, and it usually eats more hours in the week than any manager imagines — because it's spread across everyone, ten minutes at a time.

The new work that shows up

This part gets talked about less, and it's the one that tends to go wrong.

• Reviewing. Someone has to look over the suggestions, especially in the first few months. A suggestion accepted without being read is worse than no suggestion at all.
• Fixing it at the source. When the system gets it wrong, you need to understand why. It's almost always a badly recorded piece of data, and that's what needs fixing — not the output.
• Deciding the limits. Up to what value does a suggestion go ahead on its own? What kind of request always goes to a person? These rules need to be written by someone who's accountable for them.
• Knowing when to switch it off. If it isn't working, someone has to be able to say so without that being seen as a personal failure.

Who answers for the answer

It's the question that usually gets left till last and should be asked at the start: when the system suggests the wrong price to a customer, whose problem is that?

The practical answer is always the same — it's the company's. In front of a customer, a court or a regulator, there's little difference between a person's mistake and a mistake made by a system the company put to work. What's different is that a system's mistake repeats itself a thousand times before anyone notices.

That's why deciding where to draw the line — what goes ahead on its own and what passes through human eyes — is a management decision, not a technical option. It's worth making deliberately, not by default.

What doesn't change with any of this

The uncomfortable part: none of this fixes a messy operation. If the data is inconsistent, the suggestions come out inconsistent too — just faster and better presented.

That's why this kind of project almost always starts in the same place: tidying up where the data comes from and connecting what doesn't talk to what, in CRM and integrations work, before putting intelligence into the workflows.

How much of your day goes on preparing information?

Tell us where your team loses hours moving data from one place to another. We'll tell you what can be taken off the plate.

Request a quote