How many fulfiller seats will you need in 2029?

Somewhere in your organization this year, somebody is going to sit down and decide how many fulfiller seats to license, which tier to sit on, and for how long. Three years will be presented as the default. The quote in front of that person will be detailed about price and almost silent about the thing it actually rests on, which is a forecast of how much work your service desk is going to receive between now and 2029.

Nobody writes that forecast down. It arrives implied by the shape of the contract: per seat, per module, per tier, with an uplift every year and, since the April 2026 repackaging of the market leader's tiers, a metered pool of AI assists sitting on top. Every one of those lines scales with volume, or with the headcount you keep in order to handle volume. Signing it is a statement that the queue you have today is roughly the queue you expect to have in three years.

Now set that against what has happened in your own estate over the last twenty-four months. Take password resets, or access requests, or onboarding, or the laptop that turned slow after an update, and ask what share of each still reaches a human being. In most enterprises I talk to the answer has moved, and it has only moved in one direction.

I think the direction is settled and the only open question is pace. If that is right, then committing three years at a higher tier is a forecast I would struggle to defend in front of a CFO. That is not because the software is bad. It is because it buys processing capacity for a queue the same organization is spending money to shrink.

What a three-year ticketing contract assumes

The commercial model underneath enterprise service management was designed in an era when ticket volume rose every year, and it still behaves that way. You pay per fulfiller seat, which assumes a stable team working a stable queue; per module, which assumes the practices stay separate; and by tier, where the tiers themselves are sized by scale. On top of all of that comes a contracted uplift of somewhere between 7 and 12 percent a year, applied to a base that is only ever expected to grow.

Reload preview

The newer layer is more interesting, because it bets against you twice. AI consumption is now metered. Since ServiceNow replaced its five legacy tiers with Foundation, Advanced and Prime on April 9, 2026, each agentic action draws 25, 50 or 150 assists from a contracted pool, depending on how complex it is. The pool therefore drains faster the better your automation works. Spend a year getting employees to ask the assistant instead of emailing the desk, get the knowledge good enough that answers land, get automations executing reliably, and the reward for all of that effort is a larger invoice. We go through the mechanics of this, and how to negotiate around it, in our piece on treating your ServiceNow renewal as an AI negotiation.

Reload preview

So one half of the bill assumes your queue holds, and the other half assumes your success is billable. Neither assumption is one I would want to inherit for thirty-six months.

What is actually happening to the volume

This is not a projection about some future architecture. It is a description of work that has already left the queue in organizations running agentic AI properly, and the largest categories on any service desk are each losing volume for a different reason.

Reload preview

Identity and access accounts for 16 percent of volume in Fixify's 2026 benchmark of more than 50,000 tickets. Password resets, group membership and application entitlements are rule-bound and verifiable, which is exactly the shape of work that gets handled end to end without a person. It is the first thing most enterprises automate, because the rules can be written down and audited.

Joiners, movers and leavers take another 17 percent, and these were never support problems in the first place. A new starter needs accounts, entitlements, hardware, software and approvals across four systems and three teams, and the only reason a ticket ever existed is that somebody needed a way to track who had done what. Hand that sequence to an orchestrator that calls each system, collects the approvals and chases what has not happened, and the work still gets done while the ticket never opens. The event in the HR system started everything, and nobody had to ask. (The leaver side is where this matters most.)

Applications are the largest bucket at 38 percent, and they are shrinking without anybody doing anything deliberate. Most of the estate moved to SaaS, where the vendor runs the upgrade and the client is a browser tab, so the break-fix failures that used to generate thousands of tickets no longer occur. What remains is comprehension rather than repair, and a question about how to do something is answerable from knowledge, provided the knowledge is good.

Devices are the hard one, and the only category not getting quieter on its own. Device faults are chronically undercounted because Outlook crashing gets filed as software and Microsoft Teams audio breaking up gets filed as collaboration. The ones that do get logged take a median of 80 hours to close, since a technician gets five minutes of remote access to a machine they cannot reproduce the fault on. Rapport, our agentic endpoint product, exists for that gap: it investigates on the device itself rather than inferring the problem from somebody else's screen. I have written the longer version of this argument in The Ticketless Enterprise, including why the real device share is well above what any benchmark reports.

The phone queue cuts across all four of those categories, and it is the channel almost nobody automated. It is also where the hardest cases land, because an employee who cannot log in cannot open the portal to say so, and a lockout at seven in the morning becomes a phone call by definition. Voice agents now handle that conversation end to end: identity verified, account unlocked, the caller told what happened and why. The same channel reaches a population that never appeared in your ticket counts in the first place: frontline and shift workers without a desk, and employees who would far rather explain a problem out loud in their own language than type it into a form in a second one. Those people have been absorbing their own IT problems for years, which is worth remembering whenever somebody argues that volume cannot fall because it has been flat for a decade.

Nobody is running a ticketless enterprise today, and Rezolve.ai is not claiming otherwise. What I am claiming is that four separate categories are heading the same way for four unrelated reasons, which is a much harder trend to argue with than any single one of them.

What changed is the cost of building an automation

If you have sat through a decade of automation initiatives that never moved the queue very far, healthy skepticism about all of the above is the correct response. So it is worth being precise about what is different, because the reason volume stayed flat for twenty years was never a shortage of appetite.

The constraint was that every automation was a project. Each one needed scoping, a developer or an integration partner, a connector that had to be bought or built, a test cycle and a change window. That cost per automation was high enough that the work had to be rationed. Only the twenty highest-volume workflows ever cleared a business case, the long tail that made up most of the queue never got near a developer, and enterprises ended up permanently starved of automation without anybody ever deciding against it.

Four things have moved that equation, and they compound.

In Rezolve Creator Studio, workflows and automations get built conversationally. You describe in plain language what should happen, and the product assembles the steps, the system calls and the error handling, with a person reviewing and approving before anything runs against production. Work that used to occupy a sprint now takes a conversation and a review. Underneath that sits a library of workflows and automations already built for the processes every enterprise shares, so most teams are adapting something that exists rather than starting at an empty canvas. Integration is built in rather than bought, through an iPaaS layer inside the product, so connecting to the systems an automation touches is not a separate procurement with its own license, its own specialist and its own renewal date. And for the internal applications that have no standard connector (a longer list in most enterprises than anybody admits in public), custom MCP hubs expose those systems to agents without commissioning a bespoke integration each time.

Put the four together and the cost of building one automation falls far enough that rationing stops being necessary, which is the part that matters for your forecast. A backlog that sat untouched for ten years, because no individual item was ever worth a developer's quarter, becomes something a service desk team works through themselves. That mechanism is why I think the volume assumption inside a three-year contract is wrong by more than most people expect. Not because any single category collapses, but because the thing that used to limit how fast they could shrink has largely gone.

A renewal is a forecast you publish

Here is the part worth sitting with, and I do not mean it as a criticism of anybody's judgment, because almost nobody experiences a renewal as a forecasting exercise.

A renewal gets read as a signal whether you intend it as one or not. Your CFO, who is already asking what the AI budget is producing, reads a three-year commitment at a higher tier as a view about the next three years. Your service desk leadership reads it the same way. Your account team certainly reads it that way, and prices accordingly next time. If you genuinely believe volume is going to fall, you would buy differently: shorter term, lower tier, true-down rights, consumption terms that do not charge you for adoption. When the contract carries none of those protections, the belief either is not held or never reached the paperwork.

Reload preview

In my experience it is almost always the second one, because renewals default. A date arrives, a quote arrives, and the quote gets compared against last year's quote rather than against next year's queue. Somebody negotiates a discount that gets reported as a win, and the structural question never gets asked because no part of the process is designed to ask it. That is not a failure of intelligence. It is a failure of the calendar, and the fix is to do the thinking a long way before the quote shows up.

Where a ticketing system still earns its place

There is a real case for keeping a system of record, and anybody making the argument above without acknowledging it is not being straight with you.

Regulated work needs a record where the record itself is the deliverable, not a by-product. Audit and evidence need somewhere durable and queryable to live. A decade of integrations into HR, FinOps, procurement and asset systems represents real engineering that nobody should rip out for sport. And genuine human judgment (the exception to policy, the unusual access request, the decision somebody has to own) belongs in a tracked, assigned, reviewable artifact, which is roughly what the ticket was invented for before it became the container for everything else.

Every one of those is an argument for a system of record, though, and a system of record is a modest thing. It needs to be reliable, auditable and integrated. It does not need to be the most expensive line in your IT budget, it does not need a tier above where your estate sits, and it does not need to keep growing by a contracted uplift every year while the work it records is shrinking.

What to buy instead

The practical version of all of this is not "do not renew." It is to buy for the shape the queue is taking rather than the shape it had.

• Buy the intelligence layer first, and size the record to whatever survives it. The layer that removes volume and the system that records what is left are separable purchases, and in that order the second one gets cheaper.
• Negotiate one or two years rather than three. A shorter term costs you some discount and buys back the decision, which in a market repricing this quickly is worth more than the discount.
• Get true-down rights and co-termination. If the forecast is a declining queue, you need the contractual ability to act on a declining queue.
• Refuse consumption terms that price your own success. Flat or banded beats per-assist, and if per-assist is unavoidable, negotiate the overage rate and the top-up terms rather than only the headline tier.
• Allocate tiers by population, not by organization. Most of your seats do not need autonomous agents, and standardizing everybody on the top tier is the single largest avoidable number in a modern ITSM quote.
• Track absolute volume per thousand employees, year over year. Deflection percentages can rise while the queue grows, which is why deflection is the wrong number to report. Absolute volume is the number that tells you whether your forecast is coming true.

Back to the room

The person deciding your renewal is going to publish a forecast this year either way. Signing three years at a higher tier forecasts a queue that holds. Signing one year at a lower tier with true-down rights forecasts a queue that falls. And doing nothing until the quote lands forecasts whatever the vendor put in the spreadsheet, because the default shape of the contract becomes your view by omission.

What I would want, in that room, is for the forecast to be the one I actually believe: written down somewhere, argued with my own volume numbers, and reflected in the term and the tier rather than discovered three years later. The seat count you sign is the shortest possible summary of what you think the next three years hold, so the useful exercise is being able to say out loud what number you expect to need in 2029, and why. If you want help building that comparison for your own estate, learn more. And if you want the argument underneath it in full, start with The Ticketless Enterprise and what your service management estate actually costs.