Zendesk Team Publishing
Zendesk team publishing adds drafts, review and approval to help centre articles. It solves a real problem, and it slows everything down. Both are the point.
The problem Zendesk team publishing solves
Without team publishing, editing a published article edits the published article. There is no parallel draft. Save a half-finished sentence and your customers can read it.
Teams work around this in ways that are all bad. They write in Google Docs and paste in at the end, which loses formatting and version history. They unpublish an article while they rework it, which means the answer is missing for a day. Or they just edit live and hope nobody refreshes.
Team publishing gives you a work-in-progress version alongside the live one. That single capability is most of what people are buying.
What it adds
Team publishing is an Enterprise-level Guide capability rather than something on every plan. Check the current Zendesk plan comparison before you build a process on it.
The workflow in practice
Strip out the interface detail and the loop is short.
Someone creates or opens an article and works on the draft. When it is ready they submit it for review and assign a reviewer. The reviewer reads it, leaves comments, and either approves or returns it. An approver publishes. The live article changes at that moment and not before.
The bit teams get wrong is the review step. A reviewer who is a bottleneck turns a two-day update into a three-week one, and writers respond by batching changes, which makes reviews bigger and slower still. Pick reviewers by availability, not by seniority.
One habit worth stealing from engineering: review small. A five-paragraph correction reviewed on Tuesday beats a full rewrite reviewed next month.
Who can do what
Roughly three levels, though the exact names and the granularity depend on your plan, so verify against the current docs.
Guide admins
Everything. Structure, themes, permissions, publishing, deleting. Keep this group small. Two or three people is usually right.
Agents with publishing rights
Can write, edit and publish within whatever scope you grant. This is your knowledge team.
Agents who can draft only
Can write and submit, cannot publish. This is where most support agents belong, and it's the setting that makes crowd-sourced knowledge safe.
That last group matters more than it sounds. The agent who just solved a novel problem is the best person to document it and the worst person to have unreviewed publishing access, because they are writing at speed at the end of a hard ticket.
Verification, the underused half
Approvals get the attention. Verification is the part that quietly matters more.
Every knowledge base accumulates articles that were accurate when written and have drifted since. Nothing in them looks wrong. The screenshots are from an older interface, the pricing changed, the third step now happens somewhere else. A customer follows it, it doesn't work, and they raise a ticket that your help centre technically already answered.
Marking articles as verified, with a date and a person, turns that invisible decay into something you can see and schedule. Build a view of articles that have not been verified in twelve months, hand ten a month to whoever owns that category, and the problem stops compounding.
It is unglamorous work and it beats writing new articles on top of stale ones. An out-of-date answer is worse than no answer, because the customer wastes twenty minutes before they write in, and by then they are annoyed.
When it is overkill
If two people maintain your help centre and they sit next to each other, approvals add ceremony and remove nothing. Talk to each other instead.
Team publishing earns its keep when at least one of these is true: more than a handful of people can edit, the content carries compliance or legal weight, you publish in several languages and a change fans out, or you have been burned by a bad edit going live.
If none of that is you, use the simpler discipline instead. Agree who owns which category, review quarterly, and keep a note of what changed. The process is the valuable part. The software just enforces it.
Frequently asked questions
How does article approval work in Guide?
Zendesk Guide team publishing adds Zendesk article drafts, review and Zendesk article approval before anything goes live. That approval step is the whole Zendesk knowledge base workflow for teams where accuracy matters more than speed.
Which plan includes Zendesk team publishing?
It's an Enterprise-level Guide feature rather than a universal one. Check the current Zendesk plan comparison for your account, because the tier names have changed since the feature launched.
Can I edit a published article without customers seeing it?
With team publishing, yes. That is its main job. Without it you're editing the live article, so people work around it by unpublishing or drafting outside Zendesk.
Can support agents write articles without publishing them?
Yes, that is the standard setup: agents draft and submit, a smaller group reviews and publishes. It is the safest way to capture knowledge from the people closest to the tickets.
Does team publishing keep version history?
Guide keeps article revisions, and team publishing adds the draft-alongside-published behaviour on top. Check the current docs for how far back revisions go on your plan.
Review articles, not the same ticket twice
A publishing workflow keeps your answers consistent. Ticket Merger keeps two agents from writing two of them for one customer.
Start free trial14-day free trial. No credit card required.