Case Study
A UK B2B SaaS company with 9,400 active accounts deployed a custom AI chatbot built by Softomate on GPT-4o + RAG, reducing Tier-1 support tickets by 60%, cutting first-response time from 41 minutes to 28 seconds, and recovering the build cost within 5 months.
13 min read By Deen Dayal Yadav, Founder & AI Automation Director
UK-based B2B SaaS, 9,400 paying customers, 11-person support team
A UK B2B SaaS company with 9,400 active accounts deployed a custom AI chatbot built by Softomate on GPT-4o + RAG, reducing Tier-1 support tickets by 60%, cutting first-response time from 41 minutes to 28 seconds, and recovering the build cost within 5 months.
A UK-headquartered B2B SaaS company providing project-management software to professional services firms had reached a scaling inflection point that its support function could not absorb. With 9,400 paying customers across the UK and Ireland, monthly support volume had grown to 5,200 tickets, of which the support team itself had quantified that around 64% were repeat questions answerable from existing product documentation, in-app data, or account-state information already held in the platform's own database. The team of 11 support engineers was, in practice, spending the majority of its hours repeatedly answering the same dozen or so questions with slightly varied phrasings.
The product was good, the customer base was loyal, the renewal rate was over 91%, and yet the support function had become the single biggest operational drag on the business. The head of support had run an audit during the previous quarter and found that the average customer who contacted support waited 41 minutes for a first response during weekday hours, and over 6 hours outside of them. Customer satisfaction scores on post-interaction surveys had drifted from 4.4 out of 5 down to 3.9 over the previous twelve months, and the company's own NPS tracker showed a clear inverse correlation between average response time per customer cohort and likelihood to recommend.
The cost structure compounded the problem. The team was already operating at full capacity, with no slack for product-launch traffic spikes or unusual incident windows. Adding two further support engineers to absorb the growing volume would cost roughly £124,000 fully loaded per year. That hire was already approved in principle but would not solve the underlying issue, which was structural: most of the support work was data-lookup and documentation-reference, not genuine problem-solving. Throwing more people at a documentation-shaped problem was, the head of support privately acknowledged, the wrong response.
The CTO had explored two off-the-shelf chatbot products before approaching Softomate. The first was a popular helpdesk-builder add-on that promised AI auto-replies. In practice, it could only respond to exact keyword matches from a pre-built FAQ library, which meant any rephrasing of a common question fell through to a human anyway. It was abandoned after a two-month pilot during which it deflected less than 3% of total volume. The second was a more sophisticated platform offering RAG-style retrieval over documentation, but it could not connect to the SaaS product's own database to look up actual account-state, meaning it could not answer questions like “why was I charged twice in November” or “when does my current plan renew” with any specificity. Customers found those generic responses more irritating than helpful, and the trial was cancelled within six weeks.
The customer-base composition was a critical detail in framing the brief. The 9,400 accounts split into three rough tiers by value: 8,200 accounts on a self-service plan at £19-£49 per month, 1,000 accounts on a team plan at £79-£299 per month, and 200 accounts on an enterprise plan at £500+ per month. The self-service tier generated the bulk of the ticket volume (around 78% of all tickets came from this tier) but the smallest revenue contribution per account. Continuing to throw human support time at the self-service tier was eroding the unit economics of that tier, with the company's CFO modelling that within 18 months the self-service tier would be loss-making if support cost grew in line with customer growth. The strategic implication was clear: the company needed to industrialise self-service tier support without damaging the experience.
The fifth pressure was inbound channel diversity. Support tickets reached the team through five channels: in-product chat widget (52% of volume), email to support@ (31%), an in-product help article system with a contact-support button (8%), the company's mobile app (6%), and direct messages to the company's social accounts (3%). Each channel had its own conventions and the existing support tooling treated them separately. A customer who started a question on the website chat and then followed up on email got two separate ticket threads with no linkage, and the assigned support engineer had to manually reconcile them. This was a quiet but consistent source of friction that the head of support estimated cost the team several hours per week in unnecessary triage.
The CTO's brief to Softomate was specific. Build something that could answer documentation-style questions with the accuracy of a senior support engineer, look up actual account data live from the platform's own database to give personalised responses, hand off cleanly to a human when escalation was genuinely needed, and write a complete conversation summary back into the support ticketing system so that escalated tickets arrived in human queues with full context. Unify the five inbound channels into a single conversation thread per customer. Do all of this within an eight-week build window and integrate with the company's existing Zendesk and PostgreSQL data warehouse without requiring any production database changes.
The privacy and security context was equally important. The company held customer data on behalf of professional services firms, some of which were themselves regulated (law firms, accountancy practices, healthcare consultancies). The chatbot's access to customer data needed to be tightly scoped, fully auditable, and architected so that even a model compromise could not exfiltrate data beyond the structured queries the company explicitly authorised. The CTO had been clear from the outset that a system that could not pass the company's own internal security review was a non-starter regardless of any other operational benefit.
Softomate's discovery phase mapped the existing support workflow in detail and analysed three months of historical Zendesk tickets to categorise every question type by frequency, complexity, and the specific data source needed to answer it. The output was a clear priority matrix. The top 14 question types accounted for 71% of all volume and could every one of them be answered by a chatbot with read access to the product's customer-state data, the billing system, and the documentation library. Categories like “why was I charged X”, “how do I export Y”, “is feature Z available on my plan”, and “what does this error message mean” were the bulk of inbound volume.
The chatbot architecture used GPT-4o for the language model layer with a retrieval-augmented generation system over three integrated data sources: the product's user-facing documentation (110 articles across six product modules), the customer's own account-state pulled live from the production database via a read-only API gateway, and the billing system pulled live via Stripe's API. The vector store was built on the documentation corpus and queried via semantic search, so that customer queries reached the correct policy or how-to snippet even when phrased unusually. The account-state lookups were structured queries against pre-defined intent classes, not free-form database queries, which kept the security model tight and predictable.
The decision to build a custom system rather than configure an off-the-shelf product was justified explicitly in the discovery output. Softomate evaluated three off-the-shelf platforms (Intercom Fin, Zendesk AI, and Ada) against the brief. Intercom Fin and Zendesk AI both had strong documentation-RAG capabilities but neither could integrate cleanly with the company's own production database without either exposing the database to the vendor's cloud or accepting a stale data feed via batch sync. Ada offered more flexible integration but the team's own evaluation showed that the per-conversation pricing would scale to over £58,000 per year at current volume, with the unit economics getting worse as customer base grew. The custom build amortised across a one-time engagement plus ongoing model costs of approximately £0.04 per interaction, producing a structural cost advantage that compounded over time.
A critical part of the build was the escalation logic. The chatbot was trained to recognise four classes of query that required human handover: any billing dispute over £100, any data-loss or potential-bug report, any explicit request for a human, and any query that could not be confidently answered within three retrieval attempts. On escalation, a structured handover summary was generated automatically, including the customer's identity, the specific question, the relevant account-state already retrieved, and the chatbot's best-effort interpretation of the underlying intent. This summary was attached to the Zendesk ticket as a private internal note so the assigned support engineer saw the full context the moment they opened the ticket.
Brand voice calibration matched the proven pattern from previous Softomate engagements. Softomate's team analysed 180 of the support team's highest-rated historical responses, categorised by tone (warm-formal vs technical-precise vs apology-and-resolution) and used them as the training corpus for the model's response style. The head of support reviewed 200 generated responses across the full intent spectrum before launch and signed off on the tone, with 14 specific tonal corrections applied to the prompt scaffolding before the pilot opened.
The cross-channel unification was a separate workstream that delivered substantial operational value beyond the chatbot itself. Softomate built a customer identity service that consolidated identifiers across the five inbound channels (website session cookies, email addresses, in-app user IDs, mobile app installation IDs, social account handles) into a single canonical customer record. Every conversation, regardless of channel, was associated with the relevant canonical record, and historical conversations across all channels became visible in a single timeline view inside Zendesk. The head of support described this change as more operationally significant than the chatbot itself, because it eliminated an entire class of duplicate-ticket triage work.
The build was deployed in a phased rollout over three weeks. Week one was a closed pilot with five internal users acting as customers. Week two opened to 5% of real customer traffic, with every chatbot conversation reviewed daily by Softomate and the head of support together. Week three opened to 100% of inbound chat traffic with continued daily monitoring. Twenty-one targeted refinements were made across those three weeks, most of them to the documentation knowledge base where the chatbot had given technically correct but tonally awkward answers about pricing tiers.
The technical stack deserves explicit mention because it was a deliberate choice. GPT-4o was selected over GPT-4o-mini for tonal reliability after side-by-side testing on 80 representative tickets. The retrieval layer was built on a self-hosted vector database (Qdrant) rather than a hosted alternative, because the SaaS company's compliance team required all customer-data-adjacent infrastructure to run inside their existing UK AWS region. The Zendesk integration used Zendesk's native API rather than a third-party connector, which added two days to the build but eliminated a per-ticket integration cost that would have compounded over time.
The security architecture deserves equal attention. The chatbot service ran inside the company's existing VPC with no inbound internet access. Outbound calls to OpenAI went through a controlled egress proxy that logged every request and response for audit purposes. The read-only API gateway exposed a deliberately narrow set of structured queries to the chatbot rather than free-form database access; queries were parameterised templates with strict input validation. Every conversation was logged immutably for 90 days for support purposes and indefinitely in anonymised aggregate form for analytics. The company's external security consultancy reviewed and approved the design before pilot launch, with two specific recommendations (rate limiting on the data-access tier, and explicit denial of cross-account data access in the API gateway) implemented before go-live.
Testing approach reflected the platform's business-critical nature. Beyond unit tests on the integration code, Softomate built an automated regression suite of 240 representative customer questions with known correct answers. The suite ran nightly against the production-equivalent test environment, with any answer that drifted materially from the expected output flagged for review. This proved its value within two weeks of go-live when an OpenAI model update produced subtly different output formatting on numerical responses; the regression suite caught the drift before any customer was affected.
Within the first 90 days of full deployment, Tier-1 ticket volume handled by human engineers fell by 60%. The chatbot successfully resolved 3,120 of the average monthly 5,200 tickets without human escalation. Average first-response time across all ticket types dropped from 41 minutes to 28 seconds. The remaining 40% of tickets routed to humans were genuine complex cases, and engineer average response time on those improved to 14 minutes (from 41), because the queue had collapsed and engineers were no longer triaging high volumes of repeat questions before reaching the cases that actually needed them.
Customer satisfaction scores on post-interaction surveys rose from 3.9 to 4.5 out of 5 for chatbot-handled interactions, and from 4.0 to 4.6 for human-handled interactions (the latter rising because human time was now focused on harder problems where deeper engagement made a measurable difference to outcome). The company's NPS tracker moved from 38 to 52 across the same period, an improvement the CTO directly attributed to the response-time change in a board-level review.
The two-engineer hire originally approved was cancelled. The existing 11-person team had visible capacity for the volume reaching them, and the head of support reallocated 1.8 FTE worth of recovered time into a proactive customer success function that the company had wanted to build for over a year but had never had the headcount for. That function generated 14 expansion-revenue opportunities in the first quarter of operation, worth approximately £47,000 in additional ARR.
Total Softomate engagement cost was recovered within 5 months of go-live, driven primarily by the avoided hire cost. The chatbot has since been extended to handle two additional ticket categories that were originally scoped out as too complex: feature-request triage and integration-troubleshooting for the platform's top 6 third-party integrations. Both extensions were delivered as configuration changes rather than new builds.
The unexpected outcome was operational intelligence. Because every interaction was logged with structured intent tagging, the product team gained a real-time view of which features generated the most customer confusion. A consistent pattern of questions about the platform's permissions model led directly to a UX redesign in the following quarter that removed an entire category of tickets at source. The redesign reduced permissions-related tickets by an additional 38% over the following 60 days, a saving entirely separate from the chatbot's direct deflection.
The cross-channel unification produced its own measurable benefit. The duplicate-ticket rate (a customer's identical question handled separately on chat and email because the team did not see the linkage) fell from 11% pre-deployment to under 1% post-deployment. The head of support's estimate that this was costing several hours per week of unnecessary triage turned out to be conservative; the actual recovered time was closer to 9 hours per week across the support team.
The unit economics analysis the CFO had prepared looking forward eighteen months was rerun at the 90-day mark. The previous projection had shown the self-service tier becoming loss-making within 18 months at current support-cost growth rates. The post-deployment projection showed the self-service tier remaining profitable indefinitely at current trajectory, with the cost-per-supported-customer falling rather than rising as customer base grew. This was the outcome that had the most material impact on the company's long-term strategic options.
The team-morale dimension was an outcome the head of support raised in the post-launch review without prompting. The support engineers, freed from the volume of repeat questions, reported significantly higher job satisfaction in the firm's quarterly internal survey. The team also reported feeling that their senior judgment was being used rather than spent on data lookups, and two team members applied for and were promoted into engineering and customer success roles within the following six months, paths that had not been visible before the change in their working day made career-development conversations feasible.
Three things, with the benefit of hindsight, would have made the build smoother. First, the documentation corpus had three years of accumulated drift between what the documentation said and what the product actually did, which the chatbot initially exposed by giving confidently incorrect answers to certain how-to questions. Softomate added a documentation accuracy review as part of the rollout, with the product team correcting 23 specific documentation issues in the first month. Future engagements should treat documentation accuracy as an explicit dependency rather than an assumption. Second, the customer identity service required two iterations because the first version did not handle a particular edge case around customers who had changed their email address mid-relationship. Third, the regression test suite was scoped too narrowly initially; the OpenAI model drift incident in week 2 of production revealed gaps that have since been closed by expanding the suite from 240 cases to 580.
The next phase of work, already commissioned, focuses on a Tier-2 use case: the integration-troubleshooting workflow for the platform's API customers, where queries are more technical and the documentation is sparser. The hypothesis is that the same approach (retrieval-augmented model with live data access and clean escalation) will translate from end-user support to developer support, with an expected deflection rate of around 40% versus the 60% achieved on Tier-1.
The broader strategic outcome was a shift in how the company thought about its support cost structure. Before the project, support was treated as a variable cost that grew with customer base, and the implicit assumption was that scaling required scaling the team. After the project, the marginal cost of supporting an additional self-service customer fell close to zero, because the chatbot handled almost all incremental volume without additional human time. The CFO modelled the impact on the company's three-year plan and concluded that the chatbot effectively unlocked roughly £420,000 of avoided support-team growth over that window, assuming current customer-growth trajectory. That figure was material enough to factor into the company's Series B funding conversations the following year, where the unit-economics improvement became a specific narrative point.
The product team also began using chatbot interaction data as an input to roadmap prioritisation. Each quarter, the head of product reviewed the top 20 chatbot intent categories by volume to identify candidates for product changes that would remove queries at source. Three product changes in the year following deployment were directly attributable to chatbot-surfaced insights: the permissions redesign mentioned earlier, an in-product onboarding revision that reduced first-week support contact by 22%, and a billing-page redesign that reduced billing-related queries by 31%. The chatbot, in effect, became the company's most consistent source of voice-of-customer data, available to product without requiring any new research process.
Related service: AI Chatbot Development Service London. Further reading: Custom AI Chatbot vs ChatGPT, How to Build a Custom AI Chatbot and No-Code AI Tools vs Custom AI Development. Related case study: AI Chatbot for London Letting Agency.
Anonymised client engagement. Identifying details modified for confidentiality. Outcome ranges reflect typical results from similar projects.
Names withheld to preserve confidentiality.
Work with us
Every project we take on has a measurable outcome. Talk to our London team and we will show you exactly how we would approach your challenge.
Softomate Solutions Limited
Deen Dayal Yadav
Online