You already know the number is bad. You can see it on the dashboard. What you don’t have is someone — or something — that goes and fixes it while you’re doing everything else.

Dashboards are a mirror, not a hand

A dashboard is a read-only view of a problem. It tells you that 47 supplier documents are sitting unprocessed, that three enquiries have gone unanswered for 48 hours, that stock for a particular line has dipped below reorder level. Then it stops. The next move is still yours.

That’s fine when you have a team big enough to act on every signal. Most small B2B operations don’t. The dashboard becomes a guilt screen — a list of things you’re behind on, refreshing itself helpfully every hour.

What an operator actually does

An operator watches the same signals, but it has a job to do when one fires. It takes an action, then writes down what it did and why. That written record is the receipt.

A concrete example from a UK supply-chain client we built for: every inbound supplier document used to land in an inbox and wait for a human to open it, extract the key fields, and paste them into a spreadsheet. Conservatively, 30 minutes per document. Volume was doubling month on month.

The operator we built does this instead:

  1. Watches the inbox for new attachments.
  2. Extracts the structured fields — supplier reference, line items, quantities, delivery date — using a document-extraction model.
  3. Writes the result to the relevant system of record.
  4. Logs a plain-English receipt: which document, what was extracted, what was written, timestamp, confidence flags if any field was uncertain.

The human reviews the receipt log, not the raw documents. Exceptions surface automatically. Routine work disappears.

Why the receipt is the whole point

Automation without a receipt is a black box. Your team won’t trust it, your auditors won’t accept it, and when something goes wrong you’ll have no idea where.

A receipt doesn’t have to be fancy. A row in a Google Sheet is a receipt. A Slack message with a structured summary is a receipt. A plain text log file is a receipt. The format is less important than the habit: every action the operator takes gets written down in a place a human can read.

Think of it like a bank statement for your automation. You don’t watch the bank move money around in real time — you check the statement and confirm it matches what you expected. Same principle.

How to sketch one for your own backlog

Pick the single most repetitive task your team does that starts with information arriving somewhere. Then answer these four questions:

  • Trigger: Where does the information arrive? (Email, form submission, spreadsheet row, webhook.)
  • Action: What does a competent human do with it? (Extract, classify, route, reply, update a record.)
  • Destination: Where does the result need to land? (CRM, spreadsheet, Slack, another system.)
  • Receipt: Where will you read the log? (Slack channel, shared Sheet, email digest.)

If you can answer all four in a sentence each, you have a buildable operator. If you can’t answer the receipt question, stop — that’s the design gap that makes automation untrustworthy.

The dashboard still has a role

We’re not saying burn your dashboards. A dashboard that shows you the operator’s receipt log — how many documents processed, how many exceptions flagged, what the error rate looks like — is genuinely useful. You’re now watching a worker, not a problem. That’s a different relationship with the same screen.

The shift is this: the dashboard used to be the end of the process. Now it’s the audit trail for a system that already did the work.

Where to start

If you have a backlog that refreshes itself faster than your team can clear it, that’s the candidate. One operator, one trigger, one receipt format. Build the smallest version that saves real time, measure it for a month, then decide whether to extend it.

We build these for small UK B2B teams. System builds start at £4,000. If you’d rather understand the scope before committing, an audit is £750 and gives you a clear picture of what’s worth automating and what isn’t.

See what a build typically covers: badboylabs.com/#pricing.