A service marketplace can look like a simple funnel:
Request published
→ quotes received
→ quote accepted
That picture is useful only until real behaviour begins.
Several providers may respond to one request. Quotes can be revised or withdrawn. Customers and providers may speak outside the product. A site visit may happen before the final price is known. Quote acceptance can be recorded perfectly even when the work is never scheduled or completed.
This example shows how to design useful measurement without hiding those complications.
Start with the question and the unit
The team wants to understand:
Can customers obtain enough useful information to choose a service provider, and where does that process break down?
The primary unit is the eligible service request.
That choice prevents several common mistakes. A request can receive many quotes, but it still represents one customer need. Counting quotes as though they were successful customers would reward provider activity without showing whether another customer reached a choice.
The team also needs secondary units for diagnosis:
- customer account
- provider account
- quote
- quote version
- conversation
- accepted job
Those units can be related, but they should not be substituted for one another inside a metric.
Map the workflow before the events
| Element | Working definition |
|---|---|
| Customer intent | Find a suitable provider and agree to proceed with a service |
| Entry point | An eligible service request is published to providers |
| Actors | Customer, one or more providers, and the platform |
| Meaningful activity | Providers review the request; quotes are submitted, discussed, revised, compared or withdrawn |
| Digital completion | The customer accepts one recorded quote within 30 days of publication |
| Downstream outcome | Work is scheduled, completed satisfactorily and delivers the expected service value |
| Important gaps | Site visits, telephone conversations, off-platform agreements and work delivery may not be fully observable |
The 30-day completion window is a measurement choice, not a natural law. It should reflect the typical decision cycle and be reviewed for different service types.
The workflow may also end without acceptance for valid reasons. The customer may decide not to proceed, postpone the work, find that no provider is suitable or arrange the service elsewhere. A closed request is not automatically a failed product experience.
Select event evidence deliberately
| Event | Actor | What it makes observable | Important limitation |
|---|---|---|---|
service_request.published |
Platform | An eligible request became available under the publication rules | Does not prove that relevant providers saw it |
quote.submitted |
Provider | A provider submitted a quote for the request | Does not prove suitability or comparability |
conversation.message_sent |
Customer or provider | A message was sent through the marketplace | Excludes telephone and other off-platform discussion |
quote.revised |
Provider | A new version of an existing quote was submitted | Does not explain why the quote changed |
quote.withdrawn |
Provider | A previously available quote was removed from consideration | The reason may be missing or unreliable |
quote.accepted |
Customer | A recorded quote was successfully accepted | Does not prove that work was scheduled or completed |
job.scheduled |
Customer, provider or platform | A date or appointment was recorded | Scheduling may happen outside the marketplace |
job.completion_reported |
Customer or provider | An actor reported completed work | Does not independently verify quality or satisfaction |
Each record should carry the identifiers needed to connect it to the correct request, quote, provider, actor and version. The analytics event should not copy message text, addresses, telephone numbers or the complete quote record.
Define request-level metrics
Quote coverage within seven days
Question: Are eligible requests receiving any provider response quickly enough?
Eligible service requests with at least one active quote
within 7 days of publication
÷
Eligible service requests published in the cohort
The unit is the request, not the quote. A request with four quotes counts once in the numerator.
Multi-quote coverage within fourteen days
Question: How often do customers receive more than one recorded option?
Eligible service requests with at least two active quotes
within 14 days of publication
÷
Eligible service requests published in the cohort
This measures recorded choice, not quote quality. Two unsuitable quotes are not better than one suitable quote merely because the count is higher.
Time to first quote
Question: How long do customers wait before the first provider response?
Measure the elapsed time from service_request.published to the first valid quote.submitted for each request. Report a median and a useful distribution rather than relying only on an average, because a small number of very slow requests can distort the mean.
Requests with no quote need separate treatment. Excluding them from the time metric makes response speed look healthier than the complete experience.
Quote acceptance within thirty days
Question: How often does an eligible request lead to a recorded customer choice?
Eligible service requests with `quote.accepted`
within 30 days of publication
÷
Eligible service requests published in the cohort
Recent requests have not had the full 30 days to complete and should not be reported as final. Compare mature cohorts or label incomplete cohorts clearly.
Work-outcome reporting coverage
Question: How much of the accepted work has enough downstream evidence to evaluate what happened next?
Accepted service requests with a completion outcome reported
within the agreed follow-up window
÷
Accepted service requests old enough to have reached that window
This is a measure of outcome evidence coverage. It is not the same as a work-completion rate unless the reporting process is reliable and sufficiently complete.
Diagnostic measures are not success metrics
Some measures help the team locate a problem without representing value on their own:
- quote revisions per quoted request
- messages per active conversation
- quote withdrawal rate
- proportion of requests requiring a site visit
- requests closed without a recorded acceptance
- accepted quotes later cancelled or reversed
More messages may indicate healthy clarification or confusing requirements. More revisions may reflect productive negotiation or poor initial quote quality. These measures need context before anyone labels movement as good or bad.
A particularly misleading metric would be:
Accepted quotes ÷ submitted quotes
A marketplace that gives customers more valid choices could make this rate fall, because only one quote is normally accepted per request. The quote-level denominator answers a provider competition question, not whether customers successfully chose a provider.
Add dimensions that support a decision
Useful dimensions may include:
- service type
- geographic coverage area
- request entry route
- provider availability band
- number of active quotes available
- whether a site visit was required
- customer or provider tenure band
- workflow version
Show the denominator for each segment. A 100% acceptance rate based on two requests is not strong evidence, and small geographic areas may require aggregation or suppression for privacy and responsible interpretation.
Segment differences still do not explain themselves. Lower coverage in one area could reflect provider supply, request quality, seasonality, service mix or instrumentation gaps.
Combine event evidence with other evidence
The marketplace cannot answer every important question from event records.
| Question the events cannot answer well | Complementary evidence |
|---|---|
| Were the quotes understandable and genuinely comparable? | Customer interviews, usability testing or follow-up survey |
| Why did eligible providers decide not to quote? | Provider research, structured decline reasons and account conversations |
| Did customer and provider activity move off-platform? | Follow-up questions, support evidence and operational review |
| Did the accepted work happen and meet expectations? | Completion checks, quality assurance, customer feedback and complaints |
| Did customers feel confident enough to choose? | Research or a carefully designed confidence measure |
The event data provides the behavioural spine. Qualitative and operational evidence explains parts of the experience the product cannot observe directly.
Connect signals to decisions
| Signal | Possible decision or investigation |
|---|---|
| Low quote coverage | Review provider supply, matching rules, notifications or request eligibility |
| Slow time to first quote | Investigate provider awareness, request quality or operational response expectations |
| Strong quote coverage but low acceptance | Examine quote suitability, trust, comparability, pricing expectations or off-platform choice |
| High revision activity | Review requirement clarity, quote structure or the role of site visits |
| Acceptance recorded but weak outcome coverage | Improve scheduling, follow-up and completion evidence before claiming marketplace value |
| One area underperforms | Separate provider availability, service mix and instrumentation quality before changing the product |
The example works because the layers stay separate.
The workflow describes the customer and provider activity. Events record selected evidence. Metrics calculate patterns at the correct unit. Other evidence fills important gaps. Decisions explain why the measurement is worth maintaining.
Quote acceptance is a defensible digital completion point. It is not the final customer outcome. Keeping that distinction visible stops the marketplace from mistaking a recorded transaction for delivered value.