The Best Ticket Automation May Be the 15 Minutes Before an Engineer Starts

The practical first job for AI in skilled operations may not be resolving the ticket. It may be removing the 15 minutes of investigative setup that occur before an engineer can begin resolving it.

That is the useful lesson in Aderant’s early production results from its Intelligent Ticket Analyzer. The system supports a 38-person SierraOps team operating Expert Sierra across 268 client environments. Before suggesting an assignment or next step, it collects relevant context from Jira, Confluence, Amazon Athena and Microsoft SharePoint. It classifies the ticket, matches available knowledge and prepares a starting point for the person who will handle it.

This is a deliberately smaller ambition than autonomous incident resolution. It is also closer to the actual source of queue friction in many support and engineering teams. Experts are often not blocked by the absence of a possible answer. They are blocked by the work required to establish what the question is, which environment it concerns, what has happened before, where the relevant documentation sits and who is best placed to take it. That setup is repetitive, cross-system and necessary. It is a better automation target than expert judgment because its boundaries are more concrete.

Start with the work before the work

Aderant measured its baseline before deployment: 15–25 minutes of manual investigation per ticket, with an average weekly volume of 34–40 tickets. The resulting estimate is straightforward. If the workflow removes a substantial portion of that preparation, it could recover 8–14 engineering hours per week. That is Aderant’s estimate from its four-week pre-deployment baseline, not a directly observed productivity gain, financial return or reduction in customer resolution time.

That distinction matters. A ticket may still require difficult diagnosis, customer communication, a code change or coordination with another team. Better triage does not prove that any of those steps become faster. But it can change the starting condition of expert work: an engineer receives a ticket with assembled context, a proposed destination and a usable initial line of inquiry instead of an empty queue item and several systems to search.

This is where many automation programmes begin in the wrong place. They frame the choice as human resolution versus machine resolution, then discover that the hard part is not generating an answer. It is gathering the correct operational facts and connecting them to a defined action. The more reliable design is to first make that preparation legible and measurable, then automate the parts with repeatable inputs and observable outcomes.

The model is one component in a prepared workflow

The Aderant implementation should not be read as a language model acting alone. Its useful output depends on deterministic integrations, scheduled orchestration, operational metadata, existing documentation and routing logic, as well as model inference. The analyzer runs hourly on weekdays rather than continuously. It gathers the available record, then produces recommendations for assignment and next steps within a workflow designed around those connected systems.

That architecture has an important consequence for teams planning similar work: improve context assembly before expanding model discretion. A polished recommendation cannot compensate for missing ticket history, disconnected knowledge bases or ambiguous ownership. Conversely, when the relevant context can be collected consistently, the model’s task becomes narrower: interpret a prepared case, classify it and return a structured recommendation that downstream systems and people can use.

The implementation also followed an earlier Aderant project that unified search across six systems. This is a meaningful progression. Human-invoked retrieval established a shared way to find operational knowledge. Scheduled workflow automation then applied that connected knowledge to incoming work. It is not a greenfield autonomous system, and it does not need to be. The operational value comes from turning a repeated search-and-sort routine into a prepared work item.

Use live outcomes to earn a narrow action boundary

Aderant moved from concept to production in five weeks, including about two weeks of monitoring-only operation against live tickets before production launch. During the initial measurement period, from June 30 to July 17, 2026, the analyzer processed 109 tickets. It recorded four misroutes, which Aderant reports as approximately 96% routing accuracy. The measurement compares the system’s assignment with the team that ultimately resolved the ticket.

This is useful evidence, but it says exactly one thing: on this sample, the system’s routing recommendation usually matched the eventual resolving team. It is not ticket-resolution accuracy. It does not show that the analyzer diagnosed incidents correctly, resolved them autonomously or improved end-to-end resolution times. Nor does 109 tickets over roughly two and a half weeks establish a mature long-term benchmark.

Still, it is the right kind of evidence for the action Aderant introduced. The team did not leap from a prototype to broad autonomy. It observed recommendations against live work, compared them with eventual outcomes, and then allowed a limited operational effect. Tickets meeting a configured confidence threshold can be routed automatically. Lower-confidence classifications go to human review.

That sequence is reusable because it ties automation scope to evidence rather than aspiration. Monitoring-only operation tests the workflow without changing the queue. Outcome comparison identifies whether a proposed assignment aligns with how the organization actually resolves work. A confidence threshold then creates a practical dividing line: automate the cases for which the system has earned enough trust, and preserve review for the rest.

Measure the queue friction, not the model’s ambition

The reported economics reinforce the case for beginning with preparation. Aderant reported total operating cost of under $30 per month during the initial period, with Bedrock inference under $1 per month. These figures are specific to this implementation and period; they should not be generalized into a universal cost benchmark. But they do make the strategic point clearer. When an automation addresses repeated investigation across existing systems, inference cost may be a minor part of the operating equation. The expensive resource is often skilled attention spent reconstructing context.

For operations leaders, the first question should therefore be concrete: where do experienced people repeatedly spend 10, 15 or 25 minutes getting ready to do their actual work? Look for queues where someone must manually pull together history, environment details, ownership information, known fixes and supporting documents before making the first substantive decision. Measure the volume, preparation time and eventual outcome before introducing automation.

Then design the workflow in order. Assemble factual context deterministically. Require the model to return a structured classification and recommendation rather than an unconstrained narrative. Run it against live work without action. Compare its recommendations with the real destination or outcome. Finally, automate only the specific actions supported by that record, with a clear human path for uncertainty.

The ambition is not to pretend that complex engineering judgment has disappeared. It is to stop spending expert time on the same preparatory scavenger hunt at the front of every ticket. Aderant’s early evidence does not prove an autonomous support operation. It shows something more immediately usable: the queue becomes easier to work when the first fifteen minutes arrive already assembled.