Business Systems & Automation. One place to look for each fact.

When the same customer exists in three systems with three versions of the truth, every decision downstream is a guess. This practice settles which system is allowed to be right, and what happens when a handoff fails.

$2,500 Operations Audit — the fixed-fee entry point for this work. Implementation is scoped separately.

Start an operations audit How the audit works

For owner-led businesses across the United States whose systems were each a reasonable choice on their own, and were never asked to agree with one another.

What this practice settles

Four decisions

Which system is authoritative Per data type — customers, orders, invoices, schedules — decided once and written down.
How records are matched Which field carries identity, what counts as a match, and who decides a near-match.
What each handoff requires What has to be true before work moves, what moves with it, what proves it arrived.
Who owns a failure Retry behaviour, escalation, and the named person a failed step lands on.

These decisions are made in the Operations Audit. Building against them is separately scoped implementation.

Five things you would recognise.

The cause is rarely obvious from the symptom. It may be unclear ownership, it may be missing data rules, and it may be a genuine limit of a system in use — often more than one at once. Sorting out which applies here is what the audit does.

Each system was a reasonable choice on its own. What was never decided is which one wins when they disagree — so the answer today depends on who you ask and which screen they happen to be looking at.

The same customer exists in three systems, under three slightly different names.
An order is re-keyed by hand from one system into another, and the two now disagree.
"Where is it up to?" gets a different answer depending on who answers it.
An integration stopped working, and the first evidence was a customer asking why nothing had happened.
A tidy-up was done once, by hand, and the duplicates came back within the month.

What the work actually is.

Six decisions, normally worked through in roughly this order because the later ones lean on the earlier ones. Which of them a given engagement needs, and how far each is taken, follows what the findings warrant.

Choose authority per data type For customers, orders, invoices and schedules separately: one system holds the authoritative version, and any copies elsewhere carry a stated update rule and an agreed tolerance for how far behind they may run. Written down, not assumed, so there is an answer when two screens disagree.
Map identifiers and matching rules How a record in one system is recognised as the same thing as a record in another: which field carries identity, what counts as a match, and what happens to a near-match that a person has to decide on.
Clarify each handoff For every point where work passes between systems or between people — what has to be true before it moves, what moves with it, and what proves that it arrived.
Specify triggers and responsibilities What starts an automated step, what that step is allowed to change, and which named role is accountable for the result. All three are decided before anything is built.
Handle retries, duplicates and exceptions What a step does on its first failure, what it does when the failure persists, and which named owner receives it. A failed step is a visible state with an owner, never an absence nobody noticed.
Document and verify the rollout Change one path at a time. Check the expected workflow against representative test cases, then an agreed pilot on a limited slice of live work, before wider rollout — and leave behind a written description of what the system now does, readable by whoever runs the work next.

Customer record, to order, to invoice.

The working document this practice produces: one row per fact that has to be settled before automation is safe to add.

Illustrative sample

Written to show the format and the four questions every row answers. A real sheet is filled from the systems the business actually runs.

Business Systems · Rule sheet Customer to invoice · 6 facts

Where the fact lives, who owns it, what proves completion, and what happens if it fails.

Every row is a decision somebody has to make and record. Where a row cannot be completed, that gap is the next piece of work — and it is also the decision an automation would otherwise make on your behalf, silently.

Illustrative handoff and rule sheet for a single revenue path.
The fact	Where the fact lives	Who owns it	What proves completion	What happens if it fails
Customer identity	Customer record system	Named owner of the record	One record, with its source and creation time	A second record for the same customer is queued for merge, not created silently
Contact and billing details	Customer record system	Named owner of the record	The change is dated and attributed to a person	A change that does not reach the accounting system returns to that owner with the failure attached
Agreed price and terms	The accepted quote version	Named owner of the deal	An order that names the quote version it accepted	An order with no matching quote version is held for review before it can be invoiced
Order status	Order system	Operations lead	A status the customer would recognise, set by the step that caused it	A status older than its review date appears on the daily list, next to its owner
Fulfilment evidence	Order system	Operations lead	A completion record attached to the order — not a message about it	Work marked complete without evidence is reopened, not invoiced
Invoice and payment	Accounting system	Finance	Payment reconciled against the order it belongs to	Past terms assigns a named follow-up owner, not an automated reminder

The three matching rules the sheet depends on

Two customer records are the same customer when they share the agreed stable customer or account identifier: Which identifier that is gets decided for this business and recorded here. A similar name at a similar address is an ambiguous match, not a match, and is not treated as one.
An ambiguous match goes to a named owner, not to an automatic merge: Both records are shown side by side, the owner explicitly selects which becomes the master, the merge is logged and the history from both is retained on the surviving record.
Corrections are made in the authoritative system: Copies held downstream carry a stated update rule — when they refresh, and how far behind they may acceptably run. Corrections flow outward from the authoritative record, so there is no second place where the truth is changed independently.

Illustrative sample. Every row answers the same four questions, and the answers shown here are written to demonstrate the format rather than to prescribe a policy — a real sheet records what this business decides. A row that cannot be answered is a decision waiting to be made by somebody, deliberately or otherwise.

Automation that fails loudly.

An automated step that fails silently is worse than the manual step it replaced: the work stops, and nobody finds out until a customer does. Every automated handoff is specified with three behaviours before it is built.

STEP 1

Attempt

The step runs, changes only what it was specified to change, and records that it ran — against the record it acted on, where the next person will look.

STEP 2

Retry

A transient failure is retried on a defined schedule, a defined number of times. A retry never creates a second record: the matching rules decide that, not the retry.

STEP 3

Named owner

A failure that persists lands in a named person's queue with the record, the step and the error attached. The work becomes a visible owned state rather than an absence.

Automation is placed last, not first. A handoff that cannot yet be described in a sentence is not clear enough to automate — automating it only makes the confusion arrive faster and more consistently.

$2,500 Operations AuditFixed fee

What the audit settles, and what implementation builds.

The Operations Audit examines the paths agreed at kickoff, identifies the authority and handoff decisions they depend on, and returns findings and a recommended scope. Implementation is separate work, scoped from those findings.

The fixed fee covers the diagnostic deliverables, not the build. Implementation is agreed separately and delivered in stages, with a decision point at each boundary.

Start an operations audit Everything the audit covers

From the audit you receive

A current-state operating map of the paths in scope
The authority and handoff decisions those paths depend on, and where they are still open
Findings, risks and dependencies ranked by leverage
A prioritized 30 / 60 / 90-day path
An implementation scope with decision gates

A scoped implementation delivers, as applicable

Detailed matching, recovery and handoff specifications
The configured handoffs, in the order the findings rank
Failure, retry and escalation routed to named owners
Representative testing and an agreed pilot before wider rollout
Rollout documentation of what the system then does

Audit terms

Typically completed within 10 business days after kickoff and receipt of the required access and information; timing is descriptive, not a guarantee. The audit fee may be credited toward qualifying implementation begun within 30 days, subject to the engagement agreement. These terms describe the audit; implementation timing is agreed in its own scope.

Questions people ask first.

Do we have to replace the systems we already use?

Replacement is not the starting assumption. The work begins by deciding which existing system is authoritative for each kind of data and what the others have to do to agree with it — a decision that costs time and attention rather than licences.

The audit then establishes whether clearer rules inside the current tools are sufficient, or whether a limit of a system in use genuinely blocks what the business needs. Where it does, replacement appears as a finding with the constraint behind it and the decisions it depends on.

What if two systems cannot be connected to each other?

Then the handoff is defined as a human step, with a named owner, a trigger and evidence that it happened. It answers the same four questions as every other row on the sheet. An undocumented manual handoff is the problem; a documented one is a legitimate answer.

Does this have to start with the audit?

The audit is how these decisions get sequenced: normally authority first, matching rules next, handoffs after that, automation last. Work that starts before those decisions are made risks encoding the current confusion rather than resolving it.

What does the documentation actually look like?

The audit returns the operating map, the ranked findings and the recommended scope for the paths agreed at kickoff, in the register the sheet above illustrates. Detailed specifications, failure behaviour for each automated step and rollout documentation belong to a scoped implementation. All of it is meant to be read by whoever runs the work next, not filed.

Start where the systems disagree.

Name the fact that has two answers — a customer, an order, a status, a balance — and describe what happens today when somebody notices. That is enough to tell whether this is the right practice to start with.

Start an operations audit The other three practices

What changes

There is one place to look for each fact, and everyone knows which place it is.
Records are matched rather than duplicated, so two versions of a customer stop arriving downstream.
A handoff that has not happened is a visible state with an owner, not an absence.
Automation fails to a named person instead of into silence.
A new person can be told how the systems relate, because it is written down.