Which Marketplace Operations Can Stay Manual in an MVP?

Manual marketplace MVP operations can include matching requests, checking provider profiles or resolving exceptions. Keep a step manual when an operator can perform it reliably and the product records its status. The dangerous shortcut is invisible work that only the founder knows has happened.

Start from the complete transaction map. Distinguish the decision from the mechanism that records it. A person can choose a provider while software records who was chosen, when the invitation was sent and what the buyer is waiting for.

Write an operator runbook for one queue

Field	Illustrative matching queue
Entry condition	Buyer submitted a complete request
Evidence to inspect	Category, required date and availability
Allowed action	Invite an eligible provider
Recorded result	Provider, invitation time and request state
Exception	No eligible provider found
Customer message	Awaiting an operator decision
Review owner	Named pilot operator

Ask someone other than the founder to run a request from this table. Every question reveals a missing rule or access gap. Update the runbook before adding requests. A process that cannot be handed to another person is not ready to be handed to software.

Calculate capacity from handling steps

Use an illustrative workload of 20 requests per week. If completeness checks take four minutes and matching takes eight, the initial workload is 20 × 12 = 240 minutes. Five requests needing ten-minute exception reviews add 50 minutes. Total handling is 290 minutes, or four hours and 50 minutes.

Keep waiting in a separate column. A provider replying tomorrow creates delay, not a full day of labour. Conversely, five-minute follow-ups consume capacity even if the request looks unchanged. Record the number of touches as well as total handling time.

Choose a review trigger based on the hours your operator has available. Reserve time for exceptions instead of planning at the best-case average. This is a capacity rule for your pilot, not an industry benchmark.

Make the manual step visible to both sides

Check what the buyer sees after submitting and while the operator is absent. Show the actual next step. Do not display a successful automated match when nobody has matched the request.

Record operator actions in the transaction history. If a provider changes manually, subsequent screens and reminders must use the current assignment. Otherwise a later automated message can contact the wrong provider using an old state. Test reassignment while a reminder is pending.

Automate a repeated rule with its exceptions

Group operator notes by reason for intervention. A repeated eligibility check with stable inputs is a candidate for automation. Negotiating a different service for each request may call for a better category definition or a continued service role.

Replay recorded requests against the proposed rule and compare its decisions with the operator’s decisions. Keep rejected and ambiguous cases. Investigate disagreements before choosing which answer is correct. The resulting runbook, workload calculation and replay examples describe what to automate and when the system must return work to the operator.

Bring the pilot queue and its handling notes. We can identify the repeatable step worth automating next. Discuss the first release with Adamant Code.