The flow before
How the process ran before we touched it: the steps, who did what, where it waited, and which system held which piece. Written down before anything changes, not reconstructed afterwards.
Must containNamed process · steps · systems
This is not a results section. It is the format we hold ourselves to before anything goes on this site: every claim carries four layers, and the fourth one has a name on it.
The launch version of this site has no results section. What fills that space is the structure of the evidence — how a claim is built and checked — not a general promise about efficiency.
One layer on its own is a story. Four layers together can be checked — by you, by us, and by the person who put their name under the fourth one.
How the process ran before we touched it: the steps, who did what, where it waited, and which system held which piece. Written down before anything changes, not reconstructed afterwards.
Must containNamed process · steps · systems
Which systems were connected, which repeatable part an agent took over, which rules decide, and what deliberately stayed with people.
Must containNamed systems · scope · decision rules
The team and the roles that run on it in daily operation — not a pilot group kept alive for a demo, and not a licence count.
Must containNamed roles · in operation since
A named person on the client side who stands behind the claim, the period it covers, and the owner on our side who is accountable for it.
Must containNamed person · period · accountable owner
Below is the shape of an evidence row. It is a format sample — a demonstration of the structure, not a real case. The highlighted fields are exactly the parts a named source has to fill in before a row is allowed to be published.
An incoming order no longer waits to be retyped from a mailbox into the ERP.
[Named process] arrived by e-mail, was read by a person and retyped into [named system]. It sat in the inbox until someone had time for it.
[Named systems] were connected. The agent reads the order, matches it against the record that already exists, and writes it once. Anything it cannot match goes to a person.
[Named roles], in daily operation since [period].
[Named person and role, client side] · period [from–to] · accountable at ENTER: [named owner].
Until every field carries a name, the row stays unpublished.
An approval no longer waits for someone to notice it.
[Named request type] sat in a shared mailbox. Nobody could see whose turn it was, so it waited until somebody asked.
[Named systems] were connected. The request goes straight to the role that decides it, with the data that decision needs attached. An exception rule says when it goes to a person instead.
[Named roles], in daily operation since [period].
[Named person and role, client side] · period [from–to] · accountable at ENTER: [named owner].
Until every field carries a name, the row stays unpublished.
Until a claim carries all four layers, it stays unpublished.
Some things could be written today and would read well. They are not here, and this is the reason.
A figure with nobody attached to it cannot be checked. If we cannot say where it comes from, which period it covers and who is accountable for it, it does not go on this site — however good it would look.
A client name, a logo or a quote is published only when the client has agreed to it in writing, and only in the wording they agreed to. Consent for one channel is not consent for this one.
A pilot running beside the old process is not the same thing as a changed operating model. We say which of the two we are describing, and we do not let the first be read as the second.
There is no results section on this site yet. It stays empty until the rows above can be filled with names instead of open fields.
The audit is where the first layer comes from: how the work runs today, where it hands off, and what each hand-off costs. Anything we might publish later starts there.
Start the operating audit →