← Back to Work

Servidos

User flow · Marketplace · Launch

Designing launch-critical conversion flows for a two-sided service marketplace

Ask ChatGPT about this projectOpens ChatGPT with a starter prompt

TL;DR
I helped Servidos clarify its launch-critical marketplace and conversion flows so customers could request services faster, providers could reach earning moments sooner, and trust requirements appeared closer to user intent.
Role
Product Design Lead
Company
Servidos
Status
Client product · Early-stage launch
Timeline
3 months
Focus
Marketplace UX · Conversion flows · Mobile product design · Trust systems

Marketplace tension

Servidos needed to launch a two-sided marketplace where both sides had different motivations and different trust barriers.

Customers wanted to solve urgent home-service problems quickly.

Providers wanted access to real earning opportunities before investing time in setup and verification.

The business needed verification, payment clarity, reviews, fraud prevention, and operational control — but placing those requirements too early created abandonment risk before users reached the marketplace’s core value.

My role was to help decide where friction was necessary, where it was harming conversion, and how the product could guide both sides through the core marketplace loop with more confidence.

The diagram presents Servidos as a three-part marketplace connecting customers, the Servidos platform, and service providers.

Customers primarily need speed and confidence. Their goal is to solve urgent home-service needs quickly while feeling that the person they hire is trustworthy.

Providers primarily need demand and earning potential. Their goal is to see real, relevant jobs before investing significant time in account setup or platform participation.

Between these two groups, the Servidos platform supplies the mechanisms required to make the exchange trustworthy and operationally viable: provider verification, payment protection, customer reviews, fraud prevention, and operational control.

The diagram communicates the platform’s central role in balancing the needs of both sides. Servidos does not merely connect customers and providers; it reduces the uncertainty and risk that might otherwise prevent them from transacting.

The Challenge

The challenge was not simply that the product had friction. It was that some trust requirements appeared before users had enough motivation to complete them.

Customers could be blocked by account creation before submitting a request. Providers could be asked to verify before seeing whether real jobs were available. Long mobile forms, unclear offer states, and cancellation/payment moments also created risk around conversion.

The design question became:

How might we preserve the trust mechanisms the marketplace needed while moving friction closer to moments of user intent?

What I designed

I helped translate the launch strategy into the core marketplace and conversion flows needed for beta:

  • Customer request creation
  • Provider job discovery
  • Provider activation and verification
  • Offer submission
  • Offer comparison and acceptance
  • Payment / acceptance-state communication
  • Autosave and draft recovery
  • Completion, cancellation, and review states

I also helped shape the product’s launch-ready identity so the marketplace felt more credible and coherent.

Product insight

Under launch constraints, the better question was:

What is the minimum viable experience users can move through without hesitation or confusion?

That shifted the work toward the flows most likely to affect early marketplace liquidity: request creation, provider activation, offer comparison, proposal submission, recovery states, and acceptance moments.

The guiding principle became:

Friction should appear when users understand why it exists.

Mapping the marketplace loop

I mapped the end-to-end marketplace loop to identify where trust, motivation, and operational complexity affected conversion. The audit revealed six launch-critical risks across the customer and provider journey.

The diagram maps the Servidos marketplace journey across seven stages and identifies the main usability or product risk at each stage.

First, the customer creates a service request. Early account or setup friction could prevent the customer from completing and submitting that request.

Second, providers review the available jobs. Provider verification was necessary, but its timing in the journey needed improvement.

Third, providers submit offers. Because proposals can take time to prepare, longer proposal flows needed a save-and-resume capability.

Fourth, the customer compares the available proposals and accepts an offer. The scope of work and pricing needed a clearer structure so different offers could be understood and compared.

Fifth, the customer confirms the next step. Offer-acceptance and payment states needed clearer explanation so the customer would understand what they were authorizing and what would happen next.

Sixth, the provider completes the job. Notification behavior and cancellation states needed stronger definition so both parties would know about changes and understand their available options.

Seventh, the customer leaves a review, closing the marketplace’s trust loop and contributing information that can help future customers evaluate providers.

Together, the journey shows that trust depends on the entire service lifecycle rather than a single verification feature. Friction or ambiguity at any stage could interrupt the transaction.

Key design decisions

After mapping the marketplace loop, I focused the redesign around five decisions that affected launch readiness: onboarding timing, verification timing, offer comparison, acceptance/payment clarity, and provider effort recovery.

1 - Move onboarding friction to moments of intent

The original flow introduced major requirements before users had experienced enough value.

Customers could be asked to create an account before submitting a request. Providers could be asked to complete verification before seeing whether real jobs were available.

Evidence: the marketplace-loop audit showed early account/setup friction could block customer requests and that provider verification needed better timing. This led me to move account creation and verification closer to moments of clear intent.

I proposed moving these requirements closer to moments of clear intent:

For customers, account creation moved to the point where it unlocked receiving offers.

For providers, verification moved closer to offer submission and payment eligibility.

This preserved trust while making onboarding feel connected to a clear user goal.

Key changes in flows

The diagram compares earlier and redesigned flows for both customers and service providers.

In the earlier customer flow, the sequence was: need a service, create an account, fill in the request, submit the request, and wait for offers. Account creation occurred near the beginning, before the customer had described the problem or experienced much value from the platform.

In the redesigned customer flow, the sequence becomes: need a service, describe the request, preview the request, create an account to receive offers, and submit the request. Account creation is deliberately postponed until the customer has already invested in and reviewed the request and can understand why an account is needed.

In the earlier provider flow, the sequence was: sign up, complete verification, browse jobs, decide whether continuing was worthwhile, and submit an offer. Providers therefore had to complete verification before they could see whether the platform contained relevant demand.

In the redesigned provider flow, the sequence becomes: browse jobs, start a proposal, verify the profile to submit offers, submit the offer, and receive payments. Providers can inspect real opportunities and begin preparing an offer before verification becomes mandatory.

The redesign applies the same principle to both sides of the marketplace: delay high-friction setup until the user has seen relevant value and reached the moment when the requirement becomes understandable. Verification and account creation are retained, but moved closer to the actions that genuinely require them.

2 - Clarify the bidding and offer system

The offer flow was one of the highest-trust moments in the product.

Customers needed to compare providers quickly, but the decision could not be reduced to price alone. They also needed to understand who the provider was, whether they could trust them, what was included, and what would happen after accepting.

I structured the offer card around four questions:

  • Who is this provider?
  • Can I trust them?
  • What exactly are they offering?
  • What happens if I accept?

The revised card prioritized provider identity, rating, verification status, response time, quoted price, proposal message, included services, and clear next actions.

The goal was to make each offer feel like a service agreement, not just a price quote.

Offer card anatomy

The diagram explains the anatomy of a Servidos offer card using five information groups: provider identity, trust signals, quote, scope of work, and actions.

The provider identity section introduces Martin Velázquez as a bathroom specialist and includes his profile photograph.

The trust signals show that Martin is verified, has a rating of 4.9 from 218 reviews, and typically responds within 20 minutes. These signals help the customer evaluate credibility, reputation, and responsiveness before accepting the offer.

The quote presents a total estimated price of 45,000 Argentine pesos.

The scope-of-work section includes a short proposal explaining that the provider can install and connect the bathroom faucet using quality materials and provide a neat finish, leak testing, and cleanup. A structured checklist clarifies what is included: removal of the old faucet, installation of the new faucet, a 20-minute leak test, a 30-day warranty, and cleanup of the work area.

The available actions let the customer ask a question, view the provider’s full profile, or accept the offer.

The card brings the information needed for a hiring decision into a consistent structure. Instead of comparing offers through price alone or interpreting unstructured messages, customers can assess provider credibility, total cost, included work, guarantees, and available next steps in one place.

Clarify what happens after accepting an offer

Accepting an offer was a high-trust conversion moment.

Users needed clearer expectations around what happens next: when the job is confirmed, how payment is handled, when the provider is notified, and what happens if the job is cancelled or disputed.

I recommended clearer microcopy and state communication so accepting an offer felt like a protected next step, not a loss of control.

Suggested microcopy:

The provider will not be paid until the job is confirmed.

Reducing anxiety around payment authorization

The diagram explains how the Servidos payment-authorization flow is designed to reduce customer anxiety.

The payment lifecycle is presented in four steps. First, the customer’s payment is held securely. Second, the customer confirms that the agreed work has been completed. Third, the provider receives payment. If the service is cancelled or disputed instead, the payment is refunded or placed under review.

The accompanying mobile interface is titled “Authorize payment.” A protection message explains that the customer’s money is held securely by Servidos and released to the provider only after the customer confirms that the job is complete.

The payment summary shows a service total of 45,000 Argentine pesos, a Servidos fee of zero, and a total authorization of 45,000 Argentine pesos. The selected payment method is a Visa card ending in 4242.

The primary action is labelled “Authorize and confirm.” Supporting text beneath the button repeats the crucial condition that the provider will not be paid until the customer confirms the job.

The design distinguishes payment authorization from immediate payment to the provider. It explains where the money is held, what triggers its release, and what happens during cancellation or dispute. This makes the system’s protections and recovery paths visible at the moment the customer makes the financial commitment.

4 - Protect provider progress with autosave

Provider setup and proposal creation required detailed mobile forms. Losing progress during these flows could hurt provider activation.

I proposed autosave and draft recovery across long provider-side flows so providers could continue where they left off instead of losing work.

Key states included:

Saving...

Saved automatically

Draft restored

Continue where you left off

5 - Prioritize launch-critical UX over a full redesign

A full redesign would have improved the ideal product experience, but it risked delaying beta launch.

I helped separate the work into what needed to be solved before launch, what could improve after beta, and what should wait until the marketplace had more usage data.

This made shipping part of the design constraint.

P0 Critical before launch

  • Payment Clarity
  • Offer states
  • Form recovery
  • Cancellation states

P1 Improve after beta

  • Provider profiles
  • Review system
  • Saved providers
  • Messaging

P2 Scale later

  • Quality scoring
  • Repeat booking
  • Dispute management
  • Analytics

Outcomes

The project gave Servidos a clearer UX foundation for beta launch.

Post-launch context: Servidos subsequently reported ~10% week-over-week traffic growth. This is a company-level metric and is not presented as a causal measure of my design contribution.

The work clarified how customers enter the marketplace, when providers encounter verification, how offers communicate trust, how acceptance/payment states are explained, and which UX improvements were critical before launch.

The main outcome was decision clarity: the founder had a sharper product path for launching the marketplace while preserving trust, improving conversion flow, reducing harmful friction, and avoiding a full redesign delay.

The work also helped establish a launch-ready visual identity foundation for the product.

Reflection

Servidos taught me that early-stage product design is not about designing the most complete version of a product.

It is about identifying the smallest set of decisions that make the product usable, trustworthy, and shippable.

The project pushed me to think beyond screens and into system behavior: when to ask for trust, when to reduce effort, when to preserve progress, and when to defer complexity.

The biggest lesson was that friction is not always bad. In a marketplace, some friction creates safety, some creates trust, and some protects the business.

The designer’s job is to decide where that friction belongs.

Next projectFaro