Executive Summary
- Binding checkpoints—not map themes—shape on-demand architecture.
- Instant versus scheduled, fixed versus quote, invite versus auto-assign are different control planes.
- Platform status is not real-world completion; evidence and confirmation close the job.
- Additional cost and cancellation need explicit customer approval paths.
- Offline and connectivity gaps require durable local state and conflict rules.
- Fill rates and SLA outcomes depend on supply density and ops staffing—not UI alone.
Binding checkpoints
On-demand products are not 'Uber-like maps.' The architecture is shaped by which checkpoints are binding: who may accept a job, who sets price, who approves changes, what evidence closes completion, and when payment captures.
Home services, beauty, and logistics-adjacent products share family resemblance but differ in SLA pressure, skill matching, and whether price is known upfront. Produce a lifecycle diagram before polishing mobile UI.
Separate platform state (requested, matched, en route, marked complete) from real-world service completion (work done, customer confirmed, evidence accepted). Confusing the two creates payout and dispute debt.
Status is not a workflow
A single status field that means different things to customer, provider, and finance will generate support debt. Prefer explicit stage objects with timestamps and actors.
Matching and pricing authority
Instant requests need availability, service area, skills, and capacity checks in near real time. Scheduled requests add calendars, windows, and no-show policies.
Fixed price is appropriate when the catalog is standardized. Quotation is appropriate when scope is uncertain. Mixing both requires clear transitions when a quote becomes a binding price.
Provider invitation versus automatic assignment changes fairness, SLA, and earnings expectations. Document whether providers can decline and how timeouts cascade to the next candidate.
Control-plane choices
| Feature | Choice | When appropriate | Primary risk |
|---|---|---|---|
| Auto-assign | Dense supply, standard jobs | Unfair load / low acceptance | |
| Invite / claim | Specialized skills | Slow fill / cherry-picking | |
| Fixed price | Known scope | Underpricing edge cases | |
| Quote then approve | Variable scope | Drop-off before acceptance |
Approvals and additional cost
Customer approval gates should be explicit for quotes, schedule changes, and additional costs discovered on site. Silent price increases destroy trust and create chargebacks.
Additional-cost workflows need itemization, photo or note evidence where useful, and a clear accept/decline path. Declined extras should not leave the job in an ambiguous paid state.
Cancellation policies differ by stage: before match, after match, after arrival. Encode refund and provider compensation rules as deterministic policy—not chat improvisation.
Completion evidence and payment
Completion evidence may include checklists, photos, signatures, or OTP. Customer confirmation may be required before payment release—or payment may capture on provider mark-complete with a dispute window. Choose deliberately.
Provider earnings should derive from settled job events, not from optimistic UI. Disputes freeze or claw back according to policy with audit.
What must remain deterministic: payment release conditions and earnings calculation. What can be automated: matching suggestions and ETA predictions—with humans owning irreversible money decisions when risk is high.
Request-to-payout spine
Support and connectivity
Support operations need visibility into stage history, actors, and money state. Without that, every ticket becomes archaeology.
Field apps face offline gaps. Define which actions queue locally, how conflicts resolve on reconnect, and what cannot be confirmed offline (for example, irreversible payment capture).
Human approval belongs on exceptions: large additional costs, safety incidents, and high-value disputes. Routine stage transitions can be automated within policy.
When this model is unsuitable
Full on-demand matching is unsuitable when supply is a small captive team that only needs scheduling—use a simpler dispatch calendar.
Quote-heavy workflows are unsuitable for highly standardized SKUs where fixed pricing would reduce drop-off.
If you cannot staff support for disputes and no-shows, do not launch complex multi-party money release. Narrow the product until ops capacity exists.
Failure modes
Failures include double assignment, jobs marked complete without evidence, payment capture before customer confirmation when policy required it, and earnings paid on disputed work.
Validate before build: service area rules, pricing authority, completion definition, and offline conflict policy. Audit stage transitions and money events.
Implementation checklist
Incomplete checkpoint design is a launch risk for on-demand products.
Lifecycle readiness
1Matching
- Availability & service area rules
- Invite vs auto-assign policy
- Timeout cascade
2Money & approval
- Fixed vs quote path
- Additional-cost approval
- Cancellation refunds
3Completion
- Evidence requirements
- Confirmation vs dispute window
- Earnings derivation
How Digital Elliptical helps
Digital Elliptical helps teams design on-demand and field workflows across mobile and backend systems—matching, quote/approval gates, completion checkpoints, and payment timing—without forcing one vertical template.
We do not guarantee fill rates, utilization, or SLA attainment. Outcomes depend on supply liquidity, ops staffing, and market conditions.
Main-Agent ownership (Prompt 6): Re-authored to separate platform state from field completion, expand pricing/assignment matrices, and strengthen offline and evidence requirements.