The first chatbot a team builds is an adventure. The second one should be a process. The difference between those two states is documentation: not the kind that sits unread in a wiki, but a working procedure that another person could follow to produce a comparable result without the original builder in the room.
Most teams never make that transition. They build one bot, learn a dozen hard lessons, and then those lessons live only in one person's head. When that person leaves or moves on, the next bot repeats every mistake. A repeatable workflow captures the lessons as steps, checkpoints, and artifacts so the knowledge outlives any individual.
This piece lays out that workflow as a series of stages, each producing a concrete artifact you can hand off. The artifacts are the point. A stage that produces nothing reviewable cannot be handed off, and a process you cannot hand off is not repeatable.
Stage One: Intake and Scope Artifact
Every project starts with a request, and the request is always vaguer than it sounds. The intake stage converts a vague ask into a precise scope.
The Artifact It Produces
A scope document listing in-bounds questions, out-of-bounds questions, channels, and one success metric. This artifact travels with the project and is the reference for every later decision. Without it, scope drifts and nobody can prove the bot is done.
The discipline that makes this artifact valuable is forcing the requester to be specific. Vague requests survive in conversation but not on paper. When you write down exactly what the bot will and will not handle, disagreements surface immediately, while they are cheap to resolve. A scope document that took an hour to negotiate has already earned its keep by preventing a month of building the wrong thing.
Stage Two: Content Inventory
Before touching a platform, you inventory what the bot will know. This stage is research, not building.
The Artifact It Produces
A content inventory: a list of every source document, its owner, its freshness, and its status. This reveals gaps and contradictions early, when they are cheap to fix. It also assigns content ownership, which the operations stage relies on later.
Two findings always emerge from this stage and always matter. First, gaps: questions in scope that no document answers, which you must fill before building. Second, contradictions: two documents that disagree, which the retriever cannot resolve and which will surface as inconsistent bot answers. Catching both now, on paper, is the difference between a clean build and a bot that confidently contradicts itself in front of customers.
Stage Three: Platform Configuration
With scope and content settled, you configure the platform. Because the prior stages did the thinking, this stage is mechanical and fast.
The Artifact It Produces
A configuration record documenting the platform, the model, the integrations, and the settings chosen, with the reasoning for each. When someone asks six months later why a setting is what it is, this artifact answers instead of someone guessing.
The reasoning column is what makes this artifact valuable rather than just a settings dump. A record that says we chose this model because our conversations are reasoning-heavy and the cheaper model failed our test set tells a future maintainer whether the decision still holds. A record that just lists the model tells them nothing. Document the why, not only the what, and the configuration becomes a decision log you can revisit rather than a snapshot you have to reverse-engineer.
Stage Three-and-a-Half: Observability Setup
Configuration is the natural moment to ensure you can see what the bot does once it is live.
The Artifact It Produces
An observability checklist confirming that transcripts, retrieved content, escalation events, and abandonment points are all captured and reviewable. This artifact is short but load-bearing: the operating runbook in the final stage depends on this data existing. A bot built without observability is one you can launch but cannot meaningfully improve, so treat this as a gate, not an afterthought.
Stage Four: Conversation and Guardrail Design
This stage designs how the bot talks, how it handles uncertainty, and how it exits when it cannot help.
The Artifact It Produces
A design spec covering greeting, clarification behavior, grounding instructions, and escalation paths. Crucially it documents the failure paths, not just the happy path, so a future maintainer understands the bot's intended behavior under stress.
Stage Five: Test and Sign-Off
You attack the bot with a fixed test set and record the results. This stage is a gate, not a suggestion.
The Artifact It Produces
A test log: the adversarial inputs, the bot's responses, the failures found, and the fixes applied. The same test set runs again before every future change, which is what makes the workflow safe to repeat. The log is also the evidence that the bot met its bar before launch.
Stage Six: Staged Release Checklist
Release is a checklist, not a button. This stage moves the bot from internal to limited to full traffic with review gates between.
The Artifact It Produces
A release checklist with the cohort at each stage, the metrics to check before widening, and a rollback step. Because the checklist is written down, anyone can run a release, not just the person who did the first one.
The rollback step is the part teams forget and the part that saves them. Every release should specify how to revert quickly if the new version misbehaves, ideally back to the last version that passed the test log. A documented rollback turns a bad release from a crisis into a routine undo. Without it, a problematic change becomes a frantic debugging session in production while users feel the failure. Write the rollback before you need it, because the moment you need it is the worst moment to invent it.
Stage Five-and-a-Half: Acceptance Criteria
Between testing and release, the workflow needs an explicit bar that says the bot is good enough to ship.
The Artifact It Produces
A short acceptance record stating the thresholds the bot had to meet: the test set pass rate, the resolution target in piloting, and any must-not-fail behaviors. This artifact prevents the quiet erosion where a bot ships because the deadline arrived rather than because it met a standard. When the criteria are written down and signed off, done means something specific, and everyone can see whether the bot cleared the bar or merely ran out of time.
Stage Seven: Operating Runbook
The bot is live and now needs ongoing care. This stage produces the document that keeps it healthy.
The Artifact It Produces
A runbook specifying the weekly transcript review, the content refresh cadence, the owners, and the escalation procedure when something breaks. The runbook is what turns a launched bot into a maintained one, and it is the single most valuable artifact to hand to a new owner.
The runbook should also specify what to do when something goes wrong: who gets notified, how to disable a misbehaving bot quickly, and how to roll back a bad change using the test set from Stage Five. A maintained bot is not one that never breaks; it is one whose owner knows exactly what to do when it does. Writing that procedure down before you need it is what separates a calm response from a scramble.
Frequently Asked Questions
How is a workflow different from the playbook?
The playbook tells you which plays to run and when. The workflow turns those plays into documented stages with artifacts, so the process survives handoff. They are complementary: plays for decisions, workflow for repeatability.
Do small projects really need all seven stages?
Scale the depth, not the number. A small bot still benefits from a short scope doc, a content inventory, and a test log; they just take an hour each instead of a day. Skipping stages entirely is how small projects accumulate the same mess as large ones.
Who maintains these artifacts over time?
The operations owner named in the runbook. Artifacts that nobody owns go stale, which is why the runbook assigns ownership explicitly.
What if our platform changes?
The scope, content inventory, design spec, and test log are platform-independent and carry over. Only the configuration record is platform-specific. A documented workflow makes platform migration a known quantity rather than a rebuild.
How do we know the workflow is actually repeatable?
Have someone who did not build the first bot follow the artifacts to build the second. Where they get stuck reveals which artifact is too thin. Repeatability is something you test, not assume.
Key Takeaways
- A repeatable workflow turns one-off lessons into documented stages that outlive any individual.
- Each stage must produce a concrete, reviewable artifact, or it cannot be handed off.
- Scope, content inventory, and design specs are platform-independent and survive migrations.
- The test log and its fixed input set make future changes safe to repeat.
- The operating runbook, with named owners and cadences, is the most valuable artifact for a new maintainer.
For the decisions inside each stage, see Shipping a Production Chatbot: An End-to-End Operating Manual. To clear up misconceptions before you start, read What People Get Wrong About Chatbot Build Platforms and The Chatbot Platform Questions Buyers Actually Ask. For how this process may evolve, see Where Conversational AI Tooling Is Heading Next.