Operating Metrics

A field operations business is a machine for turning drive time into service time and service time into recurring revenue, and almost every decision in it comes back to a handful of numbers. Did the work get done? Was it done on time? How much of the day was driving? Are the customers who signed this spring still here in the autumn? Is the money coming in? The platform produces every input to those numbers as a side effect of running: appointments complete, routes are optimized, knocks are logged, invoices are paid. This chapter is which numbers matter, how to define them so everyone means the same thing, and how to get them out of the platform without slowing it down. The general practice is in Data Pipelines & Analytics.

One Definition per Metric#

The first failure of operating metrics isn't a wrong number. It's two right numbers that disagree. A branch manager's dashboard says 4,120 active customers, finance's report says 3,980, and both are correct by their own definition: one counts subscriptions that are past due, the other doesn't; one counts customers whose cancellation takes effect next month, the other doesn't. Every meeting that starts by reconciling the numbers is a meeting that doesn't decide anything.

So define each metric once, in code, and use that definition everywhere (One Definition per Metric). The definitions that matter most in this business:

• Active subscription. Status active (or past due, if you count those), not frozen for non-payment, and not scheduled to cancel. A subscription that is cancelling at the end of the month is not active for planning, even though it's still billing.
• Completed service. An appointment checked out with its required records, not merely started. A reservice (a free callback to fix a problem) is a completed service but not a regular one, and most production metrics exclude it.
• Sale. A signed agreement. Not a set (an appointment for someone else to close), and not an agreement still awaiting signature.
• Customer. Decide whether you count accounts, people or subscriptions, write it down, and use the word only for that (Platform Architecture).

Production: Did the Work Get Done#

The day's first question is whether the scheduled work happened.

• Completion rate is completed services over scheduled services for the day, by technician, route and branch. The denominator is what was on the route at the start of the day, not what was left at the end; a route that dropped five stops at noon and completed the rest didn't have a perfect day.
• Not-serviced reasons break down the gap: the customer wasn't home or the technician couldn't get access, weather, the technician was unavailable, or something else. Only some of those are the company's fault, and the split decides whether the fix is scheduling, staffing or customer communication (Dispatch & the Day of Service).
• Reschedules count how often a visit moved, and who moved it. A high company-initiated rate is a capacity problem; a high customer-initiated rate is often a reminder problem.
• Reservice rate is callbacks as a share of regular services. It's the closest thing the business has to a quality metric: a customer who calls back within the reservice window is telling you the treatment didn't work. Track it by technician and by product.

Compliance: Was It Done on Time#

A recurring agreement promises service at an interval, and each visit has a window around its target date (Recurring Schedules). Some states attach rules to that promise, so on-time service is a compliance number as well as a service one.

• In-window rate. Classify every completed service: on time (inside its window), late, early with the customer's consent, early without it, or a reservice (which has no window). Report the share on time, and treat early without consent as a defect, not a bonus.
• Backlog by tier. Every active subscription is in one of a few states: overdue (past its window with no service), due now (inside its window, not yet scheduled), scheduled outside its window, scheduled but the customer hasn't been told, or upcoming. The first three are the backlog. Report each tier's count by branch every morning; overdue is the number a regional manager watches.
• Capacity against backlog. The useful forecast is how long the backlog takes to clear at the branch's real pace: the average completions per working day over a trailing period, against the backlog plus everything coming due. A branch that completes 300 services a day with 2,400 overdue and due-now is eight working days behind before anything new comes due, and that's the number that justifies a hiring request or a weekend of overtime.

Snapshot these every day (or every month, for trend reports) rather than computing them from current state. "How big was the backlog on the first of March" can't be answered from today's data once those services are done.

Route Efficiency#

A technician's day is service time, drive time, and everything else (loading, breaks, paperwork, waiting). The business makes money in the first, pays for the second, and wants the third small. The route metrics decompose that:

• Services per hour, completed services over hours on the clock. Weight by expected duration where services differ (a large initial treatment counts more than a quick recurring one), or the metric rewards cherry-picking short stops.
• Drive time and miles per service, and miles between stops. Planned from the optimizer, actual from vehicle telematics. The gap between them shows where the route plan and the road disagree: a technician who drives home for lunch, a road the routing data doesn't know is closed, a stop that was skipped and revisited.
• Utilization, service time as a share of shift time.
• Revenue per route hour, the revenue of the services completed over the hours on the route. It's the number that ties operations to finance, and it's why route density matters so much: a branch that sells customers close together can serve more of them per hour at the same price.
• Optimizer score. Whatever the solver minimizes (drive time, distance, a weighted cost) reported per route, so a change to optimizer settings can be evaluated against last week's routes rather than by feel (Route Optimization).

Sales#

Door-to-door sales produce their own funnel, and each step has a number (Door-to-Door Sales):

Metric	What it measures	Watch for
Knocks	Doors knocked, per rep per day and per hour	Volume without results, or results without volume
Decision makers reached	Knocks where the person who can buy answered	The real denominator for closing
Close rate	Sales per decision maker reached	Comparing reps on sales per knock instead
Sales per rep-day	Output, by rank, team and week of season	Week one versus week ten
Contract value	Initial price plus recurring price times the agreement length	Discounting to the floor to close
First-year value	Initial plus the first year's recurring charges	Long terms inflating contract value
Plan mix	Share of sales on each plan	A rep selling only the cheapest plan
Serviced rate	Sales whose first service was completed	The sale that never becomes a customer

The last row is the one that keeps sales honest. A sale that's cancelled before its first service, or rescinded within the cooling-off period, was never revenue (Signing the Agreement). Report cancelled before initial and rescinded per rep alongside sales, and pay on serviced sales, not signed ones (Sales Teams & Commissions).

Retention#

A recurring service business lives or dies by how long customers stay. Stripe's billing analytics define the standard terms: a subscriber has churned when all of their subscriptions are cancelled or unpaid; subscriber churn rate is churned subscribers over the last 30 days divided by active subscribers 30 days ago plus new subscribers since; and lifetime value is average revenue per user divided by the churn rate. Use those definitions, or your own written ones, consistently.

The view that matters is the cohort: every customer who signed in a given month, tracked month by month until they leave. Cohorts answer questions an overall churn rate hides:

• When do customers leave? Separate the early losses (customers who cancel before or right after the first service) from the later decline. Early losses are a sales and onboarding problem; the later decline is a service and price problem, and the two need different fixes.
• Which sales stick? Cohorts by rep, team, plan and price level show whether aggressive discounting or a particular team's sales leave faster.
• Did the change work? A new reminder sequence, a price change or a new technician training shows up as a difference between cohorts before and after.

Split cancellations by reason (price, moved, switched provider, service quality, never wanted it) and by who initiated them (the customer, or the company for non-payment). And measure saves: when a customer calls to cancel and stays, record it, because the save rate by agent and offer is how the retention team learns what works (Collections & Retention). Revenue retention, which includes upgrades, can exceed 100% for a cohort even while customers leave, and in a business where technicians sell upgrades on site it's worth reporting separately from subscriber retention.

Revenue and Receivables#

Finance needs four views, all derived from billing (Billing Recurring Service):

• Recurring revenue. Stripe defines MRR as the monthly-normalized value of active and past-due subscriptions, excluding taxes, free plans and metered products. A field operations business usually has both: plans billed monthly or quarterly, which normalize cleanly, and plans billed per service, which are metered and so have no MRR by that definition. Report them separately, and estimate per-service revenue from the schedule (services owed in the next year times the price) rather than leaving it out.
• Cash. Payments captured per day, by method and merchant account, reconciled to bank deposits.
• Receivables aging. Open and uncollectible balances by how long they've been due: 0–30, 31–60, 61–90 and over 90 days. Report it by branch, because collections policy and customer mix differ by region.
• Leakage. Failed payments in the last week (revenue at risk), refunds and credits in the last month, and write-offs: invoices voided or marked uncollectible. A rising refund rate at one branch is usually a service problem showing up in finance.

Technician Upgrades and Commissions#

Technicians in many field service companies sell on site: an upgrade to a higher plan, an add-on for a specific pest, a referral for termite work. Each earns a bonus, and those bonuses are payroll, which makes their calculation a financial control:

• Write the rule as code, with its conditions explicit: which upgrades qualify (from which plan to which), how much each pays, whether the upgraded subscription must have a completed service within some number of days, and whether the technician must still be employed when that service happens.
• Attribute to the payroll identity. Commissions are paid through payroll, so the calculation needs the employee ID the HR system knows, not only the platform's user ID.
• Reconcile against what was paid. Compare the calculated bonuses to the actual payroll payouts, period by period. Where they disagree, run the rule's variants (with and without the service requirement, with different windows) against the same data to find which one payroll actually applied. That comparison is also the evidence if a technician disputes their pay.

The same discipline applies to sales commissions, with the added complexity of clawbacks for sales that cancel before service (Sales Teams & Commissions).

Getting the Data Out#

Every metric above joins data from several domains: completions from field service, prices from billing, reps from sales, branches from the platform. None of those joins should run against production databases, where a heavy report competes with technicians checking out (Keep Analytics Off Production).

• Change data capture into a warehouse. Stream each domain database's changes into the warehouse (Change Data Capture). Debezium, for example, describes log-based capture as recording every change, including deletes, with a delay in the milliseconds for PostgreSQL, and without adding "last updated" columns to the schema. Domain events can feed the warehouse too, and they carry meaning (an appointment.cancelled with its reason) that row changes don't.
• Transform in layers. dbt's recommended structure is staging models as the building blocks from each source, intermediate models that prepare them, and marts that bring them together into the entities the business cares about (Transformations Are Code). The metric definitions live in the marts, version-controlled and tested.
• Blend in the history you didn't migrate. A platform that replaced a legacy system usually didn't migrate every historical appointment (Migrating Off a Legacy System). Trends that span the cutover need the legacy analytics joined in, with a parity check that the two agree for the period they overlap.
• Freshness is a metric too. A morning backlog report built on data that stopped loading yesterday afternoon is wrong without looking wrong. Monitor each source's lag and show it on the dashboard.

Who Sees What#

Metrics are also how the business motivates people, which makes their audience a design decision. Branch managers see their branch against the region. Technicians and reps see leaderboards: services completed, upgrades sold, sales this week. A wall board in the office shows services completing and sales closing in real time. Each of those is fine, and each shows people, not customers: a leaderboard has technician names, never customer names or addresses. "Today" on every one of them ends at the branch's local midnight, not the server's (Platform Architecture).

What This Means for the System You Build#

• One coded definition per metric, starting with active subscription, completed service, sale and customer.
• Completion and not-serviced reasons recorded on every appointment, with the day's starting schedule as the denominator.
• In-window classification on every completed service, and backlog tiers snapshotted daily, with capacity measured from real completions.
• Planned and actual route figures: optimizer output alongside telematics.
• A sales funnel keyed on decision makers and serviced sales, with pre-initial cancellations and rescissions per rep.
• Cohorts by sale month, cancellation reasons and saves, and subscriber and revenue retention reported separately.
• MRR for interval plans and scheduled revenue for per-service plans, AR aging by branch, and leakage.
• Commission rules as code, attributed to payroll IDs and reconciled against payouts.
• CDC and events into a warehouse, layered transformations, legacy history blended with parity checks, and freshness monitored.

References#

Reference

• Stripe: Billing analytics, definitions of MRR, churn, subscriber churn rate, lifetime value and cohort retention
• dbt: How we structure our dbt projects, staging, intermediate and mart layers
• Debezium: Features, log-based change data capture that records every change, including deletes, with low delay