Ideas · Building a practice · Field note · 3 min read
Your demo doesn’t need a paid service until a client signs.
Build each connection as a socket with an honest Not connected status. The client brings the plug, and their own account.
Concept · ideas and illustrations here are explorations, not deployed products or measured results.
“Should we sign up for the contact centre platform so the demo looks real?”
And the text message service. And the email service. And the automation tool. And a cloud account, just in case.
Before long, your demo has a monthly bill and no client.
I had this exact question in October, while designing how ClarisTXM, my independent BPO concept, connects to the systems a BPO uses every day.
The list is long. A BPO runs its client work across about a dozen kinds of system: voice, chat, written messages, case management, payments, workforce tools, file drops, sign-in, and more.
Every one of them has a vendor with a free trial and a credit card form. 😅
The temptation is to connect them all. A live connection looks impressive in a demo.
But think about what happens next.
Each trial expires. Each account holds test data you now have to look after. Each connection is set up on your account, not the client’s. And when a client finally signs, they’ll want their contact centre and their email service, under their contract.
You’ve paid to build something you’ll throw away.
So I made a rule for the demo: no paid service.
Instead, every connection is built as scaffolding. It has its entry in the connections catalogue, its connect form, and its place in the readiness check. And it shows its real state: Not connected.
A system becomes connected only when a client signs, using the client’s own account.
Build the socket. Let the client bring the plug.
The demo still runs on real things. A sample collections system with made-up data. Files. Free, self-hosted tools where they fit. Even the language model runs on a small computer I own, behind a password gateway, instead of on a paid plan.
And here’s the part I didn’t expect. The “Not connected” screens help the conversation.
A buyer sees exactly what will be connected, where their own key will go, and what the readiness check will look for. The talk turns to their systems. That’s a better conversation than “look how nicely our trial account works”.
If you build demos for your own practice, try this order.
- 1List every outside service the demo touches. Include the “just for now” ones.
- 2Ask whether the buyer would see the difference. If a file or a sample system tells the same story, use that.
- 3Build the socket for the rest. Catalogue entry, connect form, honest status.
- 4Connect on signature. With the client’s account, under the client’s contract.
Free isn’t really the point. Clarity is.
A demo that says plainly what’s connected and what isn’t is easier to trust. It’s also much easier to afford while you wait for that first signature.
Try this week
Write down every subscription your current demo depends on, with its monthly cost.
Next to each one, write what the buyer would lose if it showed “Not connected” instead.