A repair marketplace needs an order story everyone can follow

“Booked” means different things to the people in a service marketplace. To a customer, it means help is coming. To the person doing the repair, it may mean there is a request to accept. To the operations team, it means an order that can still fail, change hands, or need a refund. Putting the same green badge on every screen does not settle those differences.

In a Flutter service app we worked on, the order moves through pending, accepted, in progress, arrived, and completed. Cancellation is another terminal state. Payment has its own status: awaiting, paid, failed, or not required. Keeping those tracks separate matters. A technician can arrive before the customer completes a payment step; a payment can fail without erasing the work already done.

Start with permitted moves

The app's lifecycle policy expresses which transitions a technician can make. Pending can become accepted; accepted can become in progress; in progress can become arrived; arrived can become completed. A completed order cannot quietly go back to “on the way.” That sounds obvious until status updates are scattered across buttons, notifications, and admin tools. A single transition policy makes it easier to ask, “Is this move actually allowed?”

It also makes screen copy more precise. “Your request was sent” is a better message than “Your booking is confirmed” while the request is still pending. “Technician accepted” says something useful without promising an arrival time the system cannot know. Customer trust often comes from these small distinctions.

Location should solve a job

The same app has location permission, a location picker, booking map, technician search, and a request flow. That is a lot of surface area for one user decision: where should the service happen? We learned to treat location as an address and serviceability problem, not as a chance to ask for the broadest permission on first launch. The user needs to see why their location matters and have a way to correct it.

On the technician side, identity and approval matter as much as discovery. A polished listing is useful only if the person behind it is the right person to receive an order. The app separates customer and technician screens, registration, and admin review so the marketplace does not pretend every new profile is immediately ready to work.

The operational screen is part of the product

Marketplaces are often judged by the customer home screen. The difficult work appears in the queues behind it: a request waiting for acceptance, a failed payment that needs a retry, a completed job whose record must stay legible, an order someone needs to investigate. We want each role to see the next action and the current fact, without having to infer them from a generic status chip.

That is the practical test for a service marketplace. If a customer, technician, and operator can each answer “what happened, and what happens next?” from the same order history, the interface is doing its job.