Concierge test (concierge MVP)
Before you build anything, do the service yourself for a few people and see whether it actually helps.
- Time
- 60 min
- People
- 2–4
- Kind of work
- Test
In short
A concierge test is a way to learn if a new service is worth building. Your team delivers a small version of it by hand, openly, to a few users who agree to take part. You measure whether it solves their need and record every step, so you know what repeating it at scale would take.
What it is
The name comes from a hotel concierge, who handles each guest's request personally. In a concierge test, a team member does the same: they take a real user's need and meet it directly, by phone, in person or through simple tools like email and spreadsheets. The user knows a person is helping them. Nothing is automated yet.
This is the opposite of building first and hoping people come. You start with the outcome and work backward. Because you do every step yourself, you learn which steps matter, which ones users never notice, and where the real effort sits. You also find out quickly if the service does not solve the need at all, before anyone has written a specification or signed a contract. Start-ups often call it a concierge MVP, and it adapts well to public services.
When to use it
Use it when
- You have a service idea and want to check that it really solves the need before building it.
- You do not yet know the steps or the rules the service will need.
- The target group is small enough to serve by hand for a few weeks, for example 5 to 20 users.
- Leaders want evidence of value before approving a budget.
Skip it when
- Delivering the service by hand would break a rule, a privacy commitment or a fairness principle.
- You already know the service works and the question is only about the technology. Use a Wizard of Oz test or a prototype.
- The team has no time to serve users personally and would deliver a poor experience.
You need
- Time
- 60 minutes to plan, then 1 to 4 weeks of manual service and a 60-minute review
- People
- 1 to 3 team members who will serve users, a decision owner, and 5 to 20 users who agree to take part
- Materials
- A short consent note, a simple log (a spreadsheet or notebook), a phone or email account for the service, and the worksheet
How to run it
Step 1: Name the user need and the outcome
Write the need in one sentence and the outcome you expect, for example 'Shop owners with several licences need to renew them on time; the outcome is no expired licence during the test.' Decide how you will tell whether the outcome was reached.
Step 2: Design the smallest manual service
Describe what a team member will do for each user, step by step. Keep it simple: a call, a reminder, a checklist, a form filled together. Leave out anything you would automate later. Write the limits: how many users, for how long, and what you will not do.
Step 3: Recruit users with consent
Invite a small group who have the need. Explain plainly that this is a short trial, that a person will help them, what information you will hold and for how long, and that they can leave at any time. Record each person's agreement.
Step 4: Deliver the service and log everything
Serve each user as promised. After every contact, log the date, what you did, how long it took, what they asked and anything that surprised you. The log is the main output of the test, so keep it complete.
Step 5: Measure the outcome
At the end, check the outcome you defined for each user. Ask each one a few short questions: Did this help? What would you have done without it? What was missing? Avoid asking whether they 'liked' it; ask what changed for them.
Step 6: Work out what repeating it would take
From the log, add up the hours, the information you needed, the decisions that required judgment and the steps that were the same every time. Mark which steps could be automated, which need a person and which you could drop.
Step 7: Decide and close the trial
Fill the worksheet: user need, manual service, outcome, learning. Meet the decision owner to choose: scale it, change it and test again, or stop. Tell participants what you learned and what happens next, and delete data you no longer need.
Worked example
A municipal economic development office notices that many small shops have three or four licences (trade, signage, health, civil defence) with different expiry dates. Shops often find out a licence has expired during an inspection. Two staff members run a concierge test with twelve shop owners in one district.
The need: 'Shop owners need to keep all their licences valid without tracking each date themselves.' The outcome: no expired licence among the twelve shops during the eight-week trial.
The manual service: a staff member visits each shop once, photographs the licence certificates on the wall with the owner's permission, and records each expiry date in a spreadsheet. Thirty days before any date, she calls the owner, explains what is needed and offers to fill the renewal form with them by phone.
Over eight weeks, nine renewals fall due. All nine are renewed on time. The log shows that each call takes about 12 minutes, but most of the time goes into explaining which office handles which licence. Three owners ask whether the dates could be aligned so they renew everything once a year.
The team concludes that reminders are easy to automate, but the explanation needs a single clear page per licence type, and aligning dates is a policy question. The director approves a larger trial with automated reminders and a combined guidance page, and sends the date-alignment idea to the policy team.
IllustrativeTips and mistakes
Tips
- Pick users who will tell you the truth, including people who are not already fans.
- Time every step. 'It took 12 minutes per call' is far more useful than 'it was manageable'.
- Agree an end date in advance so the trial does not drift into an unfunded service.
- Write down what you would never automate, such as moments that need empathy or judgment.
Common mistakes
- Serving users so generously that the result cannot be repeated at any scale.
- Forgetting to log, so you finish with good stories but no evidence.
- Running the trial without clear consent or an end date.
- Measuring satisfaction only, instead of whether the need was actually met.
What you walk away with
You walk away with evidence on whether the service meets a real need, a detailed log of what it took to deliver, and a clear view of which steps to automate, keep human or drop. That is the basis for a budget decision. If you scale, write a hypothesis test for a larger pilot and use a rollout checklist so the new service launches without gaps. If the technology is still uncertain, run a Wizard of Oz test next.
Questions people ask
What is the difference between a concierge test and a pilot?
A pilot usually runs a designed service, often with its technology, for a set period. A concierge test comes earlier: there is no system yet, and a person does everything by hand to learn what the service should be.
How many users does a concierge test need?
Usually 5 to 20. You need enough to see patterns, but few enough that a small team can serve each person well. If demand is much higher than expected, that is itself a useful finding.
Concierge test or Wizard of Oz test?
Use a concierge test when you want to know whether the service solves the need, and you are open that a person is helping. Use a Wizard of Oz test when you want to see how people use an interface that looks automated. Many teams run a concierge test first.
Tool card
The worksheet your team fills in, one box per field.
- User need
- Manual service
- Outcome
- Learning