A help desk selection checklist should test whether requests remain captured, owned, prioritised, resolved and measurable across ordinary and difficult cases. It should not award points for features that never participate in the service design.
Define the ticket lifecycle and operating responsibilities first. Then turn each material requirement into a repeatable scenario with evidence and a mandatory pass condition where failure is unacceptable.
Set the service boundary
List users, customers, request types, channels, queues, locations, hours, languages and teams. Define what must not enter the help desk and where it goes. Record volumes, peaks and sensitive-data limits.
A product cannot be evaluated responsibly if one team imagines internal IT while another expects consumer omnichannel service.
Write the ticket lifecycle
Define new, assigned, active, waiting, resolved, closed and reopened states as needed. For each, name owner, allowed transitions, required evidence and clock behavior. Keep the model understandable to agents and reporters.
Specify cancellation, duplicate, linked requests and major incident behavior. These paths expose more product fit than a happy-path tour.
Build the mandatory gate
| Area | Scenario | Pass evidence |
|---|---|---|
| Intake | email with attachment and duplicate reply | one coherent ticket and retained content |
| Ownership | ambiguous request enters fallback queue | visible owner and ageing control |
| SLA | priority changes while waiting on customer | clock follows approved rule |
| Access | restricted case transferred between teams | least access and audit retained |
| Recovery | integration fails after ticket creation | exception visible and replay safe |
Test agent work
Ask agents to triage, search context, use knowledge, collaborate, reply, reassign and close. Count navigation and duplicate capture, but also observe whether the required evidence remains coherent.
Include bulk or repetitive work, keyboard use, mobile need and a new-agent scenario. An interface optimised for a demo case may be slow at operational volume.
Test requester experience
Submit through each required channel. Inspect acknowledgement, identity, status, reply, attachment and escalation to a person. Test accessibility and plain-language communication.
If a portal is required, verify account recovery, request visibility, delegated access and privacy between organisations.
Verify routing and service commitments
Use real categories, skills, schedules, priorities and entitlements. Test unmatched requests, unavailable teams, reopened tickets, supplier wait and daylight-saving or holiday boundaries.
Require traceable clock calculations. A summary SLA percentage is not enough if agents and customers cannot understand why a case breached.
Evaluate knowledge as an operation
Test draft, review, approval, audience, search, feedback, version and retirement. Link an article to a response and update it after a changed procedure.
Measure successful use and repeated contact, not only article views or suggested-answer clicks.
Inspect data and integrations
Define identity, assets, products, contracts, orders and monitoring events needed by the service. For each integration, specify authority, identifier, timing, failure, retry and reconciliation.
Export tickets with conversations, timestamps, relationships, attachments and knowledge links. A limited export can make later migration or audit costly.
Assess administration and operations
Have the future administrator create a queue, rule, template, role, report and safe change. Review environment, release, backup, monitoring, support and supplier responsibilities.
Estimate monthly ownership. Flexibility without change control can produce inconsistent queues and reports.
Define reporting before evaluating dashboards
List the decisions supervisors and service owners make: staffing, routing, backlog recovery, knowledge investment and problem elimination. Define measures and trace them to ticket events. Test age distributions and reopened work, not only averages.
Export the underlying case set for one report and reconcile it. A polished chart is weak evidence if clock, status or exclusion rules cannot be explained.
Check security and privacy through cases
Test restricted requests, attachments, internal notes, guest or customer access, reassignment, deleted users and export. Verify least privilege, audit where needed, retention and deletion. Confirm that notification content does not leak sensitive context.
Map supplier support access and responsibilities. A help desk often centralises information from many services, which increases the consequence of broad access.
Plan implementation and migration
Inventory addresses, forms, queues, open requests, knowledge, users, templates and reports. Decide what must migrate and what can remain in a controlled archive. Reconcile open tickets by status, owner and age.
Run parallel monitoring without duplicate processing, define cutover and rollback, and confirm that new inbound requests cannot disappear between mail and the ticket system.
Review commercial and exit boundaries
Model agent, requester, asset, channel, automation, storage and reporting costs in the proposed edition. Include implementation and administration. Verify which capabilities require add-ons or consumption pricing.
Test useful export and contract exit. Retaining ticket text without attachments, relationships, audit or knowledge links may not support continuity.
Score evidence, not confidence
Use pass, fail, needs research and not applicable for mandatory items. Score preferences only after the gate. Retain screenshots, exports, notes and unresolved assumptions linked to each criterion.
Pilot the highest-risk queue with success, stop and rollback conditions. The final checklist should support a defensible service decision, implementation plan and later acceptance.
Assign an owner and expiry to every needs-research item. Before contract signature, confirm that no mandatory unknown has been converted silently into a neutral score or an implementation assumption.