Use case · AI Studio
End-of-life mails to tickets
The email everyone receives and nobody handles: vendor end-of-life notices become verified tickets in your own ticket system, with deadline, priority and owner.
01 · The brief
The bottleneck is not the decision but the way there.
Every operation knows this email. A vendor discontinues a version, a certificate expires, an audit deadline approaches. The email is polite, names a date far in the future and demands nothing concrete. You read it, find it important, and do not act on it. Because between “we should look into that” and a task someone can pick up lies half an hour of research that nobody has spare in the morning.
Anyone working in DevOps knows this on a weekly basis. Whether anything needs doing at all is not in the email. So you click through consoles and account lists and find out after a quarter of an hour: the affected system is legacy that nobody has touched for two years. Nothing to do. The quarter of an hour is gone anyway.
The brief, as it arrived in our own operations one morning at 09:12, one sentence, typos included: “these days we keep getting emails from our hosting provider about products to be migrated because of end of life. Are there tickets for this yet? If not please create them accordingly.” No system named, no deadline, no recipient, not a word about where the tickets belong. The agent still did not ask a single question back.
02 · What the team does
What happened in the six minutes.
Sorted the mailbox
The agent went through the emails of the last four months and read the relevant ones in full. It turned out this was not one topic but four: platform stack, cache service, database and messaging cluster, each with its own deadline.
Checked the ticket system for what already exists
Several search terms, open and closed tickets, years back. One topic had long been recorded and was in progress. It read that ticket completely, including all comments, to know where things stood and who was doing it, rather than placing a second one next to it.
Checked the hosting for what is really running
Via the provider’s interface it listed all applications and checked add-ons and plans for the affected ones. It could not get at the version numbers; its access was not allowed to read them. So they are in the ticket as what they are: details from the email, with the command next to them that lets the assignee verify them in ten seconds.
Said who has to do what
From old tickets it knew what runs on the most critical instance: a real-time display on which revenue from paying customers depends. So the ticket does not say “forced upgrade looming” but what an unannounced restart in the middle of the day would do. It addressed three people, each with what is needed from them: the decision on the maintenance window, implementation in their own area, acknowledgement for planning.
03 · How it works
How the agent proceeds.
Four minutes to the first finished ticket, six minutes to the complete report back. Three minutes later the team lead had passed the ticket on to the person responsible, without a single question. That is the measure of whether preparatory work is any good.
Step 01
Read
Go through the mailbox, extract topics and deadlines from the emails.
Step 02
Match
Check the ticket history: what is already recorded, in progress or done?
Step 03
Verify
Cross-read the running infrastructure via the provider’s interface: what is actually affected?
Step 04
Create
Ticket with deadline, priority, owner and reasoning. Or, with reasoning, no ticket.
Set this process up in your company? Request a conversation →
04 · From practice
Two tickets it did not write, and one error it reported itself.
The messaging cluster needed no ticket.
Four topics, but only two new tickets. One already existed. And for the fourth, a look at the running infrastructure showed that the provider had long since raised the version itself and the cluster was running. So no ticket, with reasoning. That is the difference between an automation that creates one ticket per email and preparatory work you can trust.
It reported the gap instead of filling it.
The existing ticket stated that three applications had been explicitly referred to another team. Whether that team has a ticket for them it could not see; it is not allowed into their project. Exactly that is what it added, rather than making the gap look bigger than it could prove. It created nothing; it asked.
The error it reported itself.
For one of the two tickets it was supposed to add the assignee afterwards. The ticket system acknowledged the write twice as “successful” and did nothing. Because it re-reads and compares after every write, this was noticed. Its report back therefore did not say “done” but: did not take effect, please add by hand.
05 · The outcome
What came out of it.
A mailbox full of polite emails becomes a backlog with dated deadlines, set priority and named owners. The decision is made on verified details instead of a skimmed email.
The path is verifiable, not just the result: wherever no ticket was written, the reasoning is attached, a linked ticket or a look at the running infrastructure.
- Topics and deadlines extracted from the emails, matched against the ticket history.
- A ticket only where there is really something to do, with reasoning.
- Responsibilities derived from the history, recipients addressed directly.
- Its own errors reported instead of reported as done.
06 · Systems and access levels
Which access was needed.
A single access is allowed to write, and it is at the lowest level the task permits. Nothing was rolled out, reconfigured or emailed on the systems themselves.
| System | Used for | Access level |
|---|---|---|
| Mailbox | Find and read end-of-life notices | read only |
| Hosting provider | Applications, add-ons, plans | read only · version data not accessible |
| Ticket system, reading | Ticket history, responsibilities, cross-references | read only |
| Ticket system, writing | Create tickets and comments, with labels, status, assignee | guest role, this one project only · no code, no deploy |
| Own workspace | Helper scripts and notes | write only there, nothing in production systems |
07 · Limits
Where the limits are.
The agent prepared the matter; it did not solve it. The affected instances keep running until the maintenance window. But they now run visibly: the deadlines are dated in the ticket, the priority is set. The matter is in the backlog instead of in a mailbox.
This is one case, not a rate. It was favourably cut for an agent: sources machine-readable, deadlines in plain text, and a ticket history from which responsibilities could be derived. Where the knowledge lives only in people’s heads, the same approach yields considerably less.
Two things follow. Whoever keeps ticket history, responsibilities and deadlines in writing makes their operation analysable in the first place. And a run that takes six minutes belongs not on demand but in the calendar: once a week, across all mailboxes where such emails arrive.
Frequently asked
Frequently asked questions about this use case.
Does this also work with emails from other vendors, for example about certificates or cloud services?
Yes. The approach is independent of the sender: read the emails, extract topics and deadlines, match against ticket history and running infrastructure, create a ticket or, with reasoning, don’t. Tailoring it to your vendors is part of the pilot.
Does it run automatically?
In the first step on demand, in the second on a schedule: once a week across all mailboxes where such emails arrive. Then the question is no longer whether someone read the email, but only whether the ticket is right.
What does the agent need for this?
Read access to the mailbox and to the infrastructure at the provider, read and restricted write access to the ticket system. Every machine-generated ticket carries in its first line the person who triggered it.
More use cases
Related use cases.
Marketing
Performance marketing end to end, analysis, creation and rollout in one system, with a human at the gate.
Energy management
Spot load peaks, understand consumption, control costs, before they show up on the bill.
Finance & controlling
Consolidated closings, automatic payment reconciliation and early liquidity warnings, at the push of a button.
Does this sound familiar?
In a first conversation we look at your processes together and sketch out where an agent team would make the biggest difference. Free of charge and without obligation.