Not a generic assistant. base9 Triage is configured with your team's own logic: your tiers, your rules and your guardrails, and tested on your actual tickets before it touches a live one. It decides where each new ticket goes and how urgent it is, drafts the reply from your own knowledge, and shows where every sentence came from. Your agents approve every reply. Available on request, on top of base9 Knowledge.
What "on request" means. Triage is not something you switch on yourself, and there is no trial of it. You ask; we go through your tiers, rules and guardrails with you; we configure it for your team and test it on your own solved tickets before it touches a live one. It is set up on top of base9 Knowledge, and its price follows from that scoping.
Why: same error as the open incident, so no new investigation. Urgent because they onboard a team at noon. Enterprise account, so their account manager is told.
Hi Sam, thanks for flagging this. This is a known issue that started this morning, and our team is already fixing it. We expect it to be resolved by 3 pm today. You don't need to change anything in Okta: the fix is on our side. We'll update you as soon as it's done.
The base9 console. The ticket, customer and incident are made up.
Configured, not built from scratch
Triage is one product. The steps and the safety checks don't change from team to team. Everything that decides what happens to a ticket is yours, written down with your support lead and tested on your tickets.
Yours
The same for everyone
How it works
Each step has one job and sees only what it needs. Your rules sit between the decision and the reply, so a reply is always written for the final outcome.
1 · Decide
What should happen, and who owns itIt reads the ticket with your whole knowledge base, open incidents and the customer's context, lists the possible causes, then picks the outcome, tier and priority. Your rules are applied in code before anything is written.
2 · Draft
The reply, from only what it may useA separate step writes the reply from the final decision and only the articles the decision relied on: a solution, the questions to ask, or an acknowledgement and a handoff note.
3 · Check
Every sentence, before an agent sees itEach statement is checked against its sources. Anything unsupported is rewritten once; anything still unsupported is highlighted and never sent automatically.
Triage that thinks like your team
base9 weighs the possible causes first, then decides what should happen, which tier owns it and how urgent it is. When the cause isn't clear, it asks before guessing. When your help center doesn't cover a question, it says so.
The right product, the right version, and low-risk steps.
A change across many users or devices, possible data loss, or a version that doesn't quite match.
"The integration stopped working", with no app name, time or error. Or several possible causes that need different fixes.
Anything new, risky, or not in your help center goes to a person.
When the cause isn't clear
A clear symptom can have several causes, and each needs a different fix. base9 lists them, shows which ones your help center covers, and asks the customer the question that tells them apart.
Hi Dana, thanks for letting us know. To find out what stopped the sync: does the integration show as Connected under Settings → Integrations, and did an admin or password change just before it stopped? If it shows Disconnected, choosing Reconnect restores the sync.
Made-up example.
Built around your tiers
You describe your tiers in your own words: what they're called, who works them, and what belongs at each. base9 follows them, and each tier gets something different.
Answers first. In-house, outsourced or offshore.
Takes the harder cases.
The last stop.
Your rules and limits
The safety checks run in code, after the AI has answered. They don't depend on the AI following its instructions.
Proven on your tickets
A pilot starts with a test, not a promise: base9 runs on your resolved tickets, with your rules, and is compared with what your agents actually did. You see it work before it touches a live ticket.
Before it goes live
Tested on your historyRun on recent resolved tickets and compared with your agents' replies: where it would have been right, where it would have been wrong, and where it would have asked a better question.
On every change
Retested before it goes liveNew rules, tiers or wording are tried first on a set of tickets with known right answers. Safety has to stay perfect, and your own resolved tickets join the set.
Every decision
Explained and recordedThe sources, the exact article versions, the rules that applied, and what the agent did with it. You can always see why it answered the way it did.
Tickets with known right answers. Made-up example scores.
Each entry keeps the sources, the article versions and the rules that applied. Made-up example.
Automatic sending is earned, not switched on: one type of ticket at a time, once 90% of its drafts were approved over 150 or more tickets.
Fits your helpdesk
Agents don't need to learn a new tool. The triage and the draft arrive on the ticket, as an internal note the customer never sees. Jira Service Management is the first helpdesk we connect to; tell us which one you use.
Pairs with base9 Knowledge
Every ticket shows where your help center works and where it doesn't. base9 Knowledge turns that into changes to approve: new articles, fixes to existing ones, and questions about articles that disagree. Triage is built on it, so every team starts there.
From triage to knowledge
Gaps, found as tickets come inQuestions no article answers, articles that cover only some causes, and articles that disagree.
From knowledge to triage
Better articles, better draftsEach approved fix is used by the next ticket on that topic.
How we start
Triage affects what your customers are told, so it isn't self-serve and it isn't generic. We configure it with you, once your knowledge is in shape with base9 Knowledge: your tiers, rules and guardrails, tested on your own resolved tickets. base9 reads your helpdesk read-only; your tickets are never exported, so nobody has to anonymize anything.
How it works, the safety checks, and what your setup needs: tiers, rules, guardrails, helpdesk. We agree the scope.
Your own access to a test version. Paste tickets from your queue and see how they're handled.
Read-only helpdesk access, your tiers, rules and guardrails written down with your support lead, and a test on your resolved tickets. How long it takes depends on your helpdesk and your rules.
Every new ticket gets a decision and a draft. Agents send, edit or overrule. A 15-minute check-in each week.
The numbers by type of ticket. Stop, keep it as a helper, or let it send the types that earned it.
What we measure
Time to first reply, and how many drafts were sent as written or with small edits.
Escalations with a complete handoff note, and engineering tickets that really needed an engineer.
Missing answers found and written, and articles that disagree fixed. Plus the one that must stay at zero: replies sent without approval.
The commercial shape
Configuration and pilot
Scoped with you, with success criteria we agree before we begin.
Setup
Connecting your helpdesk, importing your help center, and setting up your tiers and rules. Included in the pilot.
Pricing
On request. It depends on your team and your ticket volume, so we give it after we have scoped the work with you.
Questions
No. A chatbot answers your customers directly. base9 works behind your team: it prepares every ticket, and your agents decide what goes out.
No, and it isn't a generic assistant either. It's one product, configured for your team. The steps and the safety checks are the same for everyone; the logic, rules and guardrails are yours, and it is tested on your own tickets. That's why Triage is on request and not self-serve. Every change is versioned and tested before it goes live.
Built-in AI works the same way for everyone and uses your knowledge base as it is. base9 follows your tiers and rules, enforced in code; checks every sentence against your articles; is tested on your own tickets; and finds what your help center is missing or getting wrong.
That's exactly what a pilot measures. Drafts arrive on the ticket, so an agent sends, edits or ignores one in a single step, and you see the numbers by type of ticket. If it doesn't save time, you stop.
No. base9 reads your helpdesk read-only, in a setup you approve. Tickets are never exported or sent to us as files, so there's nothing to prepare.
Not during the pilot. Later, you can let it send replies for one type of ticket at a time, once its drafts were approved at least 90% of the time over 150 or more tickets. Refunds, security, data loss and the other tickets on your list always go to a person.
Every quote is checked word for word against the article, and every sentence of a draft is checked against its sources; anything unsupported is rewritten or highlighted. Before any change goes live, it runs on a set of tickets with known right answers. In a pilot, that set includes your own resolved tickets.
It sends the ticket to a person instead of guessing, and adds the problem to your list: a missing answer, an article that needs work, or two articles that disagree, with both passages shown.
Read-only access to your helpdesk, access to your help center and any internal notes you want it to use, time with your support lead to agree the tiers and rules, and 15 minutes a week during the pilot. Teams start with base9 Knowledge, so the help center is usually connected already.
Tickets are read from your helpdesk and sent to the AI model over its API to be analyzed. Your data is kept in your own workspace in our database (US East), separate from every other customer's. Which AI provider reads it, on what terms, and how long anything is kept are agreed in writing before we start.
Next step
A work email and your website is all we need. Before we talk, we'll look at your public help center.
Got it, thank you. We'll be in touch within a day or two. If it's urgent, email contact@base9.io.