Zendesk Go-Live Checklist template.

What's inside — the exact file

This is the complete template, not a sample. The rows are worked examples — replace them with your data (and delete them before any platform import).

What this template is for

Cutover day is where Zendesk implementations succeed quietly or fail publicly. This is the 22-point go-live checklist we actually run with clients — channels, people, workflows, data, safety nets, and comms — pre-filled with the specific checks, not blank rows with a 'checklist' header.

Use it in the final two weeks before launch. Every item gets an owner and a verified_by — the second signature matters, because 'I set it up' and 'someone else confirmed it works' are different levels of certainty, and cutover is the wrong day to discover the difference.

How to use it, step by step

1. Assign every row an owner two weeks out. Unowned checklist items don't happen. Distribute the 22 items across the implementation team and internal stakeholders by name, not by team.
2. Verify channels end-to-end, not in theory. Send a real email to every support address, start a real chat, place a real call. 'The forwarding rule is configured' and 'a test email became a ticket' are different facts.
3. Run the safety-net items last. Backup exports, rollback plan, on-call rotation for launch week, and the old system's read-only sunset date — the items everyone skips because they're only needed when something goes wrong.
4. Hold a go/no-go with the sheet on screen. Every row green or consciously waived by the project owner, in writing. Yellow rows with 'probably fine' are how launch days become launch weeks.
5. Keep the sheet as the launch-week triage list. The first week's issues almost always trace to a row on this sheet — having verified_by names attached shortens every diagnosis.

What each column means

Common mistakes to avoid

• Owner and verifier being the same person — self-certified checklists find nothing.
• Testing channels from inside your own network and missing the SPF/DKIM problem every external customer will hit.
• Leaving the old help desk writable after cutover, so two weeks of tickets land in two systems and someone merges them by hand.
• Skipping the internal comms row — agents finding out about new workflows on launch morning is a self-inflicted wound.
• No rollback criteria: decide before launch what failure looks like and who can call it.

Questions, answered

When should the checklist run?

Start it two weeks before cutover and finish the safety-net items in the final 48 hours. Items verified a month early (channels, DNS) have a habit of un-verifying themselves when someone touches email routing.

What's the single most-missed item?

Email deliverability — SPF/DKIM records for outbound Zendesk mail. Everything works in testing because testers are internal; then real customers' replies land in spam and the queue goes mysteriously quiet.

Do we need this if a partner runs our implementation?

A good partner brings their own version of it — ask to see it. This sheet is also how you hold any implementer, including us, accountable: every row is a question you're entitled to ask before launch day.

This is a Market Disrupt worksheet, not a vendor file. Import-format templates follow each platform's documented layout as of July 2026 — platforms evolve, so validate against current documentation before a large import.