Field Operations Platform
A mobile platform that guides Starlink installation technicians through scheduling, on-site workflows, and job completion under real field conditions.
- Role
- Product Designer
- Timeline
- 2024 - Present
- Scope
- Technician mobile app: scheduling, installs, job completion
01/12·Overview
Context
A truck roll costs the same whether the install succeeds or fails.
Install Pros runs Starlink internet installations across residential, commercial, and mobile sectors. The unit economics are unforgiving: a truck roll costs the same whether the install succeeds or fails, and every clarification call routes through a small dispatch team.
The business needed technicians to complete more installs per day with fewer escalations. Not a portal, but an operating tool that holds the job's state so the technician doesn't have to.
The field is the spec
The hardest part of the spec is the field itself.
The interface is used standing, outdoors, often one-handed, in direct sunlight, between a ladder and a customer conversation. Sessions last seconds, not minutes: a technician checks the next action, then puts the phone away.
Connectivity is unreliable by definition: the customer is buying satellite internet because coverage there is poor. The product has to assume a dead zone at the exact moment of work.
01
Workflows survive the dead zone.
The customer is buying satellite internet because coverage there is poor — so the product has to assume no signal at the exact moment of work.
Every workflow is offline-first: progress, photo evidence, and completion are captured locally and reconciled when a connection returns. A technician never loses state or stares at a spinner mid-install — the app confirms the action and syncs later.
Trade-off accepted: More engineering complexity in local state and conflict resolution, accepted so the tool works where the job actually happens.
02
Installation runs as a recoverable state machine.
Installs rarely fail at step one; they fail in the middle — a blocked roof, a missing part, no signal.
The workflow models progress as discrete states a technician can complete, pause, annotate, or flag, and the flow knows how to resume from any of them. A deviation becomes structured data instead of a phone call to dispatch.
Trade-off accepted: Modeled states cost more design and engineering than a free-form checklist and constrain edge cases not yet mapped. We accepted that rigidity because recoverability was worth more than flexibility.
03
Trust is verified before the first job.
A stranger represents the brand on a customer's roof, so the network's integrity has to start at the door, not the install.
Access, identity verification, and onboarding were designed as one gated sequence: a technician proves who they are, then is personalized into the work — not dropped into a feature set. Dispatch can't assign a job to an unverified installer.
Trade-off accepted: A heavier first-run experience, accepted because a failed-trust install costs far more than a few extra onboarding minutes.
04
The pocket holds action; dispatch holds control.
How much job management actually belongs in a technician's pocket?
Job views were stripped to what a technician acts on: today's sequence, each job's state, and completion evidence. Assignment logic and exception handling stayed with dispatch, which kept the mobile scope shippable by a small team.
Trade-off accepted: Some technician autonomy — reordering jobs, self-assignment — was deliberately left out of the first release to protect operational consistency.
05
Payment closes the job, inside the job.
Where should a technician collect and confirm payment — a separate app, or the workflow that completes the install?
Earnings, payment capture, and payout status (Stripe, PayPal) live inside the job, not in a separate tool. The transaction becomes the natural last step of the work rather than an errand afterward, so nothing is left uncollected on site.
Trade-off accepted: Embedding payments widened compliance and integration scope, accepted because a job isn't done until it's paid — and splitting that across tools is where money and technicians get lost.
System & workflows
One pattern set, reused across every surface.
Screen patterns like status chips, action rows, and step headers were defined once and reused across scheduling, installation, and job views. The intent was economic: engineering builds from rules rather than mockups, and a technician never has to relearn what a color or a position means.
Designing with implementation in mind is what kept the product buildable: every new screen since has been assembled from the existing pattern set rather than designed from scratch.
Outcome
What the design made possible.
Technicians get a single legible next action in every state of a job. The scanning effort the old process demanded is gone from the workflow itself.
Off-script situations became structured states instead of dispatch calls, which is the difference between a tool and a phone tree.
Engineering ships new screens from the established pattern set without a design cycle per screen.
What I'd measure next
Completion time already moved — jobs close about 25% faster. The metric I'd still push to instrument is callback rate: it's the truest test of whether guided workflows prevent failures, not just speed them up. I'd also revisit keeping job reordering away from technicians; the consistency argument may not survive contact with experienced crews.
Next project
AgencyHub