All guides

Guide · Planning, buying and running AI

A Daily Operating Summary Names Three Decisions, Not Forty Metrics

McGuire Flanigan · Updated October 30, 2026 · 13 min read

It arrives before the first truck rolls, it carries the three things that actually need a decision today, and it leaves everything else exactly where it was. The hard part is subtraction, and a summary that reports everything is a summary nobody reads.

A Dashboard Is a Place. A Summary Is a Moment.

Every service business of any size has already solved the problem of access. The dispatch board is right there, the accounting system has a dozen reports worth reading, the CRM can tell you what happened to any conversation you can name. An owner who wants to know something can find it in about four clicks. What nobody has solved is the fact that the day starts whether or not anyone has looked, and the two hours that decide how the day goes are the two hours when nobody has the attention to go clicking through four systems.

This is the difference between a dashboard and a daily operating summary, and it is worth being precise about because the two get conflated constantly. A dashboard is a place. It waits, it answers whatever question you bring to it, and it is genuinely excellent at the things you go looking for on purpose. A summary is a moment. It arrives at 06:15, unprompted, because the day has already produced a small number of things that will go wrong by noon if nobody decides anything about them. A dashboard can afford to be comprehensive, because comprehensiveness costs nothing when nobody is looking. A summary cannot, because every line in it is a claim on the first ten minutes of a person's day, and those minutes are already spoken for.

So the interesting design question is not how to gather the data. The gathering is a solved problem and it is also the part everybody builds first, because it is the part that demos well. The interesting question is what to leave out. A first draft of any daily summary carries forty or fifty lines, because every number in it is true and every number feels like it might matter. That draft is technically correct and completely useless. Somebody reads it for three days, works out that thirty eight of the lines never change what they do, and by the second week they are reading the first line and the last line and skipping the middle. The message is still arriving. It has simply stopped being read, and there is no error anywhere to tell you that happened.

The counterintuitive part, and the part the model on this page is built to show, is that cutting too far is also a failure. A summary cannot surface a decision it never prints, so a three line message on a morning that produced nine real decisions is not disciplined, it is blind. There is a real optimum and it is not the minimum. It sits close to the number of things that genuinely need a decision today, which is a much smaller number than the number of things that happened, and it moves as the business moves. The work is finding it and then defending it every week against the steady pressure to add one more useful line.

Which is why the honest way to describe this is subtraction. Anyone can add a metric. Adding is comfortable, it feels like more coverage, and it never gets questioned because the metric is true. Removing is the difficult act, because removing feels like hiding something and somebody will eventually ask where a number went. A summary that survives is one where the removals are written down as rules, reviewed by a person on a schedule, and defended on the grounds of what the reader actually decided that morning. That is a much narrower and much more useful target than a report.

The Best Length Is Neither the Shortest Nor the Longest

Set your own numbers and watch the two failure modes pull against each other. Cut too far and decisions never reach the page. Add too much and the decisions that did reach it get buried. Nothing is submitted and nothing leaves this page.

Everything that changed in a connected system between close and open.

Of those, roughly 16 are not a decision at all.

The window actually available, not the window the message assumes.

A message that takes longer than the window available is a message that gets skimmed, and skimming is how the last three lines of a summary become invisible in practice while still being true on paper.

The reading cost is close to nothing, which is the point. This message is not expensive because it takes time to read. It is expensive because of what it fails to put in front of somebody before the day has already committed itself.

Illustrative estimate from the inputs above. Your own numbers will differ; this is not a measured result.

One Night, Six Stages, 124 Candidates Reduced to 3

Follow a single overnight sweep from the first record read to the rule change it produces a month later. Each stage shows the record it emits and names the exact point where this process usually breaks.

Nightly Sweep

What Happens

The summary is assembled from a scheduled sweep that runs after the last truck is back and the office has stopped typing. Nothing is interpreted at this stage. The only question is whether each system can be read and whether the records can be joined to each other on something stable. This stage fails quietly more often than any other, because a sweep that reads nine hundred records and joins six hundred of them looks identical to a business with a light night.

The join is a number a person typed. If the office writes a job number into the invoice memo one digit differently than the dispatch platform stored it, that job disappears from the summary and nobody ever learns it existed. An unjoined record is not an error in either system. It is silence, and silence reads exactly like a quiet night.

Summary Record

Four Rules That Do the Cutting, and the Only Four You Need

Every line in a daily operating summary has to survive all four of these. They are deliberately blunt, because a rule that needs a judgment call in the moment will not be applied at six in the morning when the person doing the cutting is also the person opening the shop.

On Plan Is Not News

A job that is scheduled where it should be, a payment that arrived when it was due, an invoice that matches its job: none of these belong in a message that exists to surface decisions. They are the largest class of line in every first draft and the easiest to remove, and removing them costs the reader nothing because nothing about their day changes if they never see them. The rule is blunt and it works. If the reader would have done the same thing whether or not they had read the line, the line does not get printed.

Already Owned Is Not a Decision

A stalled job with a named person actively working on it is not something the summary needs to raise. It is somebody's Tuesday. The moment a summary starts reporting on work that is already in hand, it trains the reader that most lines are things they can skip, and a summary whose lines are usually skippable gets skimmed. Ownership is readable from the systems of record, so this cut is arithmetic rather than judgment. What survives is the state with nobody attached to it, which is the only state where a decision is actually required.

Tell It Once

The same unsigned estimate does not belong in the message on day three, day four, and day five. A repeated line is how a summary manufactures its own fatigue, because the reader learns within a week that seeing a line twice means the message is not urgent. Repeating it once or twice, at a deliberate interval, is escalation. Repeating it nightly is noise with a subject line. The line should return when something about it has changed, not because the clock advanced one more day.

If It Needs a Lookup, It Is Not a Line

A summary line that says a job may be unbilled and then makes the reader open two systems to find out which one has already failed the only test that matters. A line is a decision, and a decision needs its evidence attached: the record, the date, the amount, and a link that goes straight to it. The subtraction rule and the evidence rule are the same rule seen from two sides. Cut anything that cannot be understood in the message itself, and attach everything that survives.

Why Delivery Time Is Not a Setting

The single most common way a daily summary quietly fails is that it arrives after the day has already made its decisions. It gets scheduled for nine, or for the end of the morning standup, and from that moment it is a status report describing a morning that already happened. A summary arrives while the trucks are still in the lot, while the dispatch board can still be changed without a customer phone call, and while the estimate that has gone cold can still be touched before the owner is on a roof. Move the delivery time by three hours and the same three lines go from three decisions to three regrets. The window is the feature.

Two Readers Who Should Buy Something Else

You want a dashboard, and that is the right answer

A dashboard is a place you go. A summary is a moment that comes to you. If what you actually want is to sit down on a Friday and look at the shape of the month, you want the dashboard, and a daily message will annoy you within two weeks because it arrives when you are not asking a question. The two are complements and confusing them is how a business ends up with six charts it never opens plus a message it never reads. The summary is for the narrow set of things that are decided in the first hour of the day. Everything else belongs in the place you go on purpose.

Nobody wants to own the decisions it names

This one kills the project before a single threshold is tuned. A summary names three things that need a decision today, and every one of those decisions has to land with a person whose job includes making it. If the answer to who handles the overbooked technician day is that everybody sort of watches it, then the summary is adding a daily reminder that nothing happens, and the reader will stop opening it inside three weeks for the very good reason that reading it changes nothing. Fix ownership first. It is free, and it is the actual prerequisite rather than the integration.

Where the Line Sits on Every Summary Action

The agent sweeps, joins, subtracts, ranks, prints, and reports. Every decision the summary names belongs to a person, and money, pricing, promises, and any judgment about how somebody performed are marked never for a reason rather than as a matter of taste.

The Summary Names States, Not People

The fastest way to ruin this is to let it become a daily scorecard on the crew. A line that reads as though one technician had a bad day will be read that way no matter how it is worded, and once that happens the numbers stop being evidence. Jobs get closed at convenient times, time stamps get tidied, and the summary starts reporting a business that does not exist. So the rule is absolute: the line describes a state, the evidence describes the state, and any question about whether a person did something wrong is left to a human who is accountable for answering it. The tool that gets this wrong has a half life of about a month, and it takes the trust in the message down with it.

Straight Answers

The Rest of the Daily Operations Picture

A daily summary is one surface. Which one you need first depends on whether the trouble is deciding, noticing, or acting.

The umbrella guide for the whole daily operations cluster, if you are still deciding which surface to start with.

The other direction. Push alerts during the day for states that cannot wait for tomorrow morning.

How a read and correlate layer sits across platforms that stay exactly where they are.

One of the decision classes a summary carries most often, in full detail.

Cross-system states where completed work and collected money disagree.

The full library across operations, lead response, and back office.

Find the Three Lines Your Morning Actually Needs

In thirty minutes we will list what your systems produce overnight, separate the states that need a decision today from the ones that are simply on plan, and tell you how short the message can be without losing anything that matters. You keep the analysis whether or not you hire us.

Questions operators ask

How is this different from the morning report my platform already emails me?

Almost every operational platform can email a scheduled report, and almost every one of them emails the same thing: a broader cut of what the dashboard already shows, on a timer. That is a dashboard with a delivery time and it inherits the dashboard's central assumption, which is that showing more is helping more. A daily operating summary makes the opposite assumption. It starts from a fixed line budget, usually three to seven, and its whole job is deciding which few lines earn a place in it. The platform report is produced by adding sections. The summary is produced by removing them, and the removal is where the value is.

How many lines should the summary actually carry?

The honest answer is that it depends on how many things genuinely need a decision before the day starts, and the model on this page is where that number should come from rather than from taste. The shape of the curve is what matters and it is counterintuitive in both directions. Cut too far and you lose decisions that never got a line at all, because a summary cannot surface something it does not print. Add too much and the decisions you did print get buried under lines that changed nothing, so the reader notices fewer of them than they would have with a shorter message. The best setting sits close to the number of real decisions, not at the minimum and not at the maximum.

What happens to everything that gets cut?

It stays exactly where it has always been, in the systems of record, and it stays reachable. Cutting a line out of the summary is a decision about what interrupts a person before the day starts, not a decision about what exists. Every removed class still reports somewhere: the accounting system still has its own reports, the dispatch board is still the dispatch board, and anything the business wants to look at on purpose is still there to look at. What is being removed is the claim on the first ten minutes of the day, which is the only resource the summary is spending.

Does the summary replace the person who used to compile it?

It replaces the compiling, which was never the valuable part. Somebody in most service businesses is already writing this message by hand, usually at six in the morning, usually by opening four systems and pasting numbers into a text. That person's judgment about what matters is the scarce input, and the goal is to spend it on the three decisions rather than on the data collection that precedes them. The subtraction rules should be written down and owned by the business, approved by a person, and revisable, because the rules are the business's opinion about what matters and the agent is only enforcing it.

Do I need to replace or migrate any of my systems?

No, and a proposal that starts with replacing a platform you already run deserves suspicion. The summary reads what you have and holds no copy of the truth. Where a platform publishes an event or query surface, the sweep uses it: ServiceTitan V2 exposes jobs, appointments, and calls with webhooks on state changes, Jobber serves clients, requests, quotes, and jobs from a single documented GraphQL endpoint, and QuickBooks Online is realm scoped OAuth 2.0 with a minorversion parameter, incremental changed since queries, and entity change notification webhooks. Where a platform publishes no developer surface at all, the honest answer is that the sweep works from scheduled exports and the numbers are as fresh as the export. AutoLeap, for instance, has no publicly documented developer API, so anything built there runs off reporting exports and work order summaries. That is a real difference in freshness and it should be stated rather than smoothed over.

See where AI fits in your operation

Thirty minutes on how the work actually moves. No pack of agents. No obligation to build. If we can help, we will show you the first paths. If we cannot, we will say so.

Sources

  1. api.tekmetric.com/api/v1, api.tekmetric.com

More guides on planning, buying and running ai