Someone on the client side watched a LinkedIn clip where a chatbot "resolved" a password reset in twelve seconds, and now they want that energy on every ticket. Not some tickets. Every ticket. Password resets, printer ghosts, VPN failures, "can you make Excel stop yelling at me," the whole queue. ChatGPT, everywhere, yesterday.
If you run an MSP or an internal helpdesk, you have heard some version of this already. If you have not, you will. The ask arrives with a smile and a budget slide, and it sounds reasonable until you map it onto the work you actually do.
What they think they bought
Clients do not ask for ChatGPT because they hate your techs. They ask because they saw a demo that looked like magic and they want the same magic without the queue. In their head, every ticket is a clean question with a clean answer. User pastes a problem, model pastes a fix, ticket closes, invoice stays the same.
That fantasy skips the parts of support that make the job real. Half the tickets are incomplete. A third of them are the wrong problem described with confident wrong words. A chunk of them are policy questions dressed up as technical ones. And a surprising number are "my computer is slow" with zero detail and a manager breathing down their neck.
ChatGPT is good at sounding sure. Support work is often about being sure of the right thing after you have checked three places the user did not mention. Those are different skills.
Where the idea dies in the queue
Put ChatGPT on every ticket and you get three failure modes that show up fast.
First, the confident wrong answer. The model invents a registry path, a Group Policy name, or a vendor setting that looks plausible and is not real. A junior tech trusts it, burns twenty minutes, and then has to clean up a mess that did not exist before the "AI assist." The client sees a longer ticket and wonders why the smart tool made things worse.
Second, the policy blind spot. Models do not know that this client forbids USB drives, that VIP mailboxes get a different MFA flow, or that finance machines stay on a locked image. They answer from general internet knowledge. Your ticket system answers from contracts, runbooks, and the last ugly change request. Mixing those without a guardrail is how you get a friendly bot telling a user to disable the security control you spent a quarter deploying.
Third, the escalation trap. Easy tickets get slightly faster. Hard tickets get a wall of generated text that looks like progress and is not. The user feels helped. The queue does not shrink. Your senior people still own the weird stuff, and now they also own reviewing whatever the bot said before anyone ships it into production.
None of that means the tools are useless. It means "ChatGPT in every ticket" is a slogan, not a design.
A better shape for the same request
When a client asks for this, translate the ask before you sell anything. What they usually want is shorter wait times, fewer repeat tickets, and less "we are waiting on IT" energy in their office. ChatGPT is the brand name they know for that feeling. Your job is to sell the outcome without promising a chatbot in the path of every human problem.
Start with ticket classes that are already boring and already documented. Password resets with a clear identity source. Known VPN client resets. Standard software install requests from an approved list. FAQ style questions that already live in a knowledge base you trust. Those are candidates for assisted answers, not freeform conversation with a public model.
Keep a human in the loop on anything that changes security posture, touches finance or HR systems, or requires guessing about intent. If the ticket needs a judgment call, the model can draft. It should not decide.
And be blunt about data. If the client wants a public ChatGPT session pasted into ticket notes, say no. Paste an error message into a consumer chat and you have just exported client internals to a vendor you do not control. If you want model help, use a controlled setup with redaction, approved prompts, and a knowledge base you own. That sentence alone has saved more relationships than any demo reel.
How to talk them off the ledge without sounding lazy
Clients hear "no" as "we do not want to innovate." So do not lead with no. Lead with a scoped yes.
Tell them you will pilot assisted replies on two or three ticket types for thirty days. Measure reopen rate, time to first response, and how often a tech had to scrap the draft. Share the numbers. If the draft helps, expand the list. If the draft creates cleanup work, stop expanding and fix the knowledge base instead.
Offer a triage layer that classifies tickets and routes the easy ones to a scripted path before a human touches them. That is often what they meant by ChatGPT anyway. They want the queue sorted and the obvious stuff handled. They do not actually want a language model debating toner with the office manager at 4:55 on a Friday.
Price the work as an operating change, not as a novelty add-on. Knowledge base cleanup, prompt and policy design, integration with the PSA, and training for techs who will review drafts. If you only charge for "AI" and skip the boring foundation, you will eat the support cost when the bot starts inventing printer drivers.
What good looks like after the hype cools
A sane setup looks quieter than the pitch deck. Techs open a ticket and see a suggested reply grounded in the client's own docs. They edit it, send it, and move on. Password and access flows that used to take four messages now take one because the first answer was already close. Weird tickets still go to people who can think.
Users stop asking "why don't we have ChatGPT" because wait times dropped and repeat questions stopped bouncing around Slack. Leadership stops asking for a bot in every ticket because they can see which ticket types improved and which ones still need humans.
That is the win. Not a chatbot cosplaying as your helpdesk. A helpdesk that uses machine help where the help is cheap, checkable, and boring in the best way.
If you are the one getting the request tomorrow
Write down the last fifty tickets. Circle the ones with a known fix and a short path. Those are your pilot list. Everything else stays human until you have evidence, not vibes.
Ask the client which risk they will accept: a wrong answer that sounds right, or a slower answer that is correct. Most of them pick correct once you phrase it that way. The ones who pick speed at all costs are telling you something useful about the account. Price for the cleanup.
And when they say "just put ChatGPT on it," answer with a calendar invite for a thirty day pilot on three ticket types, not a promise to wire a public chatbot into the entire queue. You can be friendly about it. You still should not be reckless.
Support work survives on trust. Models are tools. Tools do not get to sit unsupervised in every ticket just because a vendor clip made it look easy.