A well-structured chatbot brief is the single most important document in any AI chatbot development project. It defines scope, expectations, and accountability before a single line of code is written - saving time, budget, and frustration on all sides.
At Softomate, we review somewhere between 20 and 30 chatbot briefs every quarter. We have seen the full spectrum: a handful that arrive polished and precise, and far too many that are vague, incomplete, or built on assumptions the client has never actually tested. In our experience, poor briefs are the root cause of 60-70% of all project delays. Missed integrations, unclear escalation rules, undefined tone of voice - these gaps do not disappear once development starts. They multiply.
The UK AI chatbot market reached £420 million in 2024 and is projected to grow to £1.1 billion by 2028 (CAGR 27%). UK businesses deploying AI chatbots report average first-response time reduced from 4 hours to under 10 seconds. Customer satisfaction scores (CSAT) for AI chatbot interactions average 3.8/5 in the UK, compared to 4.1/5 for human agent interactions - a gap that narrows to under 0.1 when the chatbot handles only in-scope queries. 78% of UK adults have interacted with a chatbot in the past 12 months; 54% prefer chatbot interaction for routine enquiries outside business hours. UK chatbot abandonment rate averages 35% when response time exceeds 10 seconds. AI chatbots reduce UK customer support costs by an average of £8-14 per ticket deflected (versus £12-18 for human agent handling). UK businesses with AI chatbots report 23% higher lead capture rates from website traffic versus businesses using only contact forms. GPT-4o API costs for a UK business handling 1,000 chatbot conversations per month average £40-80/month in API fees.
The good news is that writing a solid brief does not require a technical background. It requires clarity about your own business: what problem you are solving, who your users are, and how success looks after six months of operation. This article walks you through the 10 things every UK business must define before chatbot development begins.
Chatbot projects at Softomate range from around £3,000 for a focused, single-channel lead capture tool to £25,000 or more for a fully integrated, multi-channel intelligent assistant. The difference in outcome between a project that starts with a clear brief and one that does not is enormous - regardless of budget.
| What a good brief includes | What is missing from poor briefs |
|---|---|
| Defined primary purpose with a single measurable goal | Vague objective such as 'improve customer service' |
| Named target channel(s) with deployment context | Assumption that the chatbot will 'just work everywhere' |
| Specific user persona with real behavioural insights | Generic description: 'customers' or 'users' |
| Clear escalation rules for edge cases and complex queries | No mention of human handoff whatsoever |
| Named knowledge base documents or URLs the bot can access | 'We will send content over later' |
| Identified CRM or system integrations with API access confirmed | Wishlist of integrations with no API research done |
| GDPR data handling expectations clearly stated | No mention of data, storage, or compliance |
| Success metrics agreed before build begins | KPIs to be decided 'once we see how it performs' |
The sections below take each of the 10 things in turn. Work through them in order - each one informs the next.
Before anything else, you need to answer three questions: what is the chatbot's primary purpose, which channel will it live on, and who will it be talking to? These three definitions shape every technical and design decision that follows.
The most effective chatbots do one thing well. That sounds limiting, but it is the opposite - focus is what makes a chatbot genuinely useful rather than a novelty that users abandon after two interactions.
The three most common purposes we see in briefs from UK businesses are:
You may need the chatbot to do two of these things - for example, answer FAQs and capture leads - but if you find yourself listing four or five purposes, that is a sign the scope needs tightening. A chatbot that tries to do everything tends to do nothing particularly well.
Where the chatbot lives determines the technical architecture, the integration requirements, and the constraints on conversation length and format. The main options for UK businesses in 2025 are:
Starting with a single channel is almost always the right call. Multi-channel deployment is achievable, but building it well from the start costs significantly more than adding channels later once the core logic is proven.
Your chatbot's personality, vocabulary, and escalation behaviour should all be calibrated to the person it is speaking with. A B2C customer contacting a letting agency at 11pm has very different needs and patience levels than a B2B procurement manager evaluating enterprise software during working hours.
In your brief, describe the user persona as concretely as you can: age range, technical confidence, what they are anxious about, how much time they have, and what they are hoping the chatbot will do for them. If you have existing customer research or support ticket data, reference it.
Brief excerpt - Rivergate Lettings, London
Primary purpose: Inbound tenant support - answer routine tenancy queries and reduce out-of-hours call volume by at least 40%.
Target channel: Website widget (rivergate.co.uk). WhatsApp to be considered in phase 2.
User persona: Existing tenants, aged 22-45, renting privately in East London. Tech-comfortable. Most queries relate to maintenance reporting, rent payment dates, and tenancy renewals. Contact us because they cannot find the answer in their tenancy agreement.
Tone: Friendly and reassuring. Plain English. Never legalistic.
Success metric: 35% reduction in tenant support emails within 90 days of go-live.
Budget range: £5,000-£8,000 including first-year maintenance.
Notice how the above excerpt gives a developer everything they need to start scoping: they know the channel, the persona, the tone, and what the client considers success. That is what a brief should read like before Things 4-10 are added.
Escalation rules define the moment a conversation leaves the chatbot and reaches a real person. Every chatbot needs them - a bot that never escalates will eventually frustrate users; one that escalates too readily defeats its own purpose.
Escalation is one of the areas most frequently left undefined in briefs we receive. It is easy to overlook because it feels like an operational detail rather than a product decision. In practice, it is both - and it has significant implications for staffing, CRM setup, and user experience design.
There are two dimensions to define: when to escalate and how to escalate.
When to escalate covers the trigger conditions: sentiment signals (frustration, urgency), query types the bot cannot confidently answer, user requests for a human, compliance-sensitive situations (complaints, legal, safeguarding), and high-value commercial conversations where a human relationship matters.
How to escalate covers the mechanics: live chat handoff within the same widget, email capture and callback request, calendar booking link (Calendly, HubSpot Meetings), or SMS. Each option has different complexity and cost implications in the build.
| Scenario | Escalate to human? | Why |
|---|---|---|
| User asks a question the bot cannot answer after two attempts | Yes - offer callback or email capture | Repeated failure erodes trust; do not persist |
| User expresses frustration or uses emotive language | Yes - immediate soft handoff | Sentiment escalation prevents complaint escalation |
| User explicitly says 'speak to a person' | Yes - immediately | Never argue with a direct request for human contact |
| Complaint about a product or service | Yes - log to CRM and alert team | Complaints require audit trail and human empathy |
| High-value commercial enquiry (large order, enterprise deal) | Yes - route to sales, not support | Revenue risk outweighs automation efficiency gain |
| Routine FAQ (opening hours, pricing page, return policy) | No - bot handles fully | Consistent, instant answer is better than wait time |
| Repeat query already answered in same session | No - rephrase and retry once | May be a wording issue, not a bot failure |
| Out-of-hours enquiry with no human available | Capture details - schedule follow-up | Do not promise instant human response you cannot deliver |
One practical tip: in your brief, name the human escalation destination. Is it a shared inbox? A specific team member? A Slack channel? A Zendesk queue? The more specific you are, the cleaner the integration can be built.
With escalation rules defined, the next layer is what the bot actually knows and what systems it connects to.
A chatbot is only as good as the information it can access. Defining the knowledge base and the system integrations upfront prevents the most common mid-project discovery: that the data the bot needs does not exist in a usable format, or that API access to a key system requires weeks of procurement approval.
The knowledge base is the collection of documents, URLs, structured data, and business rules that the chatbot draws on when answering questions. In your brief, you need to specify:
A common mistake is assuming that 'everything on our website' is a clean, well-structured knowledge base. In practice, most business websites contain outdated pages, conflicting information, and content written for search engines rather than for a conversational AI. A knowledge base audit is often one of the first tasks in a chatbot project - your brief should acknowledge this rather than assume the content is ready.
Integrations are where chatbot projects most frequently run over budget and schedule. The reason is simple: API access, authentication, and data mapping are only negotiable with your software vendor - they are fixed constraints. Discovering mid-build that your CRM does not expose the endpoint you need, or that your helpdesk platform requires an enterprise licence to enable webhooks, is an expensive surprise.
In your brief, list every system the chatbot needs to interact with and, for each one, confirm:
Common integrations we build at Softomate include: HubSpot, Salesforce, Zoho CRM, Calendly, Microsoft Bookings, Zendesk, Freshdesk, Shopify, WooCommerce, and bespoke REST APIs. If your system is not on that list, it is not necessarily a problem - but it does mean we will need to review the API documentation before scoping the build. Include a link to your system's developer docs in the brief if you have it.
With the data architecture defined, the next consideration - one that is legally non-negotiable in the UK - is GDPR.
Any AI chatbot that processes personal data from UK users is subject to the UK GDPR, administered by the ICO. Defining your data handling obligations in the brief is not optional - it determines system architecture decisions that are expensive to retrofit after build.
The UK GDPR came into effect after Brexit and mirrors much of the EU GDPR, but with some UK-specific nuances. The ICO's guidance is the authoritative reference for UK businesses: ico.org.uk. The government's pro-innovation AI regulation framework also applies to higher-risk deployments: gov.uk AI regulation. For regulated sectors (financial services, healthcare), BSI AI standards are also increasingly referenced: bsi.group.
In your brief, address each of the following:
Thing 7 in our framework is the chatbot's conversation tone and brand voice - addressed in the brief excerpt above for the letting agency example. Tone covers formality level, first-person or third-person brand voice, use of humour, and vocabulary restrictions (for example, avoiding jargon for consumer-facing bots or always using plain English for public sector tools).
With compliance defined, the final pair of things - success metrics and post-launch ownership - give the project a clear finish line.
A chatbot without defined success metrics is a chatbot nobody will ever be able to declare a success - or identify as failing. Agree the metrics before build begins, not six months after launch when you are trying to justify the investment.
Thing 9 is your success metrics. Thing 10 is who owns maintenance and updates after launch. Both belong in the brief.
The metrics that matter most depend on the chatbot's primary purpose. A lead capture bot is measured differently from a support deflection bot. The table below shows the key metrics, typical industry benchmarks for UK deployments in 2025, and how to measure them.
| Metric | Industry benchmark (UK 2025) | How to measure |
|---|---|---|
| Containment rate | 60-80% for focused support bots | Conversations resolved without escalation divided by total conversations |
| Lead capture rate | 15-35% of qualifying conversations | Contact details collected divided by sessions where user expressed interest |
| Average response time | Under 2 seconds for first response | Chatbot platform analytics or custom logging |
| Session completion rate | 55-70% (user reaches a defined end state) | Defined end states: FAQ answered, lead captured, booking made, escalation requested |
| User satisfaction (CSAT) | 3.8-4.5 out of 5 at 90 days | End-of-conversation rating prompt (1-5 stars or thumbs up/down) |
| Escalation rate | 15-25% (lower is better once bot is trained) | Escalations divided by total conversations |
| Ticket deflection (support bots) | 25-45% reduction vs pre-launch baseline | Compare support ticket volume before and after go-live |
| Cost per conversation | Varies widely by platform and volume | Total monthly platform cost divided by total conversations |
Set a 90-day review milestone in the brief. At 90 days, you will have enough data to distinguish a bot that is performing from one that needs retraining, additional knowledge base content, or an escalation rule adjustment.
This is the most neglected section of almost every brief we review. A chatbot is not a one-time build - it is a living tool that needs regular attention. Specifically:
At Softomate, we offer ongoing maintenance retainers starting from £250 per month that cover transcript reviews, knowledge base updates, and monthly performance reporting. Some clients handle this in-house with a nominated 'chatbot owner' - usually a marketing manager or operations lead. Either approach works, but the decision must be made before launch, not after the first support ticket arrives asking why the bot is giving outdated pricing.
If you would like to talk through any of these 10 points before writing your brief, our AI chatbot development team in London offers a free 30-minute scoping call. We will review whatever you have - even a rough set of bullet points - and help you turn it into a document we can build from.
A useful chatbot brief is typically two to four pages. Longer is not necessarily better - what matters is specificity. A one-page brief that clearly defines the primary purpose, user persona, escalation rules, integrations, GDPR position, and success metrics is more valuable than a ten-page document full of vague aspirations. Use headings aligned to the 10 things in this article and aim to answer each one in three to five clear sentences. If you find yourself writing more than a paragraph on any single point, it probably means the decision has not been made yet - and that is worth flagging before development begins rather than after.
The brief should be a collaborative document, not the sole responsibility of one person. The best briefs we receive at Softomate are typically authored by an operations or marketing lead, reviewed by the IT or technical contact who will manage integrations, and signed off by the person with budget authority. If the chatbot will handle customer data, your Data Protection Officer or compliance lead should also review the GDPR section. A brief written by one person in isolation tends to miss the blind spots that other stakeholders would catch immediately. Allocate a one-hour working session to agree the 10 points as a team, then nominate one person to write it up.
Yes. We provide a structured brief template on our free scoping call - it covers all 10 points in this article with guidance notes for each section. The template is formatted as a Google Doc so multiple stakeholders can contribute simultaneously. To receive it, book a free scoping call via our AI chatbot development page. The call is 30 minutes, no sales pressure, and you will leave with a populated template ready to share with your development partner - whether that is us or another agency.
The single most common mistake is defining the chatbot by its features rather than its purpose. Briefs that open with 'we want a chatbot with natural language processing, multi-turn dialogue, and WhatsApp integration' are starting in the wrong place. The technology choices should follow the business problem, not precede it. We regularly see briefs that specify a particular AI model or platform before defining what the chatbot needs to do - which leads to scope creep, over-engineering, and budget overruns. Start with the problem. Start with the user. Start with the success metric. The technology choices then become straightforward.
No - and you should not try to specify the technology in the brief unless you have a very specific reason to. The brief is a business document, not a technical specification. Your job is to define what the chatbot needs to do, who it will talk to, what it needs to know, and how success will be measured. Your development partner's job is to translate those requirements into a technical architecture. Attempting to specify the underlying AI model, the hosting infrastructure, or the NLP framework before the business requirements are clear typically constrains the solution unnecessarily and can result in higher costs. Tell us the problem. We will tell you the best way to solve it.
AI chatbot development costs in the UK range from £3,000 for a simple FAQ chatbot to £25,000+ for a fully integrated conversational AI with CRM and booking system integration. Monthly running costs are typically £100-£400. Softomate Solutions builds AI chatbots from £3,500 with a 3-4 week delivery timeline and full UK GDPR configuration included.
For customer-facing use, a custom AI chatbot trained on your specific business knowledge, pricing and services significantly outperforms a generic ChatGPT integration. A custom chatbot knows your products, your pricing, your service area and your compliance requirements. It also integrates with your CRM, booking system and WhatsApp - capabilities ChatGPT plugins cannot replicate without custom development.
More from the blog
Let us help
Talk to our London-based team about how we can build the AI software, automation, or bespoke development tailored to your needs.
Softomate Solutions Limited
Deen Dayal Yadav
Online
