Build vs buy internal ticketing: an honest decision rule

We sell a commercial internal service desk, so treat everything below with the scepticism that deserves. The reason we wrote it anyway is that the build-vs-buy conversation usually happens badly: an engineer estimates two weeks, a manager approves it, and eighteen months later there is a system nobody owns and everybody depends on.

A good decision here is not about whether you can build it. You can. It is about whether the thing you would build is the thing you are actually being asked for, and whether you will still be funding it in year three.

The first is an unusual workflow that is close to your actual business. If your internal requests are shaped by something specific to how your company works — a regulated approval chain, a physical operation, a domain model no vendor has heard of — then a generic tool will be a permanent 70 percent fit and the last 30 percent is where all the pain lives. Building the thin thing that matches reality can beat configuring the fat thing that does not.

The second is an existing internal platform that already has the hard primitives. If you have authentication, an org and permission model, notification plumbing, an audit log, and an on-call rotation that already covers internal services, then a ticketing surface is genuinely a smaller project than it looks — because the expensive parts are already paid for. Teams with a real internal developer platform build good ticketing systems. Teams without one build a database table with a status column.

The third is spare capacity that is durable. Not a quiet quarter — an actual team that will still exist, with the same headcount, in two years. Internal tools do not fail at launch. They fail when the person who built them changes teams and the queue has become load-bearing.

The visible system is genuinely small: a ticket table, statuses, assignment, comments, a list view with filters, and a form. A competent engineer can build a usable version of that in a couple of weeks, and the demo will be convincing, because the demo only exercises the part that is easy.

That is roughly the first fifth of the work. What follows is the rest.

Intake connectors are the first surprise. Slack and Teams are not webhook exercises: message edits, deletions, threading semantics, attachments, permissions on private channels, rate limits, and the reality that people file tickets by reacting to a two-day-old message. Email is worse than it looks — threading headers, quoted history, out-of-office loops, forwarded chains, deliverability, and someone eventually sending a 40MB attachment. Every one of these is a week you did not plan, and they never stop, because the platforms keep changing.

Then deduplication. Ten people report the same outage in four channels and your system creates ten tickets, which is exactly when your responders trust it least. String matching does not solve this; the useful version is semantic, and it needs embeddings, a vector store, and tuning. Then permissions and identity: who can see a ticket that mentions a salary, or a security incident, or another team confidential system. Getting this wrong once is a serious incident in itself.

Then the operational tail: notification and digest logic that does not train people to ignore it, search that works on two years of history, SLA timers with business hours and holidays, reporting finance will accept, data retention and deletion, and on-call for the helpdesk itself. That last one deserves emphasis — when your ticketing system is down, it is also the channel people use to report that it is down.

Five years ago a decent internal ticketing system was a CRUD app with good taste, and building one was defensible for many teams. The expectation now includes triage that is grounded in your own history and systems, retrieval that stays fresh as documentation changes, and some degree of autonomous action. That is not a model call in a request handler. It is retrieval quality, an evaluation harness so you can tell whether a prompt change made things worse, guardrails on what the agent may do, an audit trail a security reviewer accepts, and a plan for the day the underlying model behaves differently after an upgrade.

Be honest about whether you want to own that. It is genuinely interesting engineering, which is part of the danger — it is the kind of project engineers volunteer for and then inherit forever. If your product does not sell AI support, this is capability you are building for internal use only, and it competes for the same people who could be building what customers pay for.

Build if two things are true at once. First, either ticketing is close enough to your core business that the workflow is genuinely unusual, or you have an internal platform where auth, permissions, notifications, audit, and on-call are already solved. Second, you can fund a maintenance line — not a project budget, a standing owner — for three years, and name the person today.

Buy if either is false. And buy in one more case people miss: when the real requirement is speed. If the queue is on fire this quarter, buying gets you a working system in days and building gets you a demo in two weeks and a working system next year.

There is also a legitimate hybrid, and it is underrated. Buy the queue, the triage, and the audit trail; build the connectors into your own systems through the vendor API, because those are the parts that are genuinely specific to you and the parts a vendor will never prioritise for one customer. That splits the work along the line where each side has the advantage.

Model permissions as an allow-list from day one — enumerate what automation may do rather than what it may not, because deny-lists fail open and allow-lists fail closed. Write every automated decision to an immutable audit trail with enough context to replay it later; you will need this the first time someone asks why a ticket was closed. Make escalation deterministic rather than intelligent, so that the path from stuck to human is the one thing in the system that never surprises anyone.

And measure the same things you would have demanded from a vendor: reopen rate, time to first human response, and how much of the queue never reached a person. Holding your own build to a vendor standard is how you find out honestly whether the decision was right — which is the only reason to make it deliberately in the first place.