Philippines staffing blog ·
Run an Outsourced Help Desk Discovery Workshop
Turn queue evidence, customer journeys, authority limits, and operating constraints into a testable outsourcing scope.
Direct answer
A discovery workshop should end with an operating map, not a presentation deck full of agreeable phrases. The buyer needs to know which requests might move to an outsourced help desk, what evidence agents would see, which actions they could take, and where a client owner must step in. Those answers cannot come from a generic capability list. Bring real, redacted ticket samples and trace the work as it happens today. The awkward cases are the useful ones. They show where a queue label hides several different decisions or where a familiar employee is quietly supplying context that no procedure contains.
Start with customer intent rather than the current team chart. A customer who says "I cannot sign in" may need basic navigation, a password reset, identity recovery, an access approval, or an incident route. Each path uses different evidence and authority. Put representative requests on a board and group them by the outcome the customer needs. Then mark the source an agent would consult, the system involved, the permitted action, the stopping condition, and the next owner. This exercise often breaks one broad queue into a routine lane and several protected exceptions. That is useful scope work, not unnecessary complexity.
Ask the people who handle tickets to demonstrate the path. Written procedures tend to show the intended process, while ticket records reveal the workarounds, missing fields, and unofficial decisions used under pressure. Choose examples from normal work, repeat contacts, escalations, after-hours arrivals, and recently changed products. Remove customer details before the session. For every example, identify what was known at first contact and what became clear later. A provider should not be scored down for failing to infer facts that were absent. The design should make those facts available or provide an uncertainty route.
Map authority in plain verbs. Can the outsourced specialist view, explain, update, reset, cancel, refund, approve, export, or disclose? Avoid a single "full support" label. An agent may explain an approved billing policy but lack authority to issue a credit. The same person may help a verified user navigate account settings but stop before changing an administrator. Record who makes each protected decision and how that person accepts a handoff. A mailbox or department name is not enough if nobody is responsible for the next action during the promised service window.
Coverage questions belong beside the workflow. A weekday email queue behaves differently from concurrent chat or urgent after-hours escalation. For each proposed lane, note arrival patterns, service hours, known peaks, languages, accessibility needs, expected handling work, and dependency hours. Do not turn a historical average into a staffing promise during the workshop. The goal is to expose which data exists and which assumptions need testing. If the client cannot produce interval demand or waiting reasons, record the gap and choose a bounded pilot instead of pretending the estimate is precise.
Treat knowledge as a controlled dependency. Ask an agent to find the approved answer using the words a customer actually used. Check whether the article identifies its owner, scope, prerequisites, allowed steps, and escalation point. A folder of files is not a knowledge base if the team cannot tell which instruction is current. When two sources conflict, the workshop should assign a client owner to resolve them. The provider can log the conflict and prepare a draft, but it should not decide policy by selecting the easier version.
Tool access needs the same level of detail. List the minimum role required for each lane and distinguish read, comment, update, and administrative permissions. Include test access, authentication method, audit evidence, approval owner, review date, and removal trigger. If a proposed role exposes unrelated customers or powerful settings, redesign the lane before launch. "We trust the team" is not an access control. Named accounts and limited roles protect the customer, the provider, and the specialist who would otherwise be asked to work beyond an approved boundary.
Finish the session with scenarios, not broad assurances. Give the provider a routine request with complete information, a similar request with one critical fact missing, a sensitive exception, and a case that arrives when the primary owner is unavailable. Ask for the exact first reply, ticket notes, next action, handoff route, and customer checkpoint. The answers show whether the proposed model works at ticket level. They also reveal terms that both parties use differently, such as resolved, escalated, urgent, or verified. Define those terms before they enter reports or contracts.
The output should separate decisions from open questions. A useful register names the candidate lane, included intents, exclusions, systems, knowledge sources, authority, hours, receiving owner, evidence still needed, and person accountable for closing the gap. Add a date and acceptance test for each unresolved item. Do not hide gaps inside meeting notes. They will return during implementation, usually when time is shorter and access has already been requested. A visible unknown is manageable. An assumption presented as settled scope is not.
Use the map to choose the next step. Some lanes will be ready for detailed design. Others need data collection, source correction, security review, or an owner decision. A small pilot may be appropriate when the path is clear but demand or handling effort is uncertain. The discovery workshop has done its job when the buyer can explain what the outsourced team would own, how success would be observed, where it must stop, and which facts still prevent a responsible commitment. That is a stronger buying position than a long list of features because it connects the service to actual customer work.
Authoritative sources
- NIST Cybersecurity Framework 2.0
- NIST SP 1305: Cybersecurity Supply Chain Risk Management
- NIST Digital Identity Guidelines
- CISA Secure by Design
- ICO data minimisation guidance