The two-week garage door call scorecard

The Monday complaint is not yet a hiring case

It is September, the board is filling before the first technician has cleared the shop, and somebody says the office needs another CSR because the phones were ugly from 7:30 to 8:30.

Maybe. Broken springs and urgent no-open calls deserve a fast answer, but first-hour congestion is a symptom, not a staffing diagnosis. The calls may be status questions, legitimate booking opportunities, or workflow exceptions. Run a controlled two-week operations test before approving headcount: protect CSR capacity, fix the workflow, add labor, or reject the staffing case.

Define the call types before counting them

A garage door call scorecard fails when every contact is called a “service call.” The CSR who answers “Is the tech still coming?” did useful work, but that call did not require the same judgment as a homeowner reporting a door trapped halfway open.

Give every inbound customer contact one primary tag. The tags are mutually exclusive. If one call contains several subjects, use the highest-value action required: a new repair request beats an ETA question; a safety triage beats both.

Add outcome tags: answered, abandoned, missed, booked, and rebooked. An abandoned call is an inbound contact disconnected before it reaches an agent or self-service response, as ICMI defines it. A missed call is one the company failed to answer or route under its own phone rule. For unanswered calls, classify Booking intent from the IVR selection, callback notes, voicemail, caller ID matched to an open inquiry, or the first documented callback. If those sources do not establish intent, tag the call UNKNOWN and report it separately; do not put it in the Booking denominator. Count a callback or voicemail as recovery only when it produces a documented customer response or disposition. The Booking denominator is all offered calls with confirmed Booking intent, including answered, abandoned, and missed calls; publish the queue scope and any short-abandonment threshold. They are not interchangeable, and combining them makes a tidy number that tells nobody what broke.

Put the definitions in writing, then have the service manager and lead CSR tag five sample calls together. Five minutes of disagreement now beats two weeks of decorative data later.

Week 1: capture the baseline without changing the workflow

Use seven consecutive operating days, or one representative workweek if the business does not operate seven days. Capture calls by hour, with a separate first-hour breakout. Do not turn on a new notification sequence halfway through the baseline because somebody got impatient on day three.

1. Export every offered inbound call for the period. Record answered, abandoned, and missed outcomes.
2. Apply one primary tag to each customer call: Status, Booking, or Change or exception. Keep Other outside the core mix.
3. Record whether a Booking call was booked, and review every abandoned or missed Booking call for callback outcome and disposition.
4. Record missed-arrival rebooks. Count one when a scheduled customer rebooks after failed or absent arrival communication. Report missed-arrival rebook rate = missed-arrival rebooks ÷ scheduled jobs; exclude ordinary customer reschedules.
5. Log the context beside the calls: booked jobs, technicians working, board fill, weather, phone or dispatch outages, and campaign activity.
6. Have the manager audit tags daily. Correct unclear calls while the CSR still remembers what happened.

Use counts and rates. Daily averages can hide the very 7:30 a.m. pileup the owner is trying to understand.

Core formulas

Status-call share = STATUS calls ÷ all tagged customer calls

In plain language: of the customer calls you classified, what portion were routine status questions?

Booking-call share = BOOKING calls ÷ all tagged customer calls

Booking abandonment or miss rate = abandoned + missed BOOKING calls ÷ offered BOOKING calls

Here, offered BOOKING calls means all offered calls with confirmed Booking intent, including answered, abandoned, and missed calls. Exclude UNKNOWN-intent calls from the denominator and report them separately. Publish the queue scope, callback/voicemail rule, and short-abandonment rule with the formula. ICMI notes that abandonment can be calculated using all abandons or only abandons after a stated threshold; either approach is usable if the rule stays fixed and visible.

The baseline is a description, not a verdict. Pull the same week from last year if it exists, and maintain a local weather and event log. There is no neutral garage-door seasonal percentage worth borrowing to explain this week away.

Week 2: test the intervention and hold the comparison steady

In the test week, keep the same weekdays, business hours, phone routing, service area, and call tags. Avoid changing staffing, scripts, marketing, and routing at the same time. A pre/post comparison can show association, but it cannot rule out other causes, which is exactly why comparative before-and-after guidance recommends predefined outcomes and a control group where possible.

Use automation only for dispatch-information work:

1. Send a queue-position or expected-window update where the operating setup supports it.
2. Send an updated arrival window when the schedule changes.
3. Send an on-the-way notice when the technician actually leaves or reaches the defined status trigger.
4. Keep CSRs available for new bookings, booking changes, safety questions, and real exceptions.
5. Log each send event, eligibility, delivery status, opt-out, and failed delivery.
6. Review exceptions at midday and at close: wrong contact data, a technician status that did not fire, a customer who needed a person, or a notification that was delivered too late to matter.

Operational aside: If Queue Up under PR-4086 is the selected test, treat it as the notification mechanism, not the result. It has not earned credit for a call reduction merely by being switched on.

Scheduled, on-the-way, and delay updates are sensible candidates because field-service guidance specifically recommends those moments and notes that automated triggers make ETA updates workable at scale. That is a workflow rationale, not proof of a universal reduction rate. IFMA’s field-service guidance makes the same distinction.

Write every disruption in a variance log: weather spike, technician absence, unusual backlog, system downtime, campaign launch, or a neighborhood outage. If the test week is not comparable, carry it into another matched week. Do not treat a broken comparison as good enough; percentage claims require comparable periods.

Put only decision-grade numbers on the owner scorecard

The owner does not need a blended “calls reduced” headline. That headline can fall because customers gave up, because fewer jobs were scheduled, or because the phone system was down. Put the mix and the guardrails beside each other.

For notification exposure, add two small supporting measures below the table:

Notification delivery rate = delivered eligible notifications ÷ eligible notifications

Status calls per scheduled job = STATUS calls ÷ scheduled jobs

The first tells you whether customers could have received the update. The second prevents a fuller schedule from masquerading as a communication failure. Reminder research also argues for measuring cancellations, rescheduling, and contact-process quality separately, because results depend on accurate contact details and an accessible path for changes. The systematic review is from appointment settings rather than garage doors, so use it for measurement discipline, not a promised outcome.

Include one plain-text annotation field for anomalies. “Two technicians out Tuesday” is more useful than a heroic footnote after the decision has already been made.

Make the decision at the next GM review

Use the scorecard to choose an action, not to congratulate the spreadsheet.

Name one owner for the next action, and put the next review date on the scorecard. One unusual fall week does not justify false precision, and it does not absolve the office from acting on a visible revenue risk. The useful question is narrower: after routine status work was handled consistently, what capacity problem was actually left for the CSR desk to solve?