Building a quote request flow for electricians: decisions that matter
A quote flow for electrical panel jobs should catch urgent problems first, ask only what customers can answer, and leave the judgment to the electrician.

A brief like this lands in my inbox a few times a year: "We're an electrical contractor. Customers keep calling about panel work and we spend half the call asking the same questions. Can an app collect that first?" It's a good brief, because it describes a real cost. Before I quote anything, I study how a local electrician offering electrical panel replacement Colorado Springs homeowners can read about explains the service, since a quote flow has to match the language customers already see on the company's own pages.
This piece walks through the decisions behind a quote request flow for panel jobs. It's written for developers and designers building for trades. It is not a guide to electrical work: none of what follows tells a homeowner what to do with their panel, and the app shouldn't either.
The problem: the first phone call does too much
When a homeowner calls an electrician about their panel, the first call usually carries a mix of things. Some callers have a specific reason: a renovation, a new appliance, an EV charger they're planning, a home inspection that flagged something. Others just know the lights flicker or a breaker keeps tripping and they're worried. The office has to sort all of that, gather an address and some basic details, and work out what kind of visit makes sense.
An app or web flow can take some of that load. It can't replace the electrician's judgment, and it should be designed to make that obvious. The aim is narrower: arrive at the first conversation with the basics already in hand, so the call is about the customer's situation rather than spelling their street name.
There's also a safety point that shapes the whole flow. Some customers who reach for a quote form actually have an urgent problem: a burning smell, a hot panel cover, sparking. A form is the wrong tool for that moment. The design has to catch it.
The constraints: what the flow can and can't ask
Before sketching screens, I write down what the contractor wants to know, what customers can reasonably answer, and what nobody should be asked to do.
Customers aren't electricians. Many won't know their panel's age, capacity or brand, and they shouldn't be asked to open anything to find out. Questions have to be answerable from the outside: "Do you know roughly how old the house is?" works; anything that sends someone poking at equipment does not.
Photos help, with limits. A photo of the closed panel from a step back, or of the label on the door if it's easy to see, can help the office prepare. The prompt should say clearly not to remove covers or touch anything. I phrase it as "only if it's easy and safe to see" and make the step optional.
The contractor decides what's needed. The flow must never suggest an upgrade, replacement or repair. It collects the customer's reason and lets the electrician work out the rest.
Location and permits are the contractor's job. Panel work commonly involves permits and inspections, and the details vary by place. The app can mention that the contractor will explain what applies; it shouldn't try to answer that itself.
The people filling it in vary a lot. Panel questions come from first-time buyers, landlords, and people who've lived in the same house for decades. Large tap targets, plain labels and readable contrast help all of them. I test the flow on an older phone with the text size turned up, because that's where cramped layouts fall apart first.
The decisions, in the order I'd make them
Here's the order I'd build it in, with the reasoning for each.
1. The urgent exit, first
The very first screen asks whether anything looks or smells unsafe right now. If the answer is yes, the flow stops and shows a large call button for the contractor's line, with plain wording advising the customer to contact the electrician or emergency services, and nothing else. No form, no photos. This screen is short to build and the most important one in the app.
2. The reason for the request
Next, a single question with a handful of tap-sized options: renovation or addition, new appliance or charger, inspection or insurance note, flickering or tripping, "not sure, I'd like someone to look." That last option matters. Plenty of people don't know why they're calling, and a flow that forces a category gets bad data.
3. Property basics and contact
Address, contact details, best times to reach them, and whether they own the home. Keep it to what the office actually uses. Every extra field costs completions.
4. Optional photos and notes
One photo slot with the safety wording above, and a free text box. Then a summary screen the customer can review before sending.
Comparing the ways to capture the request
There are a few ways to structure the request, and the right one depends on the contractor's office.
| Approach | Steps for the customer | What the office gets | Who it suits |
|---|---|---|---|
| Single short form | Low | Contact details and a free text note | Small offices that call everyone back anyway |
| Guided steps (reason, basics, photo) | Moderate | Structured reason, address, optional photo | Busy offices that triage before calling |
| Request plus booking slot | High | All of the above plus a proposed visit time | Contractors with a predictable schedule for estimate visits |
On most projects I've quoted, the guided version is the sensible middle. The booking slot sounds attractive, but it only works if the office can honor those times reliably, and that's a business question before it's a design one.
What to watch after it ships
The first few weeks tell you a lot. Ask the office which fields they actually read and which they ignore, then remove the ignored ones. Look at where people drop out of the flow; if it's the photo step, make it more clearly optional or move it after the contact details so the request still arrives.
Check the "not sure" option. If most requests land there, the reason list probably uses trade language customers don't recognize. Rewrite the labels in the words people use on the phone.
Keep an eye on the urgent exit too. If people tap it often, that's not a design failure, it's the flow doing its job. Make sure the office knows those calls are coming from the app so they can answer them quickly.
Finally, look at what happens after a request is sent. A customer who hears nothing for a day will phone anyway, and then the office handles the same job twice. A short confirmation that says when to expect a call back, in words the office agrees with, removes most of those duplicate calls.
And review the wording with the contractor every so often. Services change, and the flow should keep matching what the company's own pages say. That consistency is a large part of why customers trust the form enough to fill it in.
What I'd put in the estimate on Monday
If this brief arrived on Monday, my estimate would split the work into "do now" and "later." Do now: the urgent exit, the reason question, contact and address, the optional photo, a summary screen, and a clean handoff into whatever the office already uses for leads. Later: booking slots, status updates, and any customer accounts.
I'd also put one meeting in the estimate that people tend to skip: an hour with the person who answers the phone. They know exactly which questions waste time and which answers matter, and they'll shape the reason list better than any workshop. Then I'd build the first screen, the one that tells people when not to fill in a form at all.
Release notes
- Added: an urgent exit screen first, with a single call button and no form.
- Added: a "not sure, I'd like someone to look" option in the reason list.
- Changed: the photo step is optional and asks only for what's easy and safe to see.
- Fixed: reason labels rewritten in the words customers use on the phone.
- Dropped: any wording that suggests what work a home needs.
Keep reading

Dark mode done properly: contrast, color and images
How to build a dark mode that holds up: layered surfaces, brand colors that don't glare, contrast checks, images, icons and a test routine for both platforms.

Design systems for small app teams: start smaller than you think
How a small app team can build a design system that lasts: tokens first, a dozen components, notes in the design file, clear names and a first month plan.

App store screenshots that explain the app in five seconds
How to plan app store screenshots that work at search size: what the first three must show, how to write captions, and how to handle languages and dark mode.