NEXSUM_LABS
  1. Home
  2. Work
  3. A SaaS vendor's support assistant answers the repetitive half and hands off the rest
Book a call

[ Case study ]

SaaSLLM assistant platformRAG over consolidated docsGuardrail configHandoff to Zendesk

A SaaS vendor's support assistant answers the repetitive half and hands off the rest

Tier-1 support was drowning in the same forty questions — billing cycles, seat management, integrations — while genuinely complex tickets waited days. The team considered a chatbot and feared the classic outcome: a wall of confident nonsense.

CLIENT a project-management SaaS vendor — FOCUS Ground it in a cleaned knowledge base

AI Chatbots & AssistantsAI & AutomationAI Chatbots & AssistantsSaaSRepresentative example
Client
a project-management SaaS vendor
Industry
SaaS
Engagement
8 weeks — systems pod — automation specialist + engineer
Service
AI & Automation / AI Chatbots & Assistants
Headline outcome
Tier-1 tickets resolved without human touch, month two post-launch versus month before: 44% → 71%, read from Support desk reports

Representative examplesEvery case study in this library is an illustrative composite of the kind of engagement we deliver — written to show our method and standards, not to name clients.

Where they started

Software is the product and support is the promise: the client sells a project-management tool to small teams, and its reputation lives or dies on how fast a confused customer gets unstuck. The support team is small, senior, and proud of the complex tickets they resolve — the migrations, the broken integrations, the edge cases. Below that sits a mountain of routine volume that grew with every pricing-page change and every new integration shipped.

What it was costing

Tier-1 support was drowning in the same forty questions — billing cycles, seat management, integrations — while genuinely complex tickets waited days. The team considered a chatbot and feared the classic outcome: a wall of confident nonsense.

What they could see

  • The same billing and seat-management questions filled the queue every Monday after the weekend's signup spike.
  • Genuinely complex tickets waited days behind the routine ones, and the best engineers were pulled into answering them.
  • Copy-pasted answers drifted from the current docs, and customers quoted the stale versions back at the team.
  • Support leads kept a private list of questions the docs answered but customers never found.

The constraints we worked inside

  • Wrong answers to billing questions create real harm — grounding and refusal rules were non-negotiable.
  • The docs were good but scattered across three sources with version skew.
  • The support lead insisted on reviewing transcripts weekly — the system had to make that easy.

What had been tried before

An off-the-shelf support chatbot was trialed on the public docs for a month.
It answered billing questions confidently and wrongly twice in week one; the support lead disabled it before it could erode more trust.
Two additional tier-1 agents were hired ahead of a product launch.
Volume scaled with the launch, headcount didn't, and the complex tickets waited just as long — the bottleneck was triage, not typing speed.
A canonical FAQ page was written to absorb the repetitive questions.
Customers with a billing problem open chat, not the docs; the page was accurate, current, and almost never visited at the moment of need.

What we proposed

We proposed a grounded assistant that answers only from a consolidated, versioned corpus of their own docs, cites what it used, and escalates billing changes, contract questions, and anything account-specific to humans by rule. The refusal rules were written and tested before the personality was, because their constraint was trust, not capability. An eval set with expected answers ran before launch and runs weekly after, so quality drift is measured rather than discovered by complaint. The Zendesk desk stays the system of record; the assistant files context-rich tickets rather than replacing the tool the team lives in.

Just as important is what we ruled out, and why:

  • An autonomous agent with account accessBilling questions create real harm when wrong; an agent that could touch accounts needed guardrails the team couldn't verify before launch.
  • Migrating docs into a new knowledge platformThe docs were good but scattered with version skew — a content problem no platform purchase would fix by itself.
  • A rules-only decision tree, no LLMThe forty questions hide inside free-text phrasing; a tree either grew unmaintainable or bounced real questions to humans immediately.

How the work ran

01Ground it in a cleaned knowledge base

The three doc sources were consolidated, deduplicated, and versioned; the assistant answers only from that corpus and cites what it used.

02Write the handoff rules before the personality

Billing changes, account-specific questions, and anything about contracts escalate to humans by rule — the assistant knows what it doesn't know.

03Evaluate before and forever

A question set with expected answers ran before launch and runs weekly after, so quality drift is measured rather than discovered by complaint.

Delivered by the systems pod — automation specialist + engineer over 8 weeks, with working increments reviewed with the client every week.

The stack, and the reasoning

LLM assistant platform
Chosen for configurable refusal and citation behavior rather than raw fluency — the team needed a system that could say 'I don't know' cleanly.
RAG over consolidated docs
Answers ground in the cleaned, versioned corpus instead of model memory, so a stale answer is a content bug with a location, not a mystery.
Guardrail config
Billing changes, contract questions, and account-specific requests escalate by rule before generation; the refusals were written and tested before the personality was.
Handoff to Zendesk
Escalations land as tickets with transcript and citations attached, so the team's existing queue absorbs the assistant instead of running parallel to it.
Eval suite
A fixed question set with expected answers runs weekly, so quality drift shows up as a failed check instead of an angry tweet.

What went wrong

Obstacle

Two conflicting billing articles — one pre-dating a pricing change — produced the only seriously wrong answer in testing, and nothing in the corpus marked one as authoritative.

Handled: We consolidated the corpus before further configuration: deduplicated, versioned, and given a source-of-truth rule per topic, then re-ran the eval set clean.

Obstacle

The support lead's weekly transcript review was proving impossible — she was skimming, not reviewing, because transcripts arrived as raw dumps every Monday.

Handled: We reshaped the export around her actual questions — refusals, escalations, low-confidence answers first — and the review became fifteen focused minutes.

How we worked together

Cadence
A Monday demo with the support lead and the head of product, plus the weekly eval report circulated the same morning.
Client side
The support lead owned refusal rules and reviewed every transcript weekly; a senior agent curated the eval question set.
Decisions
Product ruled on anything touching billing policy; everything else the demo settled, and what it couldn't went into a written decision log.
They provided
Six months of anonymized tickets, access to the three doc sources, and a staging Zendesk instance configured to match production.

What changed

The headline: tier-1 tickets resolved without human touch, month two post-launch versus month before44% → 71%, read from Support desk reports. A second check: median response time for escalated (complex) tickets at 2.1 → 0.4 days.

The senior team got their complex tickets back, and the mood in the support channel shifted from triage to craft. Customers quote the assistant's cited answers back accurately now, which quietly improved the questions they ask. The weekly eval has become the support lead's early-warning system — she flagged a doc gap to product twice before any customer complained. Nobody on the team is guarding their job from the assistant; they treat it like a junior colleague who cites their sources.

The result was read from Support desk reports against the pre-engagement baseline over the stated window, with a guardrail check on median response time for escalated (complex) tickets. Where platform-reported numbers and business outcomes differ, this record says which layer it is quoting.

What they own now

  • The assistant workspace wired into the Zendesk desk, with full prompt and guardrail configuration.
  • The consolidated doc corpus with its versioning and source-of-truth rules, plus the workspace credentials.
  • The eval suite with its question set and a scheduled weekly run.
  • A transcript-review guide matching the support lead's refusals-first workflow.
  • A runbook for onboarding new doc sources without breaking grounding.

What we would do differently

We would have cleaned the docs before configuring anything — two conflicting billing articles were the source of the only serious wrong answer in testing.

AI & AutomationAI Chatbots & AssistantsSaaSLLM assistant platform

Next case study

A legal-aid clinic screens intake questions around the clock without lawyer hours