Concierge

Deliver the service by hand. No software, no automation, no curtain. You do the whole job manually for a handful of users, white-glove, and they know a human is doing it. The point isn't to hide the manual work. It's to learn whether the service is worth doing at all before you spend a dollar automating it.

The question it answers

Concierge answers one question. Is this service actually worth delivering?

That's a desirability question (whether people actually want the result), but a sharper version of it than a click. The cheaper demand tests only watch whether a stranger reaches for a button. People click to make a notification go away.

Concierge raises the cost of the yes. You don't ask anyone what they'd do. You deliver the real value, by hand, and watch whether the result is good enough that a real person rearranges their week around it. That's desirability you can trust, because it survived contact with real effort, theirs and yours. It tests value, full stop, not whether you can build cheaply or whether your pitch is convincing.

How to run it cheaply

"Cheap" here means cheap to you in code, not cheap in your hours. You're spending your time so you don't have to spend your money. Run it like this.

1. Pick the riskiest belief: that the service produces a result people actually want. If you're sure people want it and unsure you can build it, this is the wrong tool.
2. Recruit a handful of real users. Five is plenty. You're learning, not scaling, and doing this by hand for fifty would bury you.
3. Write down the audience, the success number, and the end date before you start. This is the one discipline the whole catalog leans on, and concierge is the easiest place to skip it, because you're so busy doing the work by hand that you forget to define what winning looks like. Name the number first.
4. Deliver the service manually, in the open. The user knows you're a person doing this by hand. Then read two things against the number you wrote down. First, did the result clear the bar you set. Second, did they keep showing up, rearranging their week around the work instead of drifting off after the novelty. The result clearing the bar tells you the value is real. People sticking with it tells you the value is worth coming back for. Then decide.

The minimum version is exactly that. Five users, your own two hands, a number set in advance, a deadline. No app, no model. If the manual version produces a result nobody wants, no amount of engineering was going to save it, and you found that out for the price of a few weeks of your attention.

A worked example

The cleanest concierge run in this playbook is the late-paying-customer worked example in Part 04: two people hand-send reminder emails from a shared inbox to learn whether an easier way to pay moves the day an invoice gets paid. No software, two humans doing the job by hand. Go read that one when you want a full concierge run end to end. Here's a smaller one to show the move in a different shape.

Picture a hunch that job seekers would pay for hands-on networking coaching. The obvious instinct is to build the platform: the dashboard, the message templates, the tracking. Don't. You don't yet know the coaching itself produces a result anyone wants.

So run it by hand. For three weeks, you personally coach five people. You build their outreach strategy with them, give feedback on every message before they send it, track every reply. The cost you're asking of them isn't money here. It's real effort and weeks of showing up, a sharper signal than a card swipe at this stage.

Set the number before you start. Say a 70% response rate to their networking messages, against a typical rate closer to 30%. (Both numbers are illustrative, the kind of starting benchmark you'd give a student, not a research finding. Write your own real target down before you launch.)

If the response rate jumps and the people stick with the work, you've got evidence worth building on. And concierge pays double here. You learned exactly which parts of the service are worth automating, because you just did every one of them by hand. The manual run isn't only a test. It's the spec for the build.

When to reach for it, and when not

Reach for concierge when the service is mostly human work anyway, and value is the open question. Not "will they click," but "is the result good enough that they'll come back." If your idea is really "a person does a valuable thing for someone," you can be that person tomorrow, for free, and learn more in a week than a quarter of building would tell you.

Don't reach for it when the question is something else:

• If you need to know whether they think it's automated, that's a Wizard of Oz test, where it looks automated but a human is secretly behind the curtain. The user knowing a human is involved is the whole point of concierge. The user not knowing is the whole point of Wizard of Oz.
• If you've already proven people want the result and now you need to know if they'll pay, climb to a pre-sell and ask for the money up front. Concierge proves the value. Money proves the willingness to spend on it.
• If the question is "can they use the interface" or "does the screen make sense," you want a prototype, not a concierge. Match the tool to the question.

That's the rule underneath the whole catalog. There's no best experiment. There's the cheapest one that answers the question you're actually asking. Concierge is the cheapest one when the question is whether the service is worth delivering at all.

The taxonomy behind this page comes from Testing Business Ideas by David Bland and Alex Osterwalder. Credit where it's earned.