Why operations files a ticket for something it could do itself
A customer’s setup fails. The operations person who noticed can see that it failed. They cannot see why — the job log lives somewhere they have no access to — and they cannot retry it, so they file a ticket. Two hours later an engineer reads the log, sees a capacity timeout, retries it, and closes the ticket. Everyone did their job. The customer waited two hours for a click.
The ticket is a permission request
Strip the ceremony and the ticket says: I am not allowed to look at this or do this; would someone who is, please. The engineer is not adding judgment. They are adding access. Every organisation has a class of tickets like this, and it is usually the largest class.
Why the permission was never granted
Because the only way to grant it was all-or-nothing. Give operations the job logs and they get every log. Give them a retry button and they get retries in production, unbounded. The tools did not have a way to say “this team may read setup logs for their own customers and retry in staging outright, and in production with a manager’s yes.” So the safe answer was no, and the ticket queue absorbed the cost.
What the fix looks like
- The person asks, in plain language, why the setup failed. They get the failed step, the log excerpt, and the customer record — within the access they already had.
- The agent proposes the retry, scoped to that one customer, and says what it will not do.
- In staging it runs on their confirmation. In production it goes to the on-call manager, who sees the same evidence and says yes.
- A receipt lands in the conversation and in the audit log. The ticket is never filed.
Two hours becomes four minutes, and the engineer keeps the afternoon.