Operations systems

The weekly work that never gets easier, built once as a system.

The same approach, outside our two named domains. We take this work by referral and enquiry only, against a rule we publish and use to decline.

01The fit rule

Four conditions. All four, or we say no.

We publish this because it saves everyone a call, and because a firm that will not tell you what it declines has not decided what it is.

  • 01 · Unstructured or fragmented inputDocuments, files, records and feeds that live in more than one place and do not agree with each other.
  • 02 · An output that can be checkedSomething with a right answer, or at least a defensible one — not a matter of taste.
  • 03 · A consequential decision with a named ownerSomebody acts on the output, and it costs something when it is wrong.
  • 04 · A team willing to change how the work is doneThe system replaces a process. If the process cannot change, the system is shelfware.

02The shape of the work

Problem shapes, not an industry list.

We name a sector only after a system has shipped in it. Until then, this is what the work looks like from inside.

  • Research at volumeA team of four reads three hundred documents a week and keys the findings into two systems that do not talk to each other.
  • Document-heavy workflowsEvery case, claim or file arrives as a PDF, and the first hour of work is finding six fields inside it.For example — a document pipeline that reads incoming PDFs and produces a checked structured record with every field carrying the line it came from.
  • Monitoring and event detectionSomebody checks a list every morning to see whether anything changed, and occasionally forgets.For example — a monitoring job that watches a filing source and raises an exception with its evidence when something changes.
  • Reporting that has to reconcileA recurring report assembled from three sources, where the reconciliation is done in a spreadsheet nobody else can open.For example — a weekly report that assembles itself from source systems and flags what it could not reconcile rather than silently averaging it.
  • Repetitive information work across toolsThe same record is typed into three systems by three people, and the third one is the version anyone trusts.
  • Data-intensive operationsThe pipeline exists but nobody can say when a number changed, who changed it, or what it was before.
The same work, before and afterToday the work passes through an analyst, a spreadsheet, a second system and a reviewer before it becomes the number — five handoffs with no record of what changed between them. Built as a system, the same inputs are extracted and derived once, checked against the source, and the number leaves with its evidence attached.TODAY — FIVE HANDOFFS, NO RECORD OF WHAT CHANGED BETWEEN THEMANALYSTSPREADSHEETSECOND SYSTEMREVIEWERTHE NUMBERBUILT AS A SYSTEM — ONE HANDOFF, AND EVERY STEP LEAVES A RECORDThe same inputsExtraction andderivationChecked againstthe sourceTHE NUMBER + EVIDENCE
  • TodayAnalyst → spreadsheet → second system → reviewer → the number. Five handoffs, and no record of what changed between them.
  • Built as a systemThe same inputs, extracted and derived once, checked against the source, and the number leaves with its evidence attached. One handoff, and every step leaves a record.
Figure 09Today the work passes through an analyst, a spreadsheet, a second system and a reviewer before it becomes the number — five handoffs with no record of what changed between them. Built as a system, the same inputs are extracted and derived once, checked against the source, and the number leaves with its evidence attached.

What we decline

Sometimes the answer is not a system, and sometimes it is not AI. We would rather tell you on the first call than discover it in week six.

  • Judgment-only outputs, where there is no checkable right answer
  • “Put a chatbot on it”
  • Dashboards with no decision owner behind them
  • Generic automation and cheap development
  • Anything you could not explain to your own regulator or auditor without calling us

The buyer this usually is

An operations leader at a mid-sized firm whose back office runs on documents and records spread across tools, who owns a number or a deliverable somebody else relies on, and who can name the person who will run the system after handover.

Every build ships with an operating view — what the system processed, what it flagged and why, and what it could not resolve, each with the evidence behind it. A window onto the machine, not a substitute for one.