Build a chatbot prototype: a scripted chat to test the flow and tone of your bot
Before a support bot or a booking assistant goes anywhere near customers, someone has to decide what it says, in what order, and what happens when it's stuck. A clickable chatbot prototype with scripted replies is the fastest way to test that with real people. Anticode can build one as a single-device app. No AI model runs inside it, so every reply is written by you, which for this stage is a strength.
Why script it first
Teams often start with the model and the platform and only later discover the hard questions: Which tasks should the bot handle at all? How does it greet someone who's angry? When does it hand over to a person? A scripted prototype forces those decisions into the open and lets people react to the actual words. It also makes the conversation reviewable by legal, support and brand people who would never read a prompt.
Map the conversation
Write the flows as a tree before you describe the prototype. For a delivery company's help bot:
- Greeting. "Hi, I can help with tracking, missed deliveries and returns. What do you need?" with three quick-reply buttons and a text box.
- Tracking. Ask for the order number; show a sample result for a valid one, and a helpful message for a mistyped one.
- Missed delivery. Offer to rebook with three sample slots, or explain the collection point.
- Returns. Check eligibility with two questions, then show the steps.
- Fallback. "I didn't catch that. I can help with tracking, missed deliveries or returns, or put you through to a person."
- Hand-off. What the customer sees when the bot passes them to a human, and what it says about wait times.
The fallback and hand-off steps matter most. A bot that loops on "I didn't understand" is the experience people remember.
What the prototype simulates
- Quick replies
- Buttons for the expected answers, which also keeps testers on the paths you scripted.
- Free text
- Simple keyword matching that routes typed answers to a branch ("refund", "money back" to Returns), with the fallback for anything else.
- Typing indicator and timing
- A short delay before replies so the pace feels like the real thing. Test both quick and slower pacing.
- Rich messages
- Cards for an order status, a carousel of slots, a link button.
- Personality settings
- A switch between two tones (say, formal and friendly) so testers can compare the same flow in both.
- Transcript
- The conversation saved in that browser, so you can review a test session afterwards on the same device.
Ask for any order numbers or customer details to be clearly sample data, labelled "Demo data" in the interface.
Describing it to Anticode
Paste the tree and set the scene: "A chatbot prototype for a parcel delivery company's help widget. Shown as a chat window over a blurred sample tracking page. Flows: greeting with three quick replies, tracking (sample order numbers in the format AB123456), missed delivery with rebooking, returns, fallback and hand-off to a person. Keyword matching for typed answers. A tone switch between formal and friendly. Typing indicator. Phone-sized and desktop layouts."
Run sessions with five or so people who match your customers. Give each a task ("your parcel didn't arrive yesterday; sort it out") and watch where they type something the script didn't expect. Those moments are your requirements.
What a real chatbot needs instead
Anticode apps run in a sandbox with no network and no AI inside the app, so the prototype can't do any of this:
- Understand open-ended questions. That needs a language model or an intent-matching service on a server.
- Look up real orders. It can't reach your systems; every answer is scripted.
- Hand off to a live agent. No connection to a help desk or live chat tool.
- Learn from conversations or report on them. Transcripts stay in the tester's browser.
For the real version, use a chatbot platform that connects to your help desk, or have a developer build one with an AI provider's API. The Next.js export gives a developer a TypeScript project with server routes and a database as a starting point, but it doesn't include an AI chat feature; that's for them to add. Either way, your scripted flows become the specification: the tasks, the wording, the fallbacks and the hand-off rules.
If what you actually need today is for customers to reach a person, a contact form that sends messages to you, and to Slack through a form connector, may do the job without a bot. A chat app prototype covers person-to-person messaging instead.
Questions people ask
Can the chatbot prototype use ChatGPT or Claude?
Not inside the app. The sandbox blocks all network access, including to AI services, so replies are scripted.
Can I put the prototype on my live website?
It's published as its own page, not a widget, and it can't be embedded in another site. Keep it for testing.
How many branches should a prototype have?
Enough for the three to five tasks that make up most requests, plus fallback and hand-off. Depth matters less than the edges.