Start with a case, not a feature count
Zendesk’s agent-access documentation describes groups, ticket visibility and role-dependent permissions. The exact controls depend on configuration and plan. Use that official reference as an example of the questions a buyer should investigate, rather than assuming every helpdesk exposes identical controls. AMZ12’s assessment framework is research-based and includes no claimed hands-on comparison.
Choose an enquiry that crosses responsibilities: an order is partly shipped, the customer wants an address correction and one item may need replacing. Write a fictional case with enough detail to exercise the process without exposing real customer information.
Define the customer-facing outcome
Write what the customer should receive: acknowledgement, an explanation of what can still change and a realistic next update. Identify which facts an agent must verify before making a promise. Avoid building the exercise around a perfectly simple request that any shared inbox can answer.
Have one person act as the customer and another as the first responder. Review whether the workspace makes the latest message and prior commitments easy to find. A support tool should help a colleague understand the conversation without reconstructing it from disconnected browser tabs.
Exercise the internal handoff
Move the case to the person responsible for fulfillment. The handoff should state the request, verified facts, decision required and deadline. Ask the recipient to explain what they believe they own. If their explanation differs from the sender’s, refine the workflow before blaming the interface.
Inspect how internal commentary is distinguished from the reply sent to the customer. Include an intentional draft correction in the rehearsal. The evaluator should be able to describe the safeguards and staff training needed to prevent internal instructions from becoming an accidental public message.
Check access against real roles
Create a role map for permanent agents, temporary staff, store managers and external fulfillment partners. For each role, specify what information and actions are necessary. Then ask how the proposed setup would grant that access and how it would be removed.
Test a restricted participant’s experience using an authorized evaluation account. Confirm that limited access still permits the intended handoff. Also investigate the consequence of adding someone to a conversation through a notification or collaboration feature. Evaluate the actual route information takes, not only the label on a permission setting.
Follow the case through closure
Reopen the fictional case after a promised update is missed. Check who notices, how the next action is assigned and whether another agent can explain the history. A closed status is useful only when the operating team agrees what completion means.
Ask the reporting owner to show how this case would be categorized and reviewed. Separate response speed from successful resolution. A quick acknowledgement can coexist with an unresolved replacement, so the chosen reports should support the questions the business actually needs to answer.
Choose a maintainable workflow
List the configuration, integrations and training needed to reproduce the exercise for normal work. Identify who will maintain categories, permissions and response templates when the team changes. Obtain current commercial terms for the roles and usage pattern you expect.
Keep the final decision record short: essential requirements met, unresolved limitations accepted and the owner of each follow-up. A well-chosen helpdesk gives the store a repeatable way to deliver an accurate answer, especially when the first agent cannot resolve the case alone.
Official reference: Zendesk Help: agent privileges and ticket access. Source checked on 29 October 2026. AMZ12 analysis and suggested checks are independent editorial guidance.