The Owner's Calendar Audit
Why this matters
Every owner has a story about where their week goes, and the story is usually wrong in one specific direction: it overstates the field work and understates the answering. You remember the six-hour install. You do not remember the forty-one times somebody asked you something between eight and five. The audit exists because that gap is where your quarter went, and you cannot fix a distribution you have never actually seen.
This is a backward-looking instrument. It does not tell you how to build a better week - that is a separate job, and a sibling article owns it. It tells you what your last two weeks actually consisted of, in counts and percentages, so that whatever you build next is aimed at the real problem instead of the one you feel worst about.
What the audit is, and what it is not
An audit is a coded count of hours already spent. It is not a to-do review, not a productivity score, and not a judgment on how hard you worked. Owners who skip the audit almost always do so because they expect it to read as an indictment, and owners who run it badly turn it into exactly that by coding what they meant to do instead of what happened.
Two weeks, ten working days, one owner. Two weeks rather than one because a single week is dominated by whatever went wrong in it, and rather than four because nobody sustains the coding that long the first time.
The source data: your calendar is not enough
Calendars record intentions. Audits need events. Run the audit against three sources and reconcile them:
- The calendar, for what was scheduled.
- Your job and dispatch records, for when you were actually on site, checked in, or assigned.
- A running paper or phone note kept during the two weeks for everything that happened without an entry anywhere - the walk-ups, the calls, the parking-lot conversations.
The third source is the one that changes the result. An audit run on calendar entries alone typically accounts for 60% to 70% of an owner's day and reports back that the owner has plenty of open time, which is precisely the wrong conclusion.
The coding scheme
Six buckets. Every quarter hour lands in exactly one.
| Bucket | What belongs here | What is easy to miscode into it |
|---|---|---|
| 1. Field work | You on the tools, on site, doing the job the customer bought | Riding along to supervise, which is bucket 2 |
| 2. Unblocking | Answering, approving, deciding, so that someone else can proceed | Real training, which is bucket 5 |
| 3. Sold-work creation | Estimating, quoting, walkthroughs, closing | Chasing a customer who has stopped responding, which is bucket 4 |
| 4. Admin and money | Invoicing, collections, ordering, payroll, compliance filings, insurance | Deciding a policy about any of those, which is bucket 5 |
| 5. Compounding work | Pricing, hiring, training, process fixes, planning: work that changes next quarter | Anything you meant to be strategic but which resolved a single instance, which is bucket 2 |
| 6. Unrecoverable | Waiting, re-doing, meetings that produced no decision, driving added by a scheduling error | Ordinary route travel, which belongs with the bucket it served |
Three coding rules keep it honest. Code the bucket that consumed the majority of a block, and split into two entries at quarter-hour granularity only if the split is genuinely near even. Code the outcome, not the intent: a planning session that turned into resolving one customer's complaint is bucket 2, however it appeared on the calendar. And code as you go or at the end of each day, never at the end of the two weeks, because reconstruction reliably inflates buckets 1 and 5.
What each number tells you
Total your hours per bucket across the ten days, then take each as a percentage of your total logged hours over the same two weeks. Keep the base and the window attached to every figure you write down.
- Bucket 5, compounding, as a share of logged hours. This is the headline. It is the only bucket that changes what next quarter looks like.
- Bucket 2, unblocking, as a share of logged hours. This is your bottleneck reading. High unblocking means work is queueing on you specifically.
- Bucket 2 event count, not just hours. Forty short interruptions and four long consultations produce similar hour totals and mean completely different things. The count is the better signal for switching cost.
- Bucket 6, unrecoverable, as a share. Above roughly 10% of logged hours across a two-week window this stops being noise and starts being a scheduling or dispatch defect worth naming.
- Bucket 1 against bucket 5. If field work is more than ten times compounding work, you are a technician with an ownership stake, whatever the business card says. That is a legitimate choice for a season. It is a bad accident.
The gate that matters most, and it is a pair, evaluated with AND over the same two-week window on the same owner: compounding below 5% of logged hours AND unblocking above 15% of logged hours means your shortage is caused by routing. Work is coming to you that could be decided elsewhere, and adding hours will not fix it because the new hours will route to you too. Compounding below 5% with unblocking at or under 15% is a different diagnosis: genuine volume, and the answer is capacity or scope, not delegation.
A two-week audit, worked through
An owner of a small residential shop runs the audit. Ten working days, 96.0 total logged owner hours, which is 47.0 in the first week and 49.0 in the second.
| Bucket | Hours (2 weeks) | Share of 96.0 logged hours |
|---|---|---|
| 1. Field work | 38.5 | 40.1% |
| 2. Unblocking | 17.0 | 17.7% |
| 3. Sold-work creation | 12.0 | 12.5% |
| 4. Admin and money | 15.5 | 16.1% |
| 5. Compounding | 3.5 | 3.6% |
| 6. Unrecoverable | 9.5 | 9.9% |
His reaction to the first read was that the field number looked low, because he would have guessed he was on the tools more than half the time. He was at 38.5 of 96.0 logged hours, or 40.1% across the two weeks.
Run the gate. Compounding is 3.5 hours over two weeks, which is 1.75 hours per week, and 3.6% of logged hours over the same two-week window: below the 5% threshold. Unblocking is 17.7% of logged hours over that window: above 15%. Both conditions hold, so this reads as routing, not volume.
Now go to the event count, because hours alone will not tell him what to change. The note log recorded 61 distinct unblocking events across the ten days, averaging 16.7 minutes each including the time to get back into whatever he had been doing. Sorting those 61 by what was actually being asked, 34 of them - 56% of the 61 events - fell into just three questions: whether to approve a discount outside the price book, whether to buy a part rather than order it through the usual supplier, and whether to move a booked job to accommodate a customer. Those 34 events at the same average consume about 9.5 hours of the 17.0 unblocking hours across the two weeks.
That is the finding. Not "I am too busy" but "three recurring questions, none of which needs my judgment on the individual case, cost me about 9.5 owner hours per two weeks, which is about 4.75 hours per week."
What he did with it: wrote one decision rule, for the discount question only, giving his lead a stated approval limit expressed as a percentage off book with a named exception path above it. One rule, not three. Then re-audited four weeks later.
The honest result of that re-audit: unblocking events fell from 61 to 47 across ten days, and unblocking hours from 17.0 to 13.5 over two weeks, so about 3.5 hours recovered per two weeks, roughly 1.75 hours per week. That is well short of the 4.75 hours per week the three questions were costing, because he had only converted one of the three and because a written rule gets tested at its edges for the first few weeks. It moved compounding from 1.75 to 3.25 hours per week, which is 6.6% of a 49.0-hour week: above the 5% threshold for the first time. Note that 3.25 is not the full 3.50 the recovered hours would have produced. Recovered time does not land where you point it by default; a quarter hour a week went straight back into admin, and that is the normal result unless the block is protected.
On the gain, deliberately: convert one recurring question into a written rule per audit cycle, not all of them at once. Three rules issued the same week get tested simultaneously, every edge case comes back to you anyway, and you conclude that written rules do not work. They do. They just need one at a time long enough to settle.
Running it so the numbers stay honest
Three specific ways an audit lies, none of which shows up as an arithmetic error:
Coding drift. By day six you start coding the block you sat down to do rather than the one you did. Guard: at the end of each day, take the two longest entries and ask what actually happened in them, out loud.
The audit becomes a performance review. The moment you feel defensive about a bucket, you begin protecting it, usually by upcoding bucket 2 events into bucket 5 because "I was teaching him." Teaching is bucket 5 only if the next identical situation does not come back to you. If it comes back, it was unblocking with a friendly tone.
Selective weeks. Running the audit during a slow stretch produces a flattering distribution that describes no week you actually live in. If the two weeks you audited contained no callback, no absence, and no escalation, they are not representative and the result should be labeled as such rather than acted on.
And one thing that is not a lie but reads like one: a high field-work share is not automatically a problem. An owner deliberately covering a vacancy for six weeks should have a high bucket 1 and a near-zero bucket 5, and the audit's job there is to make the cost visible and time-boxed, not to shame it. What makes it a problem is the same distribution three quarters running with no vacancy to explain it.
References
- See related: How to Design an Owner's Week That Survives Contact
- See related: The Interruption Log SOP
- See related: Why the Owner Becomes the Bottleneck
- See related: The Owner's Calendar: Protecting Time to Think
- Trade-standard practice for owner time measurement in small field-service businesses