01

The primary pain was the old app's poor UI — users just needed a cleaner, faster interface to do the same things.

The UI was almost irrelevant. The real pain was forced double data entry — every record typed in the field had to be retyped in the office. This single finding changed the entire project direction.

Real-time Salesforce sync. Single data entry point in the field. Whatever an agent records auto-syncs to the work order — no re-entry, no reconciliation.

02

All three user roles had completely different workflows — hence different navigation is required based on user roles.

All three user roles had similar workflows. A Sales Rep's job ends at signature. An Installer's starts there. A Technician's might loop back through escalation. One nav would have served none of them.

Role-based navigation at login. Each user lands on a landing page which displays the list of jobs for the day — work orders for reps, installers and service tickets for technicians. Hamburger menu adapts for dual-role users.

03

Document handling (photos, COCs, agreements) was a minor friction point — primarily a formatting issue.

The biggest source of data loss and trust breakdown in the org. Agents used personal WhatsApp for photos, paper for COCs, email for agreements — all outside the system. A technician in Orlando showed us a WhatsApp folder of job photos going back 6 months.

In-app document handling built into the job flow. E-signature, photo upload, and COC sign-off at the point of task — not as a separate step. Documents auto-attach to the Salesforce work order record.

Sell today. Build trust. Close the deal and schedule installation before leaving the driveway.

Core Needs:

• Commission visibility in real-time

• On-site quote generation

Arrive with the right materials. Install correctly. Leave with a signed COC and collected payment.

Core Needs:

• Accurate work order with materials list

• One-tap navigation to job site

• In-app photo upload and COC sign-off

Diagnose. Repair if possible. Escalate if not. Always document before and after.

Core Needs

• Work order details at a glance

• In-app supervisor escalation

• Fee waiver decision support

"I need to see my commission right now. I have no idea where I stand until end of month."

"The materials listed are often wrong. I arrive and I'm missing parts. The whole day shifts."

"If I can't fix it, I need the Install Manager. But there's no way to do that inside the app."

We built a hamburger menu that adapts based on role combination at login. For dual-role users, both the personal appointment view and the dispatch/office view are accessible without re-authentication. The navigation architecture was designed to accommodate future role expansions without requiring a structural redesign.

This is the kind of complexity that gets discovered in the field, not in a requirements document. If we had built purely from the initial brief — three personas, three flows — we would have shipped a product that didn't work for an entire subset of our users from day one. The field visit to Cleveland surfaced this on day three of research.

01

The original design

The payment screen we presented had been designed around the assumption that a customer pays via one method — Cash, Check, Credit, or ACH. Single selection, straightforward flow. It matched the brief and no one had flagged it as a problem.

02

The moment that changed it

During the stakeholder review, a Sales Manager mentioned offhand: "Sometimes customers want to put part of it on a card and pay the rest in cash — that happens more than you'd think." It wasn't a complaint or a formal requirement. It was a passing comment. We stopped and asked how often. The room confirmed it was regular — particularly for larger installations where customers were managing budgets.

03

What that meant for the design

A single-selection payment screen would silently fail these customers. The agent would either have to abandon the in-app flow, or tell the customer they couldn't split — potentially losing the sale. Neither was acceptable. The original design had no way to handle this and it wasn't on the roadmap.

04

The decision and the advocacy

We took this back to the team, made the case that a split payment flow was a core requirement — not a nice-to-have — and redesigned the screen to support multiple methods in a single transaction. The business approved it. Cash, Check, Credit, ACH, and Finance unified in one screen. Split payment supported with a live running total that validates before submission.