guides
How to Structure a Contract for a Custom Chatbot Development Project
A vague chatbot contract leads to scope creep and unpaid revisions. Here's exactly what clauses to include so payment, scope, and ownership stay locked down.
The client wants "just one more small tweak" for the fourth week in a row. You've already delivered the bot, invoiced for it, and moved on to the next project — except you haven't, because the contract never defined what "done" actually meant.
This happens constantly in chatbot development because the deliverable feels simple ("just a bot that answers questions") but the scope is actually elastic. Every integration, every edge case, every "can it also do X" request either falls inside your contract or outside it. If your contract doesn't say which, you're doing free work.
What clauses does a chatbot development contract need?
A solid custom chatbot contract needs at minimum 7 core clauses: scope of work, deliverables and acceptance criteria, payment schedule, revision limits, timeline with milestones, IP/ownership terms, and post-launch support terms. Miss any one of these and you're negotiating after the work is already done — which is the worst possible time to negotiate.
Think of the contract as the thing that answers every disagreement before it happens. If a dispute can only be resolved by asking "well, what did we agree to?" and the answer isn't in writing, you've already lost leverage.
How do you define scope so it can't quietly expand?
Scope creep is the single biggest killer of margin on chatbot projects. The fix isn't vague language like "build a support chatbot" — it's a numbered list of exactly what the bot does and doesn't do.
List every conversation flow by name. "Order status lookup," "refund request," "FAQ fallback" — not "customer support functionality."
Name every integration explicitly. CRM sync, payment gateway, specific API endpoints — anything not named is out of scope.
Cap the number of intents or flows included in the base price. A common structure: up to 15 defined intents included, additional intents billed at a fixed per-intent rate.
Define what "revision" means versus "new feature." Fixing a broken flow is a revision. Adding a flow that wasn't in the original spec is a change order.
Attach the requirements document as an exhibit. The contract should reference it directly, not just describe the project in prose.
If you haven't already nailed down the requirements in writing before drafting the contract, do that first — see how to draft a requirements document for a client's Telegram bot build. The contract should point back to that document as its source of truth for scope.
How many revision rounds should you include?
Most chatbot contracts include 2-3 rounds of revisions within the base price, with each additional round billed separately at an hourly or fixed rate. Unlimited revisions is a phrase that should never appear in a contract — it's an open invitation for the project to never end.
Define a revision round concretely: the client reviews the delivered bot against the agreed spec, submits feedback in a single consolidated document within a set window (5-7 business days is typical), and you implement fixes within an agreed turnaround. Feedback submitted piecemeal over weeks doesn't count as "one round" — say so explicitly.
How should payment milestones be structured?
A common and fair structure for chatbot projects splits payment into three or four milestones tied to concrete deliverables, not calendar dates:
Deposit (30-50%) due at signing, before any work starts. This filters out clients who aren't serious and covers your time if the project stalls early.
Mid-project milestone (25-30%) due when the conversation flows are built and testable in a staging environment.
Pre-launch milestone (10-20%) due once the client approves the final tested version.
Final payment (remainder) due at launch or handoff, with a defined grace period (net 7-15 days).
Tie every milestone to a specific, verifiable deliverable — not "week 2" or "week 4." Calendar-based milestones invite disputes about whether you actually hit them; deliverable-based milestones don't.
Before you hit that pre-launch milestone, you'll want a proper QA pass — see how to test a chatbot conversation flow before client delivery and how to set up a staging environment for a Telegram bot before launch for the process that should sit right before that payment gate.
Who owns the bot, the code, and the data after launch?
IP ownership needs to be explicit, not assumed. The default in most freelance/agency contracts is that the client owns the final deliverable once paid in full — but "the deliverable" needs a precise definition.
Custom code and conversation flows built specifically for this client typically transfer to the client on final payment.
Reusable frameworks, templates, or internal tools you built before this project (or plan to reuse across clients) should stay yours — carve this out explicitly, or you'll be rebuilding your own toolkit from scratch every time.
Third-party platforms and licenses (the CRM, the hosting, any paid API) remain owned by their respective vendors — the client is licensing usage, not buying the platform.
Client data collected through the bot belongs to the client, full stop. Say this explicitly, especially if you're handling anything sensitive.
What happens after launch — who's on the hook for bugs?
Define a bug-fix warranty period separate from any ongoing support retainer. A typical structure: 14-30 days of free bug fixes after launch for defects in features that were part of the original scope, with anything beyond that (new features, third-party API changes, ongoing maintenance) billed under a separate support agreement.
This is also the point where you should define the handoff process itself — who gets admin access, who gets documentation, and how the client's internal team takes over monitoring. If you haven't mapped that out yet, how to hand off a finished chatbot project to a client's internal team covers exactly what to include.
If you're running the bot's ongoing operations and lead tracking through your own CRM stack rather than handing everything off cold, make that visible in the contract too — including who has access to conversation data and analytics dashboards during and after the engagement. Setting up analytics to track chatbot conversion rates for a client is worth reading before you write that clause, since it determines what data ownership actually means in practice.
Should the contract mention the tech stack and platforms used?
Yes — name the specific tools, not just "a CRM" or "an AI model." If you're building the bot on Telegram and managing leads through a CRM layer, name both. This protects you if the client later claims they expected a different platform, and it protects them by giving them a clear picture of what they're dependent on.
If your workflow includes managing the Telegram side through CRMChat, it's worth noting in the contract that lead data and conversation history are stored there during the engagement. CRMChat's help center documents the setup process if the client wants to review exactly what that involves before signing.
What should a termination clause cover?
Every contract needs an exit ramp for both sides. Cover these points:
Notice period — typically 7-14 days written notice to terminate without cause.
Payment for work completed — the client pays for all milestones completed up to the termination date, prorated if mid-milestone.
Kill fee for early termination — a flat fee (often 10-20% of remaining contract value) if the client terminates without cause after work has started.
Return of materials — what code, access, and documentation get handed over on termination, regardless of reason.
Without this clause, an early termination becomes a negotiation from scratch — exactly when you have the least leverage and the most sunk cost.
Frequently overlooked clauses worth adding
Confidentiality / NDA terms — especially if the bot touches customer data or proprietary business logic.
Third-party API cost pass-through — if the bot depends on a paid AI model or messaging API, state clearly who pays those ongoing costs.
Change order process — a simple one-paragraph procedure for how new feature requests get quoted and approved, so "can you also add..." has a defined path instead of derailing the timeline.
Governing law and dispute resolution — even a single sentence naming jurisdiction saves real money if things go sideways.
A contract this detailed can feel like overkill for a "simple bot" — until the third scope-creep request lands in your inbox. The goal isn't to make the client feel micromanaged. It's to make sure every future disagreement has an answer already written down.
