The sticker price on a heavy ITSM platform is rarely the number that matters. Most IT teams discover the real cost at year two or three: implementation fees that weren't fully scoped, annual uplift built into the contract, consulting dependency for every workflow change, and AI capabilities that are sold as a separate consumption-based add-on. Evaluating an alternative means calculating all of that, not just comparing license line items. It also means asking whether the AI on offer actually runs the work or just routes it.

Why are IT teams re-evaluating their ITSM platforms right now?

Several things are converging at once.

The first is cost structure. Legacy enterprise ITSM platforms were built around the assumption that IT organizations have dedicated administrators, specialist developers, and months to spend on implementation. That model works if you are a ServiceNow shop with a full-time admin team. For mid-market organizations — and increasingly for enterprise teams that want IT automation without a separate platform management burden — the implementation model has become hard to justify. Professional services engagements before anything goes live, annual uplift baked into renewal terms, and consultant dependency for routine workflow changes are standard, regardless of contract size.

The second is the acquisitions. When a major ITSM platform acquires an AI automation vendor for $2.85 billion, it signals that the platform's own AI layer wasn't doing the job. For buyers, that's meaningful information: the AI capabilities now being pitched were built outside the platform, recently acquired, and are navigating integration with a product architecture that predates modern LLMs. Existing customers of that AI vendor are now operating under uncertainty about roadmap, support, and independence.

The third is the AI access cost question. When AI functionality is sold as a separate consumption-billed add-on on top of the base license — with token bundles priced per SKU, separate purchases for different departments, and metering on every AI action from ticket summaries to routing decisions — the all-in cost of "AI-enabled ITSM" is materially higher than the contract most buyers signed. Many teams that purchased AI add-ons haven't activated them or aren't sure how to build automations with them.

What is the real total cost of a legacy enterprise ITSM platform?

Buyers typically see one number when evaluating an enterprise ITSM platform. What that number doesn't include:

Implementation. Professional services engagements run $50,000 to over $1 million before the system goes live. The range is wide because scope is typically not fully defined at contract signing. Teams that signed what looked like a reasonable deal have found the implementation cost exceeds the first year of license fees.

Annual uplift. Enterprise software contracts build in price increases. Plan for 10-20% per renewal. Over three years, the total spend is substantially higher than the first-year number.

Ongoing consulting dependency. Workflow logic in a platform built around manual configuration doesn't change without someone who knows how to configure it. That means ongoing consultant hours for what would otherwise be routine changes. The cost doesn't appear in the license. It appears in the services invoice every quarter.

AI access as a separate line item. If the AI layer is consumption-billed on top of the base license, every AI action counts against the allocation. Ticket summaries, routing decisions, triage, agent resolution, workflow triggers: all metered. Enterprise-tier AI access starts at a floor that most teams don't come close to using. What looks like a generous allocation on paper often means paying for capacity you're not consuming.

The diagnostic questions worth asking before signing: What is the total contract value including professional services? What is the renewal term uplift in the contract language? If AI features are separately licensed, what is the per-action cost and how many actions does our team volume represent? What happens when we need to change a workflow: can our team do that, or does it require a services engagement?

What's the difference between AI that runs automation and AI that's a feature layer?

This is the architectural question that most ITSM evaluations skip. It determines whether the AI you're paying for actually reduces your team's workload or just changes the interface for routing tickets to humans.

Two meaningfully different models produce what looks like the same outcome on a demo:

The rules engine with an AI front end. The platform was built for manual configuration. Admins define logic. The AI layer reads requests, classifies them, and routes them to the right queue or catalog entry. A human, or a pre-configured rule, resolves the request. The AI's job is interpretation and routing, not resolution.

The AI-native execution model. The AI builds automation at configuration time. At runtime, a separate agent matches the incoming request to a pre-built, pre-approved workflow and executes it. No code is generated in the moment. The AI's role ends when the workflow is written and approved.

Serval uses the second model. The Automation Agent takes a plain-language description and generates a TypeScript workflow. You can read the code directly before anything goes live. Once published, the Help Desk Agent handles employee requests across Slack, Teams, email, phone, and web portal, matches each request to the right workflow, and triggers it. At runtime, the workflow executes exactly as written, every time. Nothing is generated or improvised on the fly.

The practical difference: if access is provisioned incorrectly in a probabilistic model, the explanation is "the AI decided to do that." In Serval's model, you can show the exact workflow that ran, who approved it, each step that executed, and the outcome. That's a different level of accountability.

The architectural question to ask any vendor: when a request comes in and your AI resolves it, what is actually executing? Is code running that was reviewed and approved before the request arrived? Or is the AI generating actions in the moment based on the request?

How does AI add-on pricing work on legacy ITSM platforms?

This is worth understanding concretely, because the pricing model shapes how teams should calculate all-in cost.

AI functionality on major enterprise ITSM platforms is increasingly sold as a separate add-on, billed on consumption. Each AI action uses tokens from an allocated bundle. Ticket summary generation, intelligent routing, triage classification, agent-assisted resolution, workflow trigger suggestions: each of these is a billable action. The ITSM module and the HR module are often sold as separate SKUs with separate token allocations.

The minimum scale for enterprise AI access in this model requires a meaningful upfront commitment. Most teams — mid-market and enterprise alike — when they actually map their ticket volume to estimated token consumption, find that either they're paying for significantly more than they'll use, or the allocation runs short faster than projected.

The activation rate is also worth asking about. A large share of teams that have purchased AI add-ons on legacy platforms have not activated them. The blockers tend to be the same: the add-on requires its own configuration, it integrates with the platform's existing rules-based logic rather than replacing it, and building actual automations still requires the same consultant or developer dependency that made the base platform slow to change.

The question to ask: how many of your existing customers at our scale have fully activated the AI add-on? What percentage have built more than five automations with it? What does it take to go from licensed to operational?

What does it look like to run Serval alongside an existing ITSM platform?

Not every evaluation is a full replacement. Many teams operate a well-established ITSM system that owns change management, asset inventory, or CMDB records. Replacing that system entirely isn't the right first move.

Serval supports a two-way sync with third-party ticketing platforms. The practical deployment pattern: Serval's Help Desk Agent handles incoming employee requests in Slack or Teams. Requests that can be resolved by a workflow are completed without a ticket ever entering the legacy system. Requests that need to escalate carry full context and route automatically to the right assignee. The legacy platform continues to receive what needs to be tracked there.

This coexistence model has a specific benefit for any team evaluating a platform switch: it lets you demonstrate automation rate against your actual ticket volume before making a migration decision. The Insights Agent surfaces which request categories are highest volume and most automatable, so the build priority is driven by your data rather than a vendor's demo. You can see what percentage of your real tickets are being fully resolved without IT involvement before committing to a migration.

Full automation means the request completes without any IT team member touching the ticket. Approvals can be part of an automated workflow: a manager approving a software access request before provisioning runs is an intentional control, not manual work. But if a human IT team member has to do anything to close the ticket, it wasn't automated.

When evaluating automation rate claims from any vendor, ask specifically what they count. If the metric includes knowledge base deflection, routing to another team, or catalog entries that require human follow-through, the rate overstates actual workload reduction.

What permissions model should control who can build and publish automation?

The control question most ITSM evaluations don't reach is who, within your organization, has the authority to create a workflow that provisions access to a production system.

On most ITSM platforms, that capability is tied to general admin access. If you can configure routing logic, you can generally create automation. That's a meaningful gap for teams where IT is touching user accounts, production APIs, and sensitive data.

Serval uses layered role-based access control on the workflow layer itself. Within each team, roles are explicitly tiered: Agents can run existing workflows. Contributors can install pre-built workflows but can't create custom ones. Builders can create and edit workflows, configure approval procedures, and define access policies. Managers can configure which integrations Serval can reach and what API scope those integrations have access to.

That API scope ceiling is a hard limit. When a Manager configures an integration, they define exactly what Serval is capable of accessing. A workflow can't exceed that scope at runtime. The AI can't access an endpoint that wasn't explicitly included in the integration configuration.

This means two things for compliance. First, the set of possible actions the platform can take is defined by humans, in advance, not inferred at runtime. Second, the right to expand that set of possible actions is a specific role, not a consequence of admin access. The Serval CLI gives developers full control of workflow code from their local environment, with version control and collaboration support, for teams that want to manage workflow development as they would application code.

What does an audit trail for automated IT actions actually require?

The difference between a log and an audit trail is specificity and accessibility. Most IT platforms have logs. Fewer produce records that are actually useful to a security reviewer or an auditor.

A useful audit trail for IT automation shows: what triggered the workflow, which workflow ran and at which version, every step that executed in order, who approved it and when, the outcome of each step, and the final result. That record should be tied to a specific user and timestamp, and it should be exportable without a custom database query.

Serval logs every workflow run with a full step-by-step record. The Workflow Manager provides direct access to run history across all workflows. Beyond browsing, you can build audit workflows that run on a schedule: a weekly CSV of all access provisioning and deprovisioning actions with approver and timestamp, a monthly usage report by workflow, an approval turnaround summary. Those workflows post to Slack or export to your document management system. For SOC 2 reporting, the model is to build the evidence generation once and schedule it, rather than assembling screenshots manually before each review.

The compliance use cases are documented: access change audits with approver and timestamp, change management records tied to workflow version history, SOC 2 evidence generation, incident response review of workflow activity during a security investigation.

What questions should mid-market and enterprise IT teams ask before committing to any ITSM platform?

The questions that cut through claims fastest are the ones that require concrete answers about architecture and commercial terms:

On total cost: What is the all-in contract value including professional services? What is the renewal uplift term? If AI features are separately licensed, what is the consumption cost at our ticket volume? What workflow changes require a services engagement, and what can our team do unassisted?

On AI architecture: When a workflow runs, is code executing that was reviewed before the request arrived, or is the AI generating actions in the moment? Can you show me the code that will run before any employee triggers it?

On permissions: Who in my organization can create a workflow that provisions access? Who can configure which APIs the platform can reach? Are those permissions enforced in the platform or advisory?

On activation: What percentage of your customers at our scale have activated the AI features they licensed? What does it take to go from licensed to running five automations?

On deployment: What are my options if we have data residency requirements? Is hybrid or self-hosted deployment available?

On enterprise readiness: What compliance certifications does the platform hold? Can it run in our Kubernetes environment for regulated workloads? What does the security architecture look like at the execution layer?

Serval supports fully cloud, hybrid, and fully self-hosted deployment in your own Kubernetes environment. Workflows are TypeScript in version control, auditable to the same standard as application code. The six-layer security model — team segregation, RBAC on who can build, API scope ceilings, execution controls, deterministic execution, and the air gap between the build and execution layers — is built for enterprise security review, not bolted on after the fact.

A vendor with deliberate answers to all of these has made architectural choices that support them. One that redirects to a demo has probably deferred these decisions to later in the implementation.

The right alternative to a heavy ITSM platform is not necessarily the simplest one. It's the one where the AI actually executes automation rather than routing requests, where the total cost is visible before contract signing, where your team can build and change workflows without a consultant, and where the audit trail your security team needs is produceable without manual work. Those are the criteria that separate a real improvement from a different version of the same problem.