Service Marketplace

Overview

This is a design-stage case. The product connects people who order a service with people who perform it, on web and mobile. I am not presenting it as a shipped marketplace. There is no public launch to point to.

Context and challenge

A marketplace fails when the order has no clear life. Someone requests work, someone accepts it, money and status change, and both sides need to know what happened. Location, ratings, and notifications add a timing problem: who is allowed to see what, and when.

My role

I treated this as product and system design: the participants, the order lifecycle, and the responsibilities of the web and mobile clients. Implementation is not claimed here.

Product thinking

Two sides share one order and do not share one interface. The customer needs to place, follow, and judge the work. The worker needs to accept, perform, and get paid. The system needs states that both sides can trust. A rating that appears before the order is finished is not a rating. It is noise.

System architecture

The model splits into the order and its states, the two participants, payment status, notifications, location, and reputation. Web and mobile are clients of the same order, not two products with two meanings of “done”. Payment providers, map providers, and the actual service topology are not chosen on this page, because those choices are not fixed.

Reflections

The useful work so far is the lifecycle, not a feature list. Payments, geolocation, and ratings are easy to name and easy to design badly if the order states are still soft. Until there is an implementation to review, this case stays in Research & Concepts.