Watch the demo
← Blog

We stopped trying to route tickets faster. We built a helpdesk that tries not to need one.

Most helpdesk software competes on how quickly it can hand a problem to the right person. We think that solves the wrong step — here’s what we built instead.
· 6 min read · The TodaysBru team
Every helpdesk we’d used before treated a ticket as the starting point — the moment work begins. Someone hits a wall, files a request, and the system’s whole job is to get that request to a human as fast and correctly as possible. Faster triage, better routing, cleaner SLAs. All useful. All still assuming a person has to get involved every time.
We built TodaysBru around a different starting point: the moment before the ticket, when someone is still just typing out what’s wrong. If the system can answer well right there — grounded in real documentation, not a guess — a ticket never needs to exist at all. And the tickets that remain should leave the system a little smarter than they found it, not just closed and forgotten.
That idea turned into four things we haven’t seen bundled together anywhere else. Here’s each one, in the order a real request actually moves through them.

Deflection: most tickets never get filed

When someone types a problem into chat, we check it against the knowledge base before doing anything else. Not a keyword search bolted onto a chatbot — the reply itself is grounded in a real article, and that source is tagged right underneath the answer so nobody has to take the AI’s word for it.
Assistant reply grounded in a knowledge base article, source tagged underneath
Assistant troubleshooting steps with a note that a matching ticket is already open
Left: a grounded answer with its source visible. Right: the same conversation catching a duplicate ticket mid-troubleshoot — something a static form structurally can't do.
When the steps genuinely don’t fix it, the whole conversation attaches to the ticket automatically. Nobody has to re-explain the problem to whoever picks it up next.

Automation: rules you write in a sentence

The second thing we kept running into: workflow builders that make simple automation feel like programming. “If category is Onboarding and it resolves, provision an Okta account” shouldn’t require a flowchart. So in TodaysBru, an admin just writes that sentence.
The AI runs exactly once — to translate English into logic when the rule is created. After that, it never gets consulted again.
The assistant parses it into a trigger, a condition, and concrete actions, all laid out for review before anything is live. New rules always start disabled, and you can preview which open tickets would match before you ever flip the switch.
A parsed workflow rule showing trigger, condition, and three actions for review
A ticket already routed to DevOps and bumped to High priority, untouched by a human
Left: the parsed rule, reviewable before it goes live. Right: a real ticket, routed and reprioritized the instant it existed — no agent, no AI call, just the rule doing its job.

Forms: request forms that ask, instead of making you hunt

Structured request forms — a company laptop, a Slack channel, a system access grant — still have their place; some requests need specific fields captured cleanly for approval routing. But nobody enjoys finding the right form. So chat recognizes the request and fills the form itself, asking only for whichever fields are still missing, one at a time, then confirming before it submits.
Chat asking for the fields still missing from a request form, one at a timeSame approval routing as filling out the form by hand — the requester just never has to go find it.

Knowledge: the base drafts its own next article

This is the one we’re most proud of. Most knowledge bases rot because writing articles is somebody’s side project, and side projects lose to whatever’s on fire that week. So TodaysBru watches for it: when enough resolved tickets share a real problem with no article covering it, it drafts one — title, keywords, numbered steps, grounded in the actual tickets it came from.
We didn’t trust a single model to publish unsupervised, so we don’t let it. A second AI model, from a different vendor than the one that wrote the draft, reviews the work independently and leaves specific notes on what it thinks is missing or unconfirmed.
A complete AI-drafted knowledge base article with title, keywords, steps, and source tickets
A tooltip showing the second model's specific critique of the draft
Left: a full draft, not just a title and a blank page. Right: the second model's actual critique — a real objection, not a rubber stamp.
An admin’s job becomes editing one flagged line and hitting publish — approval, not authorship.

Six more things worth knowing

The four builds above get the headline, but they only work because of some quieter decisions underneath them.
  • No AI in the hot path. A model translates English into logic once, at authoring time. Every match after that is plain code — same trigger, same outcome, nothing to hallucinate at ticket volume.
  • Nothing ships unsupervised. New workflow rules start disabled. KB drafts need a publish click. Every automation has a human approval gate before it can touch a real ticket.
  • Two vendors, one draft. Every self-written KB article is reviewed by a second model from a different vendor than the one that wrote it — an adversarial check, not a formality.
  • Web, chat, email, Slack — one ticket. Every channel a request can arrive through hits the same rules, the same routing, the same daily limits. No channel quietly falls out of sync with the others.
  • Breaches aren’t hidden. SLA outcomes are scored automatically, breach included. A frustrated tone in a message bumps priority on its own, instead of waiting on someone to notice.
  • Four roles, one hierarchy. User, agent, manager, admin — each a strict superset of the last. Growing the team doesn’t mean re-architecting who can do what.
None of this replaces the people running support — it just changes what reaches them. Fewer repeat questions, fewer duplicates, automation that doesn’t need re-explaining every time it runs, and a knowledge base that keeps pace with the tickets instead of trailing behind them. That’s the bet: every ticket that never needed a human is one your team gets to spend on the one that actually did.