Philippines staffing blog ·
Set Exit Criteria for an Outsourced Help Desk Pilot
Decide whether to expand, correct, extend, narrow, or stop a pilot using declared evidence rather than calendar pressure.
Direct answer
A pilot should answer a defined operating question, not serve as a vague rehearsal for an assumed rollout. Exit criteria state what evidence supports expansion, what defects require correction, what uncertainty justifies extension, and what conditions trigger narrowing or stop. Write them before live work begins, while stakeholders can still disagree without schedule pressure. Define the tested request population, channels, hours, users, systems, permissions, knowledge versions, provider cohort, client owners, and observation window. Anything outside that boundary is not evidence that the broader service will work.
Choose measures that reflect the intended customer outcome and the control model. Useful evidence may include correct eligibility decisions, first routing, answer accuracy, boundary adherence, customer checkpoints, escalation acceptance, record quality, article use, access variance, repeat contact, and quality-review agreement. Volumes and response times matter, but a fast unsafe answer is not success. Declare mandatory gates for consequential failures such as identity bypass, unauthorized financial action, missing incident escalation, or exposed sensitive data. Do not average a critical failure away with many easy tickets.
Define denominators and review samples. State which tickets count, how reopened or merged cases are treated, what waiting states pause measures, and how incomplete records are handled. Stratify samples so rare high-consequence lanes receive review alongside routine work. Include different shifts and specialists if the future model depends on them. Record interventions by client or trainer because rescued cases are not independent provider success. Where the pilot volume is too small to evaluate a lane, label it untested instead of converting zero observed failures into proof of safety.
Give defects a severity and disposition path. A wording improvement may be corrected and retested inside the pilot. A missing owner, broken access boundary, unreliable integration, or unclear policy may require the affected lane to pause. Assign each defect to the party able to fix its source and define the retest. Avoid blaming individual agents for ambiguous material or unusable permissions. Equally, do not hide repeated execution errors behind a promise of more training. Evidence should lead to a source correction, skill correction, scope decision, or explicit risk decision by the authorized owner.
Protect the comparison from moving targets. Version the scope, knowledge, system configuration, scenario set, and measurement rules. When a material change occurs, state whether earlier cases remain comparable and whether the observation window restarts for that lane. Note unusual demand, outages, client-owner absence, product releases, and seasonal effects. A pilot can still be useful under imperfect conditions if limitations are transparent. It becomes misleading when the team quietly changes definitions until results appear acceptable or compares supervised early work with unsupported later work as though conditions were identical.
Hold the exit review around decisions. For each lane, present evidence, limitations, open defects, customer effect, retained client effort, and the proposed disposition: expand, continue under supervision, extend to collect missing evidence, narrow, or stop. Name the accountable decision owner and required security, privacy, finance, legal, workforce, or product reviewers. Include operational readiness for the next state: staffing, access, articles, escalation capacity, communications, reporting, rollback, and contract treatment. A positive pilot result does not automatically prove the organization is ready for a larger launch.
Preserve the exit pack and monitor the first post-pilot sample. Expansion changes volume, mix, supervision, and owner demand, so compare new results with the pilot baseline without assuming they must match. Track defects that were accepted temporarily and enforce their expiry. Communicate scope accurately to customers and internal teams; do not imply unsupported 24-hour coverage or authority. A disciplined exit decision gives both buyer and provider permission to say not yet, not this lane, or proceed with named safeguards. That honesty is more valuable than declaring every pilot a success and discovering its limits after a full handoff.
Include retained client work in the exit decision. A provider may handle tickets accurately while requiring constant clarification, manual approvals, schedule repair, data cleanup, or escalation chasing from the buyer. Measure that effort by activity and owner rather than hiding it inside project management. Decide which retained work is an intentional part of the future operating model and which shows that the pilot has not reached stable ownership. The provider should also disclose interventions by senior staff that will not be available at scale. A decision that considers only frontline metrics can approve an arrangement whose apparent performance depends on unsustainable support behind the scenes.
For a concrete review, suppose a pilot covers email questions for two products. Product A passes accuracy, boundary, and customer-checkpoint gates with low intervention. Product B has acceptable response times but repeated escalation returns because the client owner map is incomplete. The correct disposition may be to expand Product A, keep Product B supervised, repair its ownership map, and retest a defined sample. The pilot is neither wholly passed nor failed. Lane-level evidence avoids forcing a binary story, preserves momentum where controls work, and keeps the unresolved product from entering full service simply because the commercial schedule expected one launch date.
Plan the stop path with the same care as expansion. Name who tells customers and staff, how open tickets return to a stable owner, when provider access ends, which artifacts and knowledge remain, how temporary data is disposed of, and what invoices or commitments require authorized review. Stopping a pilot is not evidence of organizational failure; it may be the correct result of a controlled experiment. A rehearsed exit keeps the team from extending unsafe work merely because reversal feels operationally difficult and preserves useful learning for a later design.
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