Customer support calls
Managed IT service outage call intake and escalation workflow
A practical phone workflow for MSP outage reports, identity checks, impact capture, ticket ownership, status updates, and safe escalation.
Treat the call as evidence, not diagnosis
When a client says “everything is down,” the receptionist’s job is to create a reliable starting point for the technical team. That means verifying the permitted caller details, capturing observable symptoms, checking the approved status source, opening or linking the right ticket, and explaining the next communication step. It does not mean guessing at a cause or walking the caller through unapproved changes.
This distinction is especially useful for a managed service provider covering several clients. The same phrase may describe one locked account, an office internet failure, a cloud application incident, or a planned maintenance window. A structured intake turns urgency into information engineers can use.
Before delegating the queue, define which organizations are covered, which contacts may report incidents, the supported hours, priority rules, and the system of record. Include a separate path for suspected security events because a compromised account or phishing report should not wait in an ordinary support queue.
Verify without creating a new security problem
Use the provider’s approved caller-verification method. Do not ask a caller to read a password, one-time code, private key, full payment credential, or recovery secret over the phone. If the caller cannot pass verification, record a safe callback method and route the case under the failed-verification rule. Do not reveal client systems, user names, ticket history, or outage details before authorization.
Be alert to social engineering. A caller who pressures the receptionist to bypass controls, change an administrator, reset multifactor authentication, or reveal a staff schedule may be creating an incident rather than reporting one. The CISA guidance on recognizing and reporting phishing provides a useful basis for awareness training.
The intake form should show which verification step passed, failed, or was unavailable. Avoid writing the verification answers themselves in a general note. The evidence should prove the process was followed without storing another reusable secret.
Capture impact in observable terms
Ask what the caller was trying to do, what appeared on screen or happened on the call, when it last worked, and how many known users are affected. Record the exact error text when practical, but do not invite the caller to send sensitive screenshots through an unapproved channel. Note location, device or service, and whether a known workaround exists.
Useful intake fields include:
- Client organization and verified caller.
- Affected service, location, and known user count.
- First observed time and time zone.
- Exact symptom or error, without an invented cause.
- Business process affected, such as phones, checkout, scheduling, or email.
- Safety, security, or regulatory concern stated by the caller.
- Status page or maintenance notice checked.
- Existing incident linked or new ticket number created.
Ask “Who else have you confirmed is affected?” instead of accepting “everyone” as a measured count. A caller may reasonably feel that the whole business is blocked, but the engineering team still needs the basis for the claim.
Apply a written priority matrix
Priority should come from defined impact and urgency factors, not the caller’s title or volume. The MSP might distinguish a single-user inconvenience, a multi-user degradation, a site outage, and a suspected security or safety event. The receptionist collects the factors and the ticketing rule assigns or suggests the priority. An authorized owner handles overrides.
Never promise a resolution time unless the approved service agreement and current incident state support that statement. “An engineer will acknowledge this within the applicable response window” is different from “Your service will be restored in an hour.” The first describes an owned next step; the second may be an unsupported outcome.
If the caller disputes the priority, record the additional impact they describe and route the review. Do not bargain over severity. The technical owner can reassess with complete evidence.
Link duplicates without losing local impact
During a widespread incident, many people may call about the same symptom. Check the approved incident register before opening a separate primary event. Link the caller or organization to the existing incident while preserving any distinct location, error, or business impact.
A duplicate is not useless. It can show geographic spread, a service not previously known to be affected, or a customer who requires an accessible update channel. The note should therefore include the local facts even when it links to a master incident.
Tell the caller the public status accurately. If the technical team has acknowledged an incident, use the approved update. If they have not, say the report has been recorded and assigned. Do not announce a breach, root cause, or vendor fault based on speculation.
Define the security-event fork
Certain phrases should activate a separate playbook: unexpected multifactor prompts, suspected phishing, data sent to the wrong person, ransomware message, lost administrative device, unauthorized account changes, or a request to conceal activity. The receptionist should preserve the caller’s facts, avoid asking them to explore further, and notify the approved security route.
The NIST Cybersecurity Framework 2.0 can help an organization frame governance, detection, response, and recovery responsibilities. It does not replace a client-specific incident plan. The call guide should state who can declare an incident, who communicates externally, and which details must stay out of ordinary notes.
When no security owner acknowledges within the defined interval, use the named backup path. “Email IT” is not enough for a time-sensitive event; the escalation needs an address or queue, an acknowledgment rule, and a fallback.
Close with ownership and an update path
Read back the affected service, scope, first observed time, and safe callback method. Give the ticket number and explain who owns the next update. If the caller needs updates in a particular channel, record it. Do not ask them to repeatedly call for status when the workflow can send an acknowledgment.
The handoff should separate facts, caller statements, and actions. For example: “Verified billing contact reports voice service unavailable at the west office for six confirmed users since 09:20 Pacific. Status page shows no posted event at 09:34. No troubleshooting performed. Ticket 4821 opened as multi-user service disruption; network queue paged; caller requests SMS acknowledgment.”
That record lets an engineer begin without unpicking a diagnostic guess from the intake.
Audit for continuity, not just speed
Review a mix of single-user tickets, major incidents, failed verification, and security forks. Check required-field completeness, source timestamps, correct client association, priority evidence, duplicate linkage, and acknowledgment. Compare the call record to the final ticket so corrections do not disappear between systems.
Useful measures include tickets reassigned for wrong client or service, priority changes caused by missing intake, time to owner acknowledgment, duplicate-link rate, caller repeat contacts before an update, and records containing prohibited secrets. A low average handle time is not a success if engineers must call back for basic facts.
When the same symptom is described inconsistently, improve the intake prompts. When priorities are frequently overridden, calibrate the matrix with real cases. Workflow fixes usually have more leverage than telling receptionists to “be more technical.”
Pilot the queue safely
Test a locked account, a single-site internet failure, a known cloud incident, a suspicious login report, an unverified caller, and a ticketing-system outage. Confirm that the receptionist can reach the backup owner and record the event offline in an approved minimal format. Reconcile those offline records as soon as the system returns.
Limit the pilot to named clients and services. Review the first week daily, then expand only when verification, routing, and acknowledgment are consistent. If your MSP wants a Philippines-based receptionist to support intake while engineers retain technical decisions, review the inbound customer calls service and use the QA scorecard to plan sample reviews.
Frequently asked questions
Should a receptionist troubleshoot an outage?
Only when a specific, approved script authorizes a low-risk step. Configuration changes, credential resets, security decisions, and diagnosis belong with trained technical owners.
What should be said about restoration time?
State the approved acknowledgment or update commitment. Do not promise restoration unless an authorized source provides a current customer-facing estimate.
How should suspected phishing be routed?
Use the dedicated security-event path, capture the observable facts, avoid collecting secrets, and require acknowledgment from the named owner or backup.