A bot reads every email in the support inbox, works out what the customer needs, answers it, and files the case. People only see what it hands over.
Most ask the same handful of things — the QR code will not install, there are no signal bars, there is no data icon. Each one still needs the order looking up before it can be answered properly.
Someone opens every message, finds the order, then writes broadly the same reply again.
Auto-replies, CC-ed threads and messages from non-customers all land in the same inbox.
Let a bot handle the known answers and hand a person only the cases that genuinely need judgement.
Nothing bespoke. It reads the real mailbox, uses the real helpdesk, and calls the same business tools a person would.
Read through Microsoft Graph, including attachments and inline images, so a screenshot of an error is visible to it.
Answers come from the published eSIM.net helpdesk articles, not from invented knowledge.
67 MCP tools cover orders, lines, payments and QR codes — the same audited code path as the admin site.
Every message becomes a SupportCases row: type, outcome, who replied, and why.
The point: the bot has no private database and no shortcut. If a person could not do it in the admin system, neither can the bot.
Seven steps, every one recorded. The bot decides between answering, handing over, and deliberately saying nothing.
Steps 2–3: it works out what kind of problem this is, and whether the sender is even a customer.
Steps 4–5: the order, the line and its status are read live before a word is written.
Steps 6–7: reply, hand over, or stay silent — and leave an auditable trail either way.
Just over half of all messages got a real answer from the bot.
Auto-replies, non-customers, CC-ed copies and superseded messages. Replying to these is noise, not service.
Flagged in the inbox for a person — and most still got a holding reply first.
Because the problem set is narrow and well documented, a bot can be genuinely good at it.
Will not scan, already used, wrong device.
Line status, bars and network checked live.
APN and data bar settings confirmed.
Voice and text issues on the plan.
Recognised, recorded, and never paid by the bot alone.
If the answer is “here is your QR code again”, the bot resends the QR and invoice itself through an audited tool — the customer gets a fix, not an instruction.
A fixed set of instructions: classify the email, confirm the customer, check the order, then choose one of eleven reply actions. The same steps run on every message.
gethelpdeskarticle · getcustomer · getprocesses · sendqrcode · updateemail — and nothing it has not been given.
An Outlook category is set on the message and a case row written, so the inbox itself shows what has been handled and what is waiting.
Why the thread matters: the bot groups messages by their email conversation, so a follow-up is answered in context and an older message in a settled thread is recognised rather than answered twice.
Reads and classifies the inbox, drafts the reply.
Looks up orders and lines, resends QR codes.
Mailbox access, categories, attachments, images.
Published articles as the single source of answers.
● No refunds by bot — 328 asked, 8 paid, all by a person
● Non-customers filtered — never replies to a stranger's thread
● One message, one reply — threads are grouped, not re-answered
● Escalation is explicit — flagged in the inbox a person already watches
● Every case recorded — type, outcome, handler and reason