The Scope Creep Pattern Specific to Conversational AI Projects

Normal scope creep looks like a client adding a new feature request. Conversational AI scope creep looks like a client discovering, one conversation at a time, that the bot can't handle a case they never thought to mention during scoping — and each one feels small enough to just ask for, because it's phrased as "can it also handle..." rather than "build a new feature."

The pattern is specific to this kind of project because the surface area is effectively unbounded. A form has a fixed number of fields. A chatbot has every sentence a customer might ever type, and the client only discovers the shape of that surface area after launch, one weird input at a time.

You can scope a form. You cannot scope "everything a customer might say," and pretending otherwise is where the engagement quietly turns into unpaid work.

How I scope these now

• Define the covered intent set explicitly in the contract — not "handle customer support" but a named list of intents, with everything outside it routed to a fallback, not silently handled worse.
• Price a post-launch refinement window separately from the build, since the real intent gaps only show up with real traffic.
• Set an explicit threshold for what counts as a new intent category (billable as a change) versus a tuning tweak to an existing one (covered by the refinement window).
• Show the client real transcripts, not demo scripts, before they sign off — demo scripts hide the long tail that production traffic will expose immediately.

None of this stops the discovery process — you genuinely cannot know the full intent surface before launch, no matter how much discovery you do upfront. What it stops is the discovery process from being free labor. Once the covered intent set is named in writing, "can it also handle refund requests from a third-party reseller" is clearly a new line item, not a bug report, and that distinction is the entire difference between a profitable engagement and a slow bleed.