The Operating Baseline: financial, customer and workflow visibility

A baseline is the boring answer to an expensive question: how do we know whether that worked?

Without one, the argument about whether a change helped is settled by whoever is most confident in the room. With one, it is settled by evidence, and it takes ten minutes instead of a quarter.

A baseline is easy to assume you have. Check what yours is made of. A monthly close and a weekly report that disagree with each other, plus a dashboard nobody has audited since it was built, is not a baseline. This guide is about what a real one contains, and how to find out in an afternoon whether yours would hold up.

Three kinds of visibility, and why one is not enough

Financial visibility answers what the business earned and spent, and whether the cash is where the report says it is.

Customer visibility answers who your customers are, what they asked for, what you promised, and what actually happened.

Workflow visibility answers what the work did between those two -- the steps, the handoffs, the waits, and the ones that went wrong.

You can hold one of the three and assume it covers the others. It does not. A good controller gives you financial visibility and no workflow visibility at all, because closing the books tells you what happened last month, which is a different job from running the operation this week. A good CRM gives you customer visibility while the back office runs in the dark. And a process consultant maps the workflow without ever tying it to a dollar, which produces a beautiful diagram nobody acts on.

You need all three because the interesting problems live in the joins. Revenue is fine and margin is slipping -- that is a workflow answer hiding inside a financial number. Customers are complaining about turnaround and the dashboard says turnaround is excellent -- that is a measurement definition problem, and one of the two is measuring from the wrong moment.

What each one actually contains

Financial

Not a full close. The subset of finance that touches the operation you are trying to improve.

• Revenue split the way the operation is actually run -- by line, location, channel or job type. If the P&L is one bucket, nothing operational can be traced into it.
• Contribution margin per transaction type. Not gross margin at company level, which averages the loss-makers into invisibility.
• Fully loaded labour cost by role. Wage plus payroll taxes plus benefits plus the overhead that person consumes.
• Cost to serve for the main transaction types.
• Days sales outstanding, split into the part caused by your own process delay and the part caused by customer payment behaviour. Only the first part is yours to fix.
• The running cost of the systems in scope, including per-use consumption. Anything you build has a bill attached, and it belongs in the baseline from the start.

Customer

• A single record per customer, with duplicates found and counted rather than assumed away. The duplicate rate is itself a finding.
• Inquiry source, arrival time, and the time of the first genuine outbound contact. The gap between those last two is Line 2 of the value formula.
• What was promised: quoted turnaround, service level, delivery date. Written down somewhere a machine can read.
• What happened: actual delivery, actual resolution, actual invoice date.
• Complaints and their reasons, categorised consistently enough to count.
• Where the data is free text pretending to be structured. A status field with 40 distinct values, 12 of which are spelling variants, cannot be automated against until it is fixed.

Workflow

A finance pack and a CRM leave this one out between them. It is also the cheapest of the three to obtain, because your software has been writing it down for years without anybody reading it.

Start with the event log. Each row is: case identifier, activity, timestamp -- plus, where you can get them, the source system, a role identifier, the status transition, an exception flag and the outcome. Those three core fields are the standard requirement for process mining, and they are enough to answer most workflow questions on their own.

From them you get:

• Cycle time from trigger to completion -- median and 90th percentile. The average is the least useful statistic in operations because it hides the tail, and the tail is where the cost lives.
• Touch time versus wait time. Measure the hands-on minutes and the elapsed days separately. Where the work takes minutes and the case takes days, the days hold the cost, and automating the minutes buys you a faster wait.
• Handoffs per case, and queue depth at each one.
• The variant map -- how many different paths the work actually takes. Count them from the log, then compare that count with the number of paths anyone in the room can name.
• Exception rate, and the cost of an exception against a clean case.
• Rework loops: cases that visit the same step twice.

Notice what none of that required. Nobody was recorded, nobody was observed, and nobody's screen was captured. It came out of timestamps your systems already write. Start there. Observation is for the specific questions the logs genuinely cannot answer, and it should be optional, scoped to one question, visible to the person, pausable by them, and time-boxed. Anything touching calls, SMS or email is a separate matter with its own permissions and its own legal review -- and a company owner's permission is not their employees' permission, nor a third party's on a call.

The number that has no owner

Every measure in a baseline needs the same fields written down once, and the field that gets skipped is the owner.

• Name
• The decision it supports
• Owner
• Formula, with its numerator and denominator
• Units and period
• Authoritative source
• Refresh frequency
• Baseline
• Target
• Quality checks
• Known limitations
• Escalation threshold, and the person accountable when it is crossed

Two of those do more work than the rest.

The decision it supports. If a number does not change a decision, stop producing it. A dashboard of eleven numbers where two are acted on is nine numbers of maintenance cost and a lot of scrolling past the important ones.

The owner. One human being. Not a department, not a committee, not "ops." A number owned by a department is owned by nobody, and you will discover this on the day it goes wrong.

The McKinsey survey mentioned in our other guide found KPI tracking associated with reported AI value alongside workflow redesign. Same caveats apply -- self-reported, correlational, and not drawn from the American mid-market -- so treat it as consistent with the argument rather than as proof of it. The practical case stands on its own: you cannot automate against a number you do not trust, and you cannot trust a number nobody is accountable for.

If you run EOS or something like it, you already have a scorecard and a meeting rhythm, and that is a genuine head start. The only question worth asking is whether the numbers on the scorecard are pulled from a system of record or typed in on Monday morning from memory. A baseline works underneath that rhythm rather than replacing it.

Test the baseline you already have

An afternoon. No consultant required.

1. The two-report test. Take one number that appears on both the weekly operating report and the monthly close. Same period. Do they match? If not, can anyone explain the difference in under five minutes? An unexplained gap is not a rounding problem, it is two different definitions with one name.

2. The trace test. Pick three numbers from your dashboard. For each, name the system it came from, the exact formula, and the person who owns it. Three for three is a strong result.

3. The definition test. Ask four people to define "closed won," or "resolved," or "on time." Do it separately so they cannot hear each other. Count the distinct answers. Every extra answer is a number that cannot be compared across teams.

4. The stopwatch test. Take your most frequent transaction. Ask the person who does it how long one takes. Then time ten real ones, including the awkward ones. The gap between the two is the gap between the process you believe you run and the one you actually run, and that gap is where the money is.

5. The break test. Ask: how would we know today if this process stopped working? If the answer is "a customer would tell us," you have no operational monitoring, only a complaints department doing it for free.

6. The tail test. For your main cycle time, produce the 90th percentile as well as the average. If your system cannot produce a percentile, that is the finding.

Failing these is normal. The value is in knowing which ones you fail, because that tells you what to fix first and stops you buying a fix for the wrong problem.

What a baseline is not

It is not a report. A report is produced monthly and read. A baseline is a fixed, dated, documented statement of what the operation did over a defined period, kept unchanged so that a later measurement can be compared against it. If it gets quietly updated, it is not a baseline any more.

It is not a target. Baseline first, target second, and the target is set by someone with the authority to be held to it.

It is not proof of anything on its own. A baseline lets you measure a change. It does not establish that your change caused the change. Seasonality, headcount, pricing and marketing all move at the same time you do. Normalise the obvious ones, use a staged rollout where you can so there is a comparison group, and write down what you could not remove. Anyone offering you a before-and-after as proof of cause is selling.

It does not fix anything. Measurement is not change. A baseline plus a map plus no action is money spent on a document. The point of it is what you do in the eight weeks afterwards.

Three weeks of baseline is not a year of seasonality. A baseline taken in your busiest month is not your average month. Say so on the document rather than quietly annualising it and hoping.

What to do first

Pick the workflow that costs you the most, not the one that annoys you the most. Pull its event log -- case id, activity, timestamp -- for the last twelve months. Produce the median and the 90th percentile cycle time. Put a name against the process. Then run the six tests above on the numbers you already publish about it.

That is a week of somebody's attention and it will tell you more than most dashboards tell you in a year.

---

The examples here are illustrative and are there to show the shape of the calculation, not to report a result. Nothing in this guide reports a client outcome. Our prices are published on the approach page. If you want the baseline built properly, that is the Operating Diagnostic.