Zendesk and ChatGPT

A Zendesk ChatGPT setup is genuinely useful for three jobs and quietly dangerous for a fourth. Knowing which is which is most of the work.

Four ways to wire up Zendesk and ChatGPT

They differ mostly in who sees the output and how much control you keep.

A marketplace app. Adds a panel to the ticket sidebar, calls the model with your own API key, shows a suggested reply. Fastest to try, least control over the prompt.
Your own app on the apps framework. Same shape, but you write the prompt and the key lives in secure settings with the call made through the framework proxy, so it never reaches the browser. This is the version you'll end up with if the first one is nearly right.
Middleware. A webhook fires on ticket created, your service calls the model, and the result comes back as an internal note or a custom field value. Nothing for the agent to click, nothing for them to learn.
Zendesk's own generative features. Already model-backed, no key to manage, no prompt to tune. Less flexible, and somebody else is responsible when it breaks.

Rule of thumb: prose a human will read and edit belongs in the sidebar, field values belong in middleware where nobody sees them. Sidebar panels producing data an agent then copies somewhere else are the worst of both.

The jobs it does well

Drafting from context you supply. Give a model the ticket plus the right help centre article and it writes a serviceable first draft. Give it the ticket alone and it writes a confident guess. The retrieval half is the whole trick.
Summarising long threads. Forty comments, three agents, one reassignment, a customer who has repeated themselves twice. A five-line summary at the top of an escalation saves real minutes.
Classifying and routing. Intent, product area, language, urgency. Cheap, measurable, and no customer ever sees the output. Pound for pound this is the highest return on the list.
Extracting structured data. Order number, error code, app version, affected account. Written into custom fields where triggers and Explore can actually use them.
Translation. Not as good as a human. Considerably better than nothing at two in the morning.

Notice the pattern. Everything there either feeds a person or feeds a field. Nothing on that list sends an email to a customer on its own.

Where it goes wrong

It invents policy. The model does not know your refund window, so it produces one that sounds plausible. The customer quotes it back three weeks later and they are, in a sense, right to.

It has no account data. It reads the ticket. It can't read your billing system. Any sentence about this specific customer that you did not put into the prompt is fabrication, however fluent.

Agents stop reading. Draft quality is the trap: good enough that people skim, wrong often enough that skimming costs you. The failure is invisible until a customer screenshots something.

Tone. Trained-in cheerfulness lands badly on a ticket from somebody whose payment failed twice. Models are relentlessly upbeat unless you tell them not to be.

Data leaves the building. Ticket text contains whatever customers pasted in, which over a year includes card fragments, passwords, screenshots of other people and occasionally medical detail. Read the processing terms, confirm your content is not used for training, and redact before you send.

Cost scales with thread length. A summariser that re-reads the whole conversation on every update gets pricier with each reply, on exactly the tickets that were already expensive. Cap the input.

Nobody measures it. Without a hand-labelled sample you have no idea whether your classifier is right 92% of the time or 61%, and those lead to entirely different routing decisions.

Guardrails that hold

Five, in rough order of importance.

A human sends anything consequential

Money, policy, promises, apologies with commitments in them. Suggest-only isn't a timid starting position, it's the correct permanent setting for most of your queue.

Ground it, then check the grounding

Retrieve from your own help centre and instruct the model to say it doesn't know when the answer isn't there. Then measure how often it says so. A model that never admits ignorance isn't grounded, it's guessing with citations.

Log what it was told

Store the prompt and the output somewhere retrievable, even if that's just an internal note. When a reply goes wrong you need to see what the model was working from, not reconstruct it.

Score two hundred tickets by hand

Boring, unavoidable, takes an afternoon. It's the only number in this project that means anything.

Start with classification

Nobody gets fired for a mis-tagged ticket. Build confidence on the invisible work first.

Your own model, or the built-in one

Bringing your own gives you prompt control, model choice, and the ability to feed in data from systems Zendesk knows nothing about. It also gives you an API bill, a rate limit to respect, a key to rotate and an owner who has to care when the vendor deprecates a model version.

The built-in features are less flexible and you can't see the prompt. In exchange they're maintained, they sit inside your existing data agreement, and they work on day one. For a team of six that has never run an integration, that trade is usually worth taking. See Zendesk AI agents for what the built-in side covers.

The middle path few people take: built-in features for anything customer-facing, your own middleware for classification. Different risk, different tools.

FAQ

Frequently asked questions

Can you use OpenAI models directly rather than the built-in AI?

Yes. A Zendesk OpenAI connection through the API is the usual Zendesk LLM integration when you want your own prompts and your own model. ChatGPT for customer support works best on drafting and summarising rather than on unsupervised replies.

Is there an official ChatGPT integration for Zendesk?

There are marketplace apps that call OpenAI with your own key, and Zendesk has its own model-backed features that need no key at all. There is no single blessed connector, so pick based on whether you want prompt control.

Can ChatGPT reply to customers automatically in Zendesk?

Technically yes. For anything involving money, policy or a promise, do not. Run it as suggestions for a quarter and count how often agents edit before you consider anything else.

Will our ticket content be used to train the model?

It depends on the plan and the terms you agreed to. Check rather than assume, and redact obvious sensitive data before it leaves your systems either way.

What is the cheapest useful thing to build first?

Classification into a ticket field through middleware. No customer sees it, the accuracy is measurable, and it improves routing immediately.

How do we know if it's working?

Label a sample by hand and compare. Agreement rate on classification, edit rate on drafts. Anything else is a feeling.

Duplicate detection without the token bill

Spotting a repeat ticket is a classification problem with a real cost attached. Ticket Merger solves that one on requester, timing and the keywords you list, with no prompt to tune.

Start free trial

14-day free trial. No credit card required.