DEMETER ICT · Zendesk Launch Guide · EP1
Zendesk Setup Checklist: What to Prepare Before Going Live
A practical guide to the decisions behind your Zendesk setup, from brands and support channels to ticket ownership, knowledge and launch testing.
You have purchased Zendesk, added your agents and connected an email address. Are you ready to launch?
You may be ready to receive requests. But before the team starts relying on the system, you also need to know who owns each case, what happens outside business hours, how work moves between teams and how supervisors spot requests that need attention.
This Zendesk setup checklist explains what to prepare and why it matters. It focuses on planning decisions rather than screen-by-screen configuration instructions. If you are still evaluating the platform, start with our Zendesk overview.
What needs to be configured before launching Zendesk?
Before launching Zendesk, define your service scope, brand structure, team roles, support channels, ticket information, routing rules, service targets, knowledge resources, automation and reporting. Then test complete customer journeys and prepare the people who will operate the system. Your setup should reflect how requests are received, assigned, resolved and followed up.
You do not need every feature on day one. Start with a service process your team can operate reliably, then expand as your needs become clearer.
Scope note: This guide focuses on customer service with Zendesk Suite. Feature availability, limits, AI capabilities and integrations depend on your subscription, add-ons and selected channels. Review Zendesk plans and pricing against your requirements before confirming the launch scope.
Zendesk setup at a glance
Use this table to bring the right people into the planning process. These are suggested participants; the accountable owner will depend on your organisation.
| Setup area | Key decision | Who to involve |
|---|---|---|
| Service scope | Which customers and requests will the team support? | Service owner, business leaders |
| Brands | Which customer-facing identities need separate experiences? | Business owner, marketing, CX |
| Teams and permissions | Who does the work, and who can access or change what? | Team leads, administrator, IT/security |
| Channels | Where can customers contact you, and who responds? | Customer service, channel owners, IT |
| Ticket information | What information is needed to act and report? | Agents, operations, reporting owner |
| Routing and ownership | Who owns the case, including during handoffs? | Leads from all receiving teams |
| Service targets | What response and follow-up commitments are realistic? | Service owner, workforce/team leads |
| Knowledge | What answers can people rely on, and who maintains them? | Product, operations, knowledge owner |
| Automation and AI | What can run automatically, and when must a person intervene? | Process owners, administrator, IT/security |
| Reporting and testing | How will you confirm the process works? | Supervisors, reporting owner, launch team |
1. Define your service scope before configuring the system
Start with the work Zendesk will support. Pre-sales questions, order issues, technical support and internal employee requests may require different information, ownership and approval processes.
Agree on who you serve, which request types are included, which countries and languages you support, and which teams participate. Identify the operational problem you want to improve: missed requests, slow handoffs, repeated questions or limited visibility into outstanding work.
For example, a retailer might begin with post-purchase support for one brand and two markets. That gives the team a clearer launch scope than trying to move every customer interaction into Zendesk immediately.
Prepare: A service scope statement, a list of request types and named process owners.
2. Plan brands around the customer experience
Your brand structure should reflect the identity customers expect when they contact you. Decide whether different brands need distinct support contact points, presentation or knowledge experiences.
Operating in several countries does not automatically mean you need a separate brand for each country. Likewise, internal departments do not necessarily need their own brands. Consider the customer-facing differences first, then assess how to organise the work behind them.
- Which brand name should appear in customer communications?
- Which contact points should be shared or separate?
- Do customers need different policies or help content?
- How should performance be reported across brands?
Prepare: A brand map and the customer-facing assets needed for the launch scope. Confirm multibrand entitlements before committing to the structure.
3. Define teams, roles and access permissions
Adding agents is only the beginning. Define who receives requests, who investigates them, who approves exceptions and who administers the platform.
Document which work belongs to each team and which information each role needs to access. Include colleagues outside customer service who may participate in a case, such as finance, warehouse or technical teams. Decide how they will collaborate and confirm any licensing requirements.
Assign an ongoing system owner, too. After launch, someone must review changes to business rules, permissions and connected channels.
Prepare: A responsibility and access matrix, team membership and a named Zendesk administrator.
4. Connect the channels you are ready to operate
Choose launch channels based on customer needs and your ability to respond. These might include support email, request forms, website messaging, voice or selected social messaging channels.
For each channel, agree on its owner, operating hours, response expectations and out-of-hours experience. Confirm account ownership and the access needed to maintain the connection.
Connecting a channel does not establish the service process behind it. If you add messaging to your website, decide what happens when no agent is available and what information the customer should provide before the conversation is handed over.
Prepare: A channel inventory with ownership, service hours, customer messages and an end-to-end test for each launch channel.
5. Decide what information each ticket needs
A message saying “My order has a problem” may not contain enough information for the next team to act. Define what agents need to understand, route and resolve the request.
Depending on the use case, useful information may include issue category, product, order reference, country, preferred language and business impact. Agree on consistent definitions so the data remains useful for reporting.
Separate information needed at intake from information collected during investigation. Requiring too many fields too early can slow down customers and agents. Also define which sensitive information should not be requested or stored in the ticket.
Prepare: A ticket data dictionary, required information by request type and clear rules for data collection.
6. Establish routing rules and case ownership
Routing determines where work goes. Ownership determines who remains accountable for moving it forward. Both need to be clear.
Decide how requests reach the right group or agent, what happens when a request cannot be categorised and who monitors work that remains unassigned. Zendesk routing options include business rules and, where available and appropriate, omnichannel routing. Choose the approach after agreeing on the operating rules.
A handoff should include enough context for the receiving team to act. It should also be clear who updates the customer while another team investigates.
Prepare: A routing map, handoff requirements, an exception queue and a named owner for customer follow-up.
7. Set business hours, service targets and escalation rules
“Reply quickly” is difficult to manage consistently. Define service hours, time zones, holidays, priority criteria and measurable response expectations.
If you use SLA policies, confirm the supported metrics and whether targets use business hours or calendar hours. First response, subsequent updates and resolution are different commitments; choose measures that fit the service you can deliver.
Agree on who receives warnings when work approaches a target, how overdue cases are escalated and how requests waiting on another team are followed up. Automated acknowledgements should not create the impression that an agent has already investigated the issue.
Prepare: A service target matrix, business schedules and escalation responsibilities.
8. Prepare your Help Center and internal knowledge
Start with the questions customers and agents need answered most often. Common examples include order tracking, account access, troubleshooting and return policies.
Decide what belongs in public self-service content and what must remain internal, such as investigation procedures or approval guidance. Assign content owners and define how information is reviewed when products or policies change.
A complete Help Center does not have to delay every launch. You can start with a focused set of accurate articles where that fits your service model. If AI will use knowledge to answer questions, check that the selected sources support the intended questions and that the content is suitable for the audience.
Prepare: A prioritised knowledge list, publication/access rules and an owner for each important topic.
9. Give automation and AI a defined job
Choose specific work to automate: acknowledging receipt, categorising requests, routing work or reminding the team about outstanding cases. For AI, identify the supported tasks, knowledge sources and situations that require human involvement.
Define what starts each process, what information it needs, what a correct outcome looks like and how failures are handled. Check that rules do not conflict or repeatedly trigger one another.
For example, explaining a refund policy and approving a refund are different responsibilities. Do not assume that the ability to generate an answer also grants permission to carry out a financial action.
Prepare: An automation and AI use-case list with boundaries, approvals, fallback paths and acceptance tests. Confirm product and usage entitlements separately.
10. Prepare reporting, launch tests and team training
Decide what supervisors need to see to run the service. Useful starting questions include: Which requests have no owner? Which cases have waited too long? Where do handoffs stall? Which issues repeat?
Then test complete journeys using demonstration data. Submit a request through every launch channel, check its routing and required information, respond, add internal context, change its status and confirm the customer-facing result.
- What happens outside business hours?
- What happens when the request lacks essential information?
- Can another team take over without asking the customer to repeat everything?
- Who acts if the intended owner is unavailable?
- What happens when the customer replies after a case is marked solved?
- How does the team recover when automation or AI cannot continue?
Train agents on these scenarios, not only on where to click. Assign a launch support owner and a review date to assess what needs adjusting after the team starts using the system.
Prepare: A reporting specification, completed acceptance tests, operating guidance and a post-launch review plan.
Illustrative example · Not a customer case study
How the setup decisions connect: a missing-item request
Imagine a retail brand whose customer reports that an item is missing from an order. Customer service needs help from the warehouse before confirming the next action.
- Capture context: The agent records the order reference, affected item and issue category.
- Establish ownership: Customer service owns the customer follow-up while the warehouse investigates.
- Request internal action: The warehouse receives the information required to check fulfilment, through the agreed collaboration process.
- Monitor progress: The team tracks the next update due and follows up if the investigation stalls.
- Confirm the outcome: Any replacement or refund follows the agreed approval and system process before the customer is informed.
This scenario connects ticket information, access, routing, service targets and knowledge. Automatically reading order data or executing refunds may require a separate integration; do not assume these actions are available simply because the ticket exists in Zendesk.
Do you need every Zendesk feature before going live?
No. Separate what is essential for a reliable launch from what can be introduced after the team has a stable operating process.
| Establish before launch | Consider in a later phase |
|---|---|
| Clear service scope and case ownership | Additional brands or markets when required |
| Working channels with named owners | More channels once staffing and workflows are ready |
| Essential ticket information and routing | More sophisticated routing and integrations |
| Accurate operating guidance and key answers | A broader multilingual Help Center |
| Basic operational visibility and tested workflows | Expanded analytics, automation and AI use cases |
The sequence depends on your business. A capability listed as a later phase may be essential from day one for your particular launch.
Match the scope to your people, processes and Zendesk subscription requirements, rather than selecting a plan based on agent count alone.
Your Zendesk go-live readiness checklist
Review these items with the people responsible for delivering the service.
- Our launch scope and supported customer groups are agreed.
- Our brand structure matches the customer experience.
- Team roles, access permissions and administration ownership are reviewed.
- Every launch channel has an owner and a tested service process.
- Tickets capture the information needed to take action.
- Routing, handoffs and customer follow-up have clear ownership.
- Business hours, service targets and escalation rules are agreed.
- Essential knowledge is accurate and has content owners.
- Automation and AI have tested boundaries and fallback paths.
- Supervisors can identify unassigned and ageing work.
- Agents have practised realistic service scenarios.
- A launch support owner and post-launch review date are assigned.
If an item is not ready, assess the customer impact. Decide whether to resolve it before launch or reduce the initial scope.
Frequently asked questions about Zendesk setup
Can we start using Zendesk with email only?
Yes, an email-first rollout can be a practical starting point if it meets your customer needs. You still need ownership, routing, essential ticket information, response expectations and testing. Add channels when the team is ready to operate them.
Do we need a Help Center before launching Zendesk?
Not every launch requires a fully developed public Help Center. Decide how important self-service is to your service model. Prepare reliable guidance for agents, and ensure any AI use case has appropriate knowledge sources before enabling it.
Does every country or business unit need a separate brand?
No. Base the decision on customer-facing identity, contact points and knowledge requirements. Country, language or internal department alone is not a sufficient reason to add another brand.
Should we configure AI before going live?
Only if the use case, knowledge, boundaries and human handoff are ready. You can launch a reliable human-operated process first and add AI later. If AI is part of the initial service, include it in your acceptance tests.
How long does Zendesk setup take?
The timeline depends on the number of channels, teams, brands, integrations, data migration needs and approval requirements. Define scope and acceptance criteria before committing to a go-live date.
When should we involve a Zendesk implementation partner?
Consider involving a partner when you need help translating business processes into a working setup, coordinating multiple teams, connecting systems or preparing a controlled rollout. If you already use Zendesk, a CX optimization discussion with DEMETER ICT can help you identify which areas to review.
Plan the service process behind your Zendesk setup
A useful launch starts with a manageable scope: customers can reach you, agents have the context they need, cases have owners and supervisors can see what requires attention.
DEMETER ICT can discuss your Zendesk requirements in the context of your customer service operations. Whether you are preparing a new rollout or reviewing an existing setup, bring your channels, team structure and a few examples of requests that are difficult to manage today.
Explore our Zendesk solutions overview, review plans and pricing, or learn about our Customer Experience Optimization services.
