How to Customize Zendesk Chat

Most teams customize Zendesk chat with decoration. Two settings genuinely change your ticket quality, and neither of them is a colour.

Three places the settings live

People get lost because customisation is spread across three surfaces, and the answer to "where do I change that" depends on which one owns it.

Admin Center. Colours, launcher label, brand name and avatar, the pre-chat form, offline behaviour, operating hours, language. No deployment needed and no code.
The widget JavaScript API. Showing and hiding the launcher, opening it from your own button, prefilling fields, setting locale, offsetting position, clearing the session on logout. That last one matters on shared computers and it's forgotten constantly. More in the widget API guide.
Triggers and routing rules. What happens to the conversation once it exists, which is customisation of a different kind and the kind that matters most.

Exact setting names move between releases. Navigate by what you're trying to change rather than by a remembered menu path.

Customize Zendesk chat appearance, and its ceiling

You get a colour, a position, a label, an avatar and a brand name. That's genuinely most of what anyone needs, and it takes about four minutes.

What you can't do is redesign it. The widget renders in an iframe with a supported set of options, and no CSS on your page reaches inside it. If a designer hands you a bespoke chat interface, you're no longer customising a widget, you're building a client against the messaging APIs. Different project, different budget, different person.

One small thing worth doing anyway: offset the launcher so it doesn't sit on top of your cookie banner or your back-to-top button. Check it on a thirteen inch laptop rather than on your monitor.

The pre-chat form, which is the real lever

This is the highest leverage setting on the page and it's usually left at whatever shipped.

Every field on a pre-chat form is a small tax on starting the conversation, paid by somebody who is already slightly annoyed. So ask of each one: will an agent behave differently based on the answer? If not, cut it.

Name and email, if the visitor isn't signed in, since you need a way to reply if they leave. One routing question, written in customer language, six options at most. That's a good form and it takes ten minutes to build.

A pre-chat form asking five questions gets answered carelessly, and wrong values are worse than absent ones.

If the visitor is signed in, skip the identity fields entirely and prefill from your own site through the widget API. Asking a logged-in customer for their email address is the fastest way to look like you don't know who they are.

Offline and away behaviour

Decide three states deliberately rather than accepting whatever ships.

Online. Chat available, expected reply measured in a minute or two.

Away. Agents signed in but at capacity. Say so, give a queue position if you can, and let people leave a message instead of waiting blindly at a screen.

Offline. Outside hours. The widget should collect a message and state plainly when someone will reply. "We will get back to you as soon as possible" at 2am is not a commitment, it is a shrug.

The offline state is where most of the goodwill is won or lost, and it's the state nobody tests, because nobody is looking at their own site at midnight.

Departments and routing

Getting the conversation to the right group is customisation with a measurable return, unlike the colour.

The usual pattern: the routing answer on the pre-chat form sets a field, a trigger reads that field and assigns the group, and the conversation lands somewhere staffed. Page context works too. A chat opened from a pricing page is a different conversation from one opened in the help centre, and you can route on that without asking anybody anything.

Two rules that hold up. Never make "Other" the first option, because a meaningful share of people pick it without reading further. And write the options as things customers say, not as your internal team names, since nobody outside your building knows what Tier 2 Platform means.

Language, and knowing when to stop

The widget supports a set of locales and will follow the browser unless you override it through the API. If you run a multilingual help centre, set the locale explicitly from your own page rather than hoping the browser gets it right.

Then stop. Once the pre-chat form is short, the routing works and the offline message is honest, further customisation is rearranging furniture. Spend the time reading transcripts instead. You'll learn more in an hour of those than in a week of settings.

FAQ

Frequently asked questions

What can you change on the pre-chat form and departments?

The Zendesk pre-chat form takes name, email and a dropdown, and every field costs you conversions. Zendesk chat departments route the conversation to a team, and both sit in the same Zendesk chat customization screen whichever way you spell customise Zendesk chat.

How far can you customize Zendesk chat with CSS?

No. It renders in an iframe with a supported set of appearance options. Anything beyond that means building your own client against the messaging APIs.

How many fields should a pre-chat form have?

Two or three. Identity if the visitor is not signed in, plus one routing question with a short option list.

Can I route chats to different departments?

Yes, usually by setting a field from the pre-chat answer or the page context and letting a trigger assign the group.

What should the widget do outside business hours?

Collect a message and state when someone will reply. Leaving a live chat launcher up with nobody behind it is the worst option available.

Short forms, cleaner matching

Consistent requester details and a real subject line make duplicates far easier to identify. Ticket Merger uses exactly those fields.

Start free trial

14-day free trial. No credit card required.