Connecting support tickets to infrastructure actions

In most operations teams, a ticket and the infrastructure it concerns are connected by a person. Someone reads the request, works out which machine it is about, opens a different tool, performs an action, comes back, and writes a reply. That relay is where the time goes, and it is also where inconsistency enters. This guide covers how to connect the two systems directly, and which controls make that safe.

The four translations

Connecting a request to an action means performing four translations, each of which can fail independently. Designing them as separate stages is what makes the whole thing debuggable.

1. Text to intent — what is actually being asked?
2. Intent to asset — which specific system does this concern?
3. Asset to permission — is this action allowed, here, for this requester?
4. Action to outcome — did it work, and how do we know?

Text to intent

Intent classification is the stage where language models genuinely help, because the input is unstructured prose written by someone describing a symptom rather than a cause. 'The site keeps timing out' and 'getting 503s since this morning' and 'is the server down?' may all be the same intent.

Two design points matter here. First, classify into your own operational taxonomy — the categories that map to workflows you actually have — rather than a generic support taxonomy. Second, carry a confidence score forward and use it as a gate. A classification you are not confident about should route to a person, and that routing is a success, not a failure.

Intent to asset

This is the stage that is most often underestimated. A ticket rarely names a hostname. It names a domain, a service, an account, a URL, or nothing at all. Resolving that to a specific asset requires your inventory and your account records, and it needs to fail loudly when it is ambiguous.

Build the resolution as an explicit lookup with a defined precedence: requester's account, services on that account, the identifier mentioned in the ticket, recent tickets from the same requester. If more than one asset matches and the action is anything other than read-only, stop and ask. Acting on the wrong machine is worse than acting slowly.

Asset to permission

This is the control layer, and it should be entirely deterministic — no model involvement. Given an intent, an asset, a requester and an environment, is this action permitted?

• Is the requester authorised for this account and asset?
• Is this action registered and permitted for this asset class and environment?
• Does the asset's tenant policy require approval for this action?
• Is the asset inside a maintenance window where automation should stand down?
• Has this action already run on this asset recently, suggesting the fix is not holding?

Action to outcome

The action runs, and then the loop has to close. Closing it well means three distinct things: re-measuring the original symptom, writing the result back to the ticket in a form the requester can read, and recording the run for your own review.

Re-measuring is the part that gets skipped. If the ticket said disk was full, the verification is a disk measurement, not a successful cleanup command. If the ticket said a service was unreachable, the verification is a request from outside the host, not a process check on it.

What to write back to the ticket

The reply is a product surface, and a bad one undermines the whole thing. A good automated update contains: what was understood from the request, what was found, what was done, what the result was, and what happens next. Specific values beat reassurance — 'disk usage reduced from 94% to 61%, 42 GB reclaimed from rotated logs' is worth more than 'the issue has been resolved'.

Keep the internal record richer than the customer reply. The run history should hold the full diagnostic output; the ticket needs the summary and the outcome.

Rolling it out

A sequence that works in practice, over roughly two months:

1. Classification only. Tickets get labelled with intent, asset and confidence. Nothing acts. You review the labels for two weeks and fix the taxonomy.
2. Context attachment. The workflow gathers and attaches the diagnostic context a human would have gathered. Agents immediately save time, and you learn whether the context is the right context.
3. Draft replies. The workflow drafts the reply and the proposed action; an agent reviews and executes. You see where its judgement differs from yours.
4. Execution on one narrow category. The lowest-risk intent, on one asset class, within one tenant tier. Verification mandatory.
5. Expansion, one category at a time.

Failure modes to watch for

• Confident misclassification on unusual phrasing. Mitigate with confidence gates and by reviewing the lowest-confidence decile weekly.
• Asset ambiguity resolved by guessing. Mitigate by requiring a unique match for any action that changes state.
• The same remediation running repeatedly on the same asset, masking a structural problem. Mitigate with a repeat-run detector that escalates instead of re-running.
• Replies that read as evasive because they lack specifics. Mitigate by requiring measured values in the template.
• Silent scope creep as new actions get registered without review. Mitigate by treating the action catalogue as a reviewed artefact.

The measurement that matters

Track the share of tickets in automated categories that were resolved without a person opening them, and track it alongside the rate of incorrect escalations and unverified outcomes. The first number is the benefit. The other two are the cost. A programme that only reports the first number is not being honest with itself.