Deployment walkthroughField service & customer intake
The handoff has to work for the person receiving it.
A mobile service request connected to the team's existing lead sheet, with photos, retry protection and the notification the operator actually uses.
In briefTL;DR · 3 min read
- The business already had a lead sheet and a quoting process. The new intake needed to fit them.
- Our call confirmed email as his notification channel. My phone test caught a photo problem; he explained why his existing lead numbers had to survive.
- One test request arrived with both photos. Sending it again did not create a second customer record.
Evidence checkpoint: August 24, 2026
My part. I shaped the request form around the operator's existing sheet, tested it on my phone and worked through the photo and lead-number problems with him. I brought the call transcript and specific corrections into the build.
AI assistance. AI coding tools traced the spreadsheet formulas, implemented the corrections and helped test the timeout and retry behaviour.
- 1
Customer request
Service details and photos from a phone
- 2
Existing lead system
Validated row, native identifiers and linked photos
- 3
Operator action
Email notification and the familiar quoting workflow
Start with what happens after submit
We wanted someone who found the business on Google to be able to request a pool closing. The person handling enquiries needed the details and photos in the sheet he already used for quotes and invoices.
I asked for phone photos to be part of the request, then tested the journey with him. We checked where the files landed, how he would hear about a new enquiry and whether the new rows still worked with his system.
He explained what the numbers were for
The form was writing its receipt into his Lead ID column. I initially explained it as a way to recognise where the enquiry came from. He pointed out what I had missed: his lead and job numbers were used to generate quotes and invoices, and the new rows were breaking that sequence.
After the call, I checked the sheet and asked for the integration to preserve his numbering. The AI-assisted inspection confirmed that his formulas already did the job. We left those columns alone and stored the form receipt separately for retries, photo links and tracing a submission.
Technical lens
The receiver writes the intake columns while preserving the sheet's formula-backed lead, job and record-key fields. The immutable submission receipt remains the idempotency key. Replaying an accepted receipt returns success without inserting another lead.
The operator changed the design
I found the photo problem on my phone: I could select one image, but opening the picker again replaced it. I raised it on the call and asked for the selections to accumulate. The corrected form keeps up to four photos and lets the customer clear them.
He could open the shared photos, but asked how he would know when an enquiry arrived. He checked email regularly; he would not open the sheet every hour. We kept the existing email alert and corrected its lead-number labels and photo-folder link.
A slow upload must not become a duplicate lead
A cold submission with two photos completed in the sheet just after the original 25-second wait expired. The front end could report failure even though the request had arrived.
We extended the server wait to 45 seconds and retained the same receipt on retries. The longer wait helps the normal path; the receipt protects the business when a customer tries again.
In the August 24 controlled check, one request arrived with both photos and the lead system’s identifiers preserved. Sending the same request again returned success without adding another row.
Technical lens
The server validates the request before forwarding it to the spreadsheet receiver. The receiver handles the stored receipt, linked photo provenance and notification eligibility. Duplicate and synthetic submissions do not notify. This case describes the documented acceptance checkpoint, not a new live test.
What I had missed
I had treated the lead number as tracking information. To him, it was part of producing the next document. He knew something about the workflow that I needed to learn.
Testing together gave us specific corrections: keep his numbers, let phone photos accumulate and put the useful details in the email he already checks.
Evidence at a glance
| Check | Recorded result |
|---|---|
| Two separate photo selections | Both retained in the mobile intake |
| Synthetic production request | One lead, two photos, native identity preserved |
| Same receipt submitted again | Success response; no duplicate row |
| Synthetic notification | Intentionally not sent |
Based on the August 24 operator-acceptance and synthetic production checkpoint. Client names, contact details, real lead rows and provider identifiers are withheld. No attributable revenue result is claimed.
What to take away
The useful part of that call was finding what I had missed, then coming back with a fix we could check.
Discuss your workflow