A day that cannot lose a job

The technician app is built for a phone in daylight glare, sometimes with gloves on, sometimes with no signal at all. One screen holds today's route; each job opens into a checklist and a set of dispositions that move it from scheduled to complete without a second app or a paper backup.

Today's route

A technician sees their stops for the day in order, each one carrying the customer, the service, and anything flagged ahead of time - an unpredictable-duration job, a linked group of services at one property, a note left from the last visit. Opening a job is the only step needed to start working it.

The app is designed for a phone held outdoors in direct sun, sometimes with work gloves on. Targets are large, the layout is high-contrast, and dark mode is available for early-morning starts before sunrise. None of that is cosmetic - it's the difference between a technician who can actually use the screen standing in a driveway and one who gives up and reaches for a paper backup instead.

En route fires the customer text

Tapping "En Route" does two things at once: it marks the start of that job's clock, and it fires the customer's en-route text with a live ETA. The technician does not have to remember to notify anyone - dispositioning the job is the notification.

Before photos to start, after photos to complete

Moving a job to "In Progress" requires a set of before photos first - the job cannot proceed without them. Completing the job requires after photos the same way. Before-and-after video is also supported for jobs where a photo alone doesn't tell the story, capped to a short clip rather than an open-ended recording. Those photos travel straight into the customer's completion email; nobody has to attach them by hand later.

Requiring the photo at the moment the disposition changes, rather than as a separate step a technician might skip, is what makes the record trustworthy. It's not a technician's word against a customer's memory of what the property looked like - there's a photo timestamped to the visit itself, on both ends of the job.

A checklist that remembers the property

Every visit prompts a short cross-marketing checklist - things like whether the property has other services worth flagging. Each toggle remembers what it recorded last time at that property, so the technician is confirming what changed, not re-entering the same answers every visit. A flipped toggle can surface as an upsell lead in the office's reporting without anyone having to notice it by hand.

Completion notes that write the customer's email

At completion, a technician chooses from a library of preset notes - "everything looks great," "found and repaired," "found an issue we could not fix, photos included," and similar - plus a free-text field for anything specific to the visit. Both flow directly into the customer's post-visit email together with the photos, so what the customer reads matches what actually happened on-site.

Clock-out blocked until every job has an answer

A technician cannot clock out while any job assigned that day is still undispositioned. The blocking screen names the specific job or jobs still open, not a generic warning - so the fix is always obvious, not a mystery to track down at the end of a long day.

This one rule closes off the single most common source of billing errors: a job that was actually finished but never got marked complete, so it never became a billing candidate and never generated the next recurring visit. Blocking clock-out until every job has an answer means that gap gets caught the same afternoon, by the person who was standing at the property, instead of surfacing weeks later as a customer asking why nobody ever came back.

Offline queue

Every disposition, photo, and completion action is captured locally first and synced automatically the moment signal returns. A technician working in a low-signal area keeps working normally; nothing "spins" waiting for a connection, and nothing has to be re-entered once signal comes back.

Low-signal properties are common on real routes, not an edge case - a rural stop, a property tucked behind thick construction, a dead zone between two towers. An app that only half-works in those conditions pushes a technician back toward a paper workaround, and a paper workaround is exactly the kind of gap that turns into a missed disposition and a missed billing candidate later. Queuing locally and syncing automatically is what keeps the office's record complete no matter where the truck actually was that day.

Clock-in tied to the truck

A subsection of the same clock: clock-in is checked against the assigned truck's own location, using the GPS units already on your trucks - not a separate device or a manual location ping. Drive time home from the last job of the day is paid, and a reminder fires if the truck's location shows it back at base while the technician still hasn't clocked out.

Tying clock-in to the truck's own location removes a step a technician would otherwise have to do manually and removes a place where a clock-in could be logged from somewhere other than where the work actually happened. It uses location data the trucks are already generating for dispatch - nothing new to install, nothing extra for a technician to carry.