Turning Service Calls Into Project Leads: A Framework for Electrical Contractors

A simple observe-flag-recommend system trains techs to surface real project opportunities without turning every call into a sales pitch.

## The Opportunity Sitting in Plain Sight on Every Service Call

A tech dispatched to fix a tripping GFCI outlet is standing three feet from a panel that's twenty-five years old, has no AFCI protection anywhere in the house, and couldn't support a Level 2 EV charger without an upgrade. None of that has anything to do with the outlet they were called for, and most techs, focused on closing out the ticket they're actually there for, walk right past it. That's not a training failure exactly, it's a systems failure: nobody built a process for capturing what a trained eye naturally sees.

## The Observe-Flag-Recommend Framework

This works because it doesn't ask techs to become salespeople. It asks them to do something closer to what they already do instinctively, just with a defined next step.

1. Observe. While working the original call, techs keep half an eye on the broader condition of the electrical system: panel age and brand, presence of AFCI/GFCI protection, service size relative to visible load (multiple window units, an EV in the driveway, a hot tub), obvious code-vintage issues like knob-and-tube or aluminum branch wiring. 2. Flag. Rather than pitching anything on the spot, the tech notes what they saw, with a photo if relevant, in the job file or whatever system tracks the visit. 3. Recommend, low-pressure. Before leaving, the tech mentions it in one plain sentence: "Your panel's original to the house, it's on the older side, might be worth having someone take a look at some point, no rush." That's it. No pitch, no hard close. 4. Route the flag to follow-up. The office reviews flagged jobs weekly and reaches out with a no-obligation offer for a full assessment or estimate, separate from the service call itself.

## Scripts That Don't Feel Like a Pitch

The language matters more than most shops think. Customers can tell the difference between a tech who's genuinely flagging something and one who's chasing commission. A few principles:

- State the observation, not the sale. "I noticed your panel doesn't have any AFCI protection" lands very differently than "You really need to upgrade your panel." - Give them an out, explicitly. "No rush on this, just wanted you to know" signals you're not trying to scare them into a same-day yes. - Never diagnose what you didn't inspect. If the tech was there for one outlet, they shouldn't claim certainty about the whole panel's condition, just flag it as worth a proper look.

## Building the Internal Routing So Flags Don't Die in a Notebook

The framework fails quietly if flagged opportunities have nowhere to go. A few things that keep it alive:

- One clear place flags get logged, whether that's a field in your job tracking tool or a simple shared list, not scattered across individual techs' memories. - A named person who reviews flags weekly and does the follow-up outreach, so it's not everyone's job, which usually means it's no one's job. - A follow-up window. Reach out within a week or two while the visit is still fresh in the customer's mind, not months later when they've forgotten the conversation happened.

## Incentivize It Without Turning Techs Into Salespeople

A small spiff, paid when a flagged lead converts to a booked project, not just when it's flagged, keeps the incentive aligned with quality over quantity. Paying purely on flag volume invites noise: techs flagging every panel they see regardless of actual condition, which erodes the office's ability to trust the flags and erodes customer trust when the follow-up call doesn't match reality.

## Track Conversion, Not Just Volume

Measure this monthly:

- Flags logged per tech, which tells you who's engaged with the system and who's ignoring it - Flag-to-follow-up rate, which tells you whether the office side of the process is actually working - Follow-up-to-booked-project rate, the real measure of whether this is generating revenue or just busywork

If flags are being logged but conversion is low, the problem is usually in the follow-up call, not the tech's observation. If flags aren't being logged at all, the problem is usually that techs don't trust the system will do anything with what they report, which is a signal to fix the follow-up process visibly before asking for more flags.

A shop that builds this well turns every service call into two opportunities: the ticket in front of them, and a quiet, ongoing pipeline of project work that costs nothing to generate because the observation was already happening. It just needed somewhere to go.