Use case · Use case - Support
Ticket deflection
Most tickets are answerable from systems your team already trusts - they just take a person eight minutes to assemble. Bhogar reads the account, the policy, and the knowledge base together, resolves what it can prove, and escalates the rest with the work already done.
ROI lever
tasks deflected and cost per resolved ticket
Deflection is only worth counting when the requester actually got what they needed. The measurement discipline matters as much as the automation: a session the customer abandoned is not a deflection, and reporting it as one destroys trust in every other number you publish.
Reads from
- Knowledge base and policy
- Ticket and contact history
- Account and entitlement systems
- Order or service records
The problem
Your queue is full of questions that have documented answers.
Deflection projects usually fail for the same reason: the assistant can read the help centre but not the account. A generic answer to a specific question does not deflect anything, it just adds a step before the ticket.
Checked by hand today
- Help centre and knowledge base
- Ticketing and case history
- Account, order, or entitlement systems
- Policy and eligibility rules
““Given who this requester is and what they already own, what is the correct answer right now?””
Self-service cannot see the requester
Help centres answer in general terms while customers ask in specific ones - this order, this plan, this device. Without account context the assistant cannot resolve, only redirect.
Escalations arrive empty
When automation gives up, it usually gives up silently. The agent restarts from the original message, so the customer repeats themselves and handle time gets worse rather than better.
Nobody trusts the deflection number
Counting every session that did not open a ticket inflates the figure and hides abandonment. Finance discounts the whole business case as a result.
How Bhogar helps
How Bhogar handles ticket deflection
Bhogar resolves identity and entitlement before it retrieves, so the answer is scoped to what this requester actually has - and to what they are allowed to be told.
Sources
- Knowledge base and policy
- Ticket and contact history
- Account and entitlement systems
- Order or service records
Outcomes
- Resolved contacts
- Actions taken within limits
- Context-rich escalations
- Content-gap reporting
Account-aware retrieval
Plan, entitlement, order state, and prior contacts are read before the knowledge base, so the answer accounts for the requester’s situation rather than describing the general case.
How it works →Grounded answers with citations
Every claim traces to an approved source. Where the corpus is silent, the configured behaviour is to say so and escalate rather than to produce a plausible sentence.
How it works →Actions inside limits
Password resets, plan changes, refunds, and reships run as permissioned tools with configurable value and risk thresholds. Above the limit the case is prepared for a person.
How it works →Escalations that save time
The handoff carries what was asked, what was checked, which sources were consulted, and precisely why automation stopped - so the agent starts at minute eight, not minute zero.
How it works →
All your data
Four connections cover most of the queue.
Deflection does not need every system in the company. It needs the systems that answer the top ten contact drivers, connected properly, with permissions respected at query time.
Knowledge base and help centre
Published articles, internal macros, and troubleshooting guides, indexed with their review dates so stale content is visible.
Ticketing and case history
Prior threads for the same requester, resolutions that worked, and the known-issue register.
Account and entitlement data
Plan, tier, licences, contract terms, and support scope - the facts that decide whether an answer applies.
Transactional systems
Orders, subscriptions, devices, or service records read live so status is current rather than cached.
Policy library
Refund, returns, eligibility, and goodwill rules at their safe version, so the same facts always produce the same ruling.
Product and release information
Documentation and changelog for the version the requester is on, so answers do not describe behaviour they do not have.
Governance built in
- Identity verified before entitlement data is retrieved - the assistant never reveals account detail on an unauthenticated session.
- Retrieval scoped by requester so one customer’s context can never surface in another’s conversation.
- Action tools bounded by value and risk thresholds with mandatory escalation above the limit.
- Personal data redaction on the path to model providers, with regional or private endpoints where required.
- Every resolution logged with sources, policy clause, and any action taken, for quality review and dispute handling.
The workflow
From first message to measured outcome.
The path is the same whether the requester is a customer in your product or an employee in a service-desk channel.
Asks in their own words
The contact arrives from chat, email, the help centre, or an internal channel, with identity established by the surface it came from.
In the portal
Task agents with a defined job, versioned.
211 agents across content, HR, and finance - each with a type, status, and version, grouped into teams and chains.
The return
Count resolutions, not conversations.
Baseline your current volumes and handle time before go-live. Each definition below is deliberately conservative so the resulting number survives a finance review.
tasks deflected
sessions resolved without a ticket ÷ total assisted sessions
Only count sessions with confirmed resolution or no ticket within the follow-up window. Abandonment is not deflection.
Cost per resolved ticket
(agent minutes × loaded rate) + platform cost ÷ resolved tickets
Report automated and assisted paths separately. Blending them hides which path is improving.
Handle time on escalations
median minutes from handoff to resolution
Context-rich escalations should be faster than a cold ticket. If they are not, the handoff payload needs work.
Reopen rate
tickets reopened within 7 days ÷ tickets resolved
The guardrail on the whole programme. Deflection that rises while reopens rise is deferral, not resolution.
| Dimension | Before | With Bhogar |
|---|---|---|
| A routine account question | Help-centre article, then a ticket, then an agent checking the account. | Answered from account state and policy in the first exchange, with sources. |
| A question the corpus cannot answer | A confident-sounding wrong answer, then a complaint. | An explicit “I cannot confirm this” and an escalation with context. |
| Escalation quality | The original message and nothing else. | Question, checks performed, sources consulted, and the stopping reason. |
| Content maintenance | Gaps found by reading ticket trends months later. | Failed retrievals ranked weekly as a prioritised content backlog. |
FAQ
Frequently asked questions
What tasks deflected should we expect?
How do we stop it answering when it should not?
Does this replace our support team?
Can it work for internal service desks too?
Keep exploring
Knowledge search
One question, every approved system - documents, tickets, code, wikis, and records - answered with citations and each person’s own permissions applied.
Incident response
Assemble the runbook, the recent changes, the comparable past incident, and the customer impact within seconds of a page - and draft the comms.
Contracts
Extract obligations, deviations, and risk positions from long documents at clause level - with every finding linked to the exact text it came from.
Start from your contact drivers, not from a demo.
Bring a quarter of ticket data and we will show which drivers resolve end to end today, which need work, and what deflection is worth at your volume.