Business requests, in flow.
My role
Product design · Android · Frontend · Workflow correctness
01
Small service teams receive requests across apps, then manually decide who should handle them and when. Relay gives each request a structured place and a clear next step.
On-device intake classifies cleaning, repair and site visits. Seven weekday policies use the appointment date, working hours and assigned team. Urgent or uncertain requests stay available for human review.
The owned scheduling reference has no appointment-creation API. After an operator requests a booking, Relay fills its visible form and verifies the exact stored receipt. All demonstration requests are fictitious.
▶
02
Real product views, without mockups or stock imagery.
03
Selected intake
Explicit notification sources and consent; local structured data.
Weekly policy
Appointment weekday, service, working window and team.
Review workspace
Compact inbox, editable details and a bounded activity history.
Verified action
Reserve once, operate the owned form, match the receipt.
04
05
Selected request content stays on the device. The MVP has no cloud account, telemetry or Android Internet permission.
Some authorized legacy systems expose a usable form without a booking API. The reference demonstrates this boundary with a real form, not a simulated success flag.
Only an exact matching receipt counts. A click, conflict or interrupted attempt cannot silently become a booking.
06
07
08
A real Android notification produced a structured request and a confirmed native appointment. A second overlapping attempt was rejected without creating another appointment.
Who this is relevant for
For small service businesses that need an authorized request-routing workflow and a carefully scoped scheduling integration.
I can design and build a solution around your workflow, team, and business goals.