A Prompt Cheatsheet for Your Ticket Queue

Here is a prompt that will do real damage: answer the tickets.

A perfectly reasonable English sentence. Also, once your assistant is connected to your helpdesk over MCP, a request to email nine strangers text you have never read — reply_to_ticket posts the message on the thread and sends it immediately, with no draft state, no outbox and no undo. The agent did exactly what you asked. The problem was the asking.

The difference between a prompt that works and one that goes wrong is almost never length or politeness. It is two things, and a third for anything that leaves the building. A good prompt names the outcome, what should be true when it finishes. It names the criterion, how to decide the borderline cases. And when the work reaches a real person, it names the checkpoint — where you get to look before anyone else does.

What follows is a cheatsheet organised the way a queue gets worked, with a note on each prompt about which of those three it carries. The tool names are Helmdesk's MCP server; the argument holds for any agent with credentials that reach customers.

The morning read

Everything here reads and changes nothing, which makes it the one place you can be sloppy with phrasing. On a read-only key the worst outcome is a wasted minute.

• "What happened in Ledgerly overnight — queue, errors, anything waiting on me?" One get_project_overview call answers all of it: tickets by status, how many await a reply, how many have gone stale, open error issues, email delivery, and what the automations left you. It replaces about six list calls.
• "Which tickets are waiting on us rather than on the customer, oldest first?" The criterion is the interesting part. "Waiting on us" is not the status field — it is who sent the last message — and list_tickets carries that, so this is an answer rather than an inference.
• "Any error group from the last day that a customer has already written in about?" Crossing list_log_issues against list_tickets is the question nobody asks by hand, because by hand it means holding two dashboards side by side.

Notice none of these say "and fix it." Staple an action onto a read and the criterion becomes whatever you noticed while reading — a criterion only you can see.

Triage

Triage is the safe half of the queue: statuses, priorities, tags and internal notes all stay inside your account. Sweeping instructions are appropriate here, because being wrong costs a tag.

• "Go through the new tickets in Nightjar. Anything mentioning 'charged twice' or 'refund' is urgent and category billing. Everything else, pick a sensible priority and tag it, then tell me what you decided and why." The model prompt for the whole post. The outcome is every new ticket classified; the criterion is quoted literally; the last clause makes the agent show its reasoning, which is how you learn your rule was too broad.
• "Assign everything tagged billing to whoever handles billing." Well-formed because it delegates the lookup — the agent reads list_team_members to turn that phrase into a real user id.
• "Tickets 118 and 121 are the same bug. Note that on both, with a summary of what I found." add_ticket_note is staff-only: never emailed, never on the portal, does not move the status. The tool for recording something without talking to anyone.
• "Drop the needs-triage tag from anything that now has a priority set." remove_ticket_tag is idempotent — a ticket that never had the tag is a no-op, not an error — so re-run this every morning without thinking.

One trap, worth being blunt about. Close out anything that looks resolved is a bad prompt twice over. "Looks resolved" is not a criterion, it is a feeling you were having about your own queue. And closing is not free: resolving emails that customer a satisfaction survey, so a sweep across forty stale tickets is forty surveys at once. Say the criterion instead — no customer reply in 21 days and the last message was ours — and ask to see the list first.

Answering

This is where prompts reach people. Four of the tools on this side of the queue are outbound and none of them can be recalled.

• "Read ticket 41, find the article that answers it, and draft a reply citing it. Do not send — show me first." There is no draft tool and there need not be one: the draft sits in your chat window until you say otherwise. That is the checkpoint, and it costs one clause.
• "Good. Send it." A real prompt, and deliberately short. If the send is a clause in the same sentence as the writing, you did not review anything — you authorised it in advance.
• "I shipped the CSV export fix. Find every open ticket about it and draft one reply each, written from the actual fix rather than a template. Show me all of them together, and don't resolve anything yet." Outcome, criterion and checkpoint — plus a fourth instruction that matters: holding back the resolve keeps the survey out of it until you have decided the replies are right.
• "Answer this in the same tone as the last three replies we sent this person." get_customer carries full ticket and feedback history, so the agent reads how you actually talk to someone instead of inventing a house voice.

The counter-example is reply to anything easy. Easy is a property of your afternoon, not of the ticket — and an agent asked to judge easiness picks what it can answer confidently, precisely the population where confidence and correctness come apart.

The follow-up

The last pass covers what everything else left behind — the review queue from Helmdesk's own scheduled automations, and the articles you should have written.

• "What did the automations file overnight?" list_agent_activity lists everything pending a human: drafted replies, drafted articles, auto-closed tickets, log alerts.
• "Show me each drafted reply next to the ticket it answers and the article it cites. I'll tell you which to approve." Compare approve the good ones — not a reviewable criterion, and not a review at all: approve_agent_item on a drafted reply is what posts and emails it. Approval is the send button. If you would not let the agent write replies unsupervised, you cannot let it grade its own.
• "Revert any auto-close where the customer wrote the last message." Auto-Close acts rather than proposes, which is why revert_agent_item exists. That criterion is checkable by machine, which makes this safe as a standing sweep.
• "Turn the resolution on ticket 41 into a draft article, but check we don't already have one." search_articles first, then create_article, which defaults to draft. Every question you answer twice is an article you should have written, and the agent just read the thread that proves it.

Where this stops working: any decision whose criterion you cannot write down. Refund or no refund, exception or no exception — those are not prompts missing detail, they are judgements you have not made yet. Ask for the evidence and make the call. An agent that triages two hundred tickets is a good afternoon; an agent improvising your refund policy is a liability with excellent grammar.

Four rules that generalise

• Name the outcome, not the activity. "Answer the tickets" describes what you would be doing. "Draft one reply per open ticket about the export bug" describes what should be true afterwards.
• Give a criterion a stranger could apply. If you cannot write the rule in a sentence, you are not delegating a decision — you are hoping for one.
• Make the send its own turn. Draft, look, then send. Two prompts, and the second takes four words.
• Know which verbs reach a person. On the ticket side there are four: replying, resolving, bulk-resolving, and approving a drafted reply. Everything else is a tag, a note or a query, and can be handed over freely.

Get those right and the queue becomes something you review rather than something you type. Get the third one wrong and you find out the way everyone finds out — from a customer, quoting you back to yourself.

Work the queue from your editor

An MCP server with 73 tools for tickets, customers, email, articles and logs — with the ten that reach a customer marked as such.

Start freeRead the docs