Support Model FAQ
L1/L2/L3 responsibilities and the standard escalation flow.
Quick answers
What is the Reach support model?
Reach uses a 3-tier support model:
L1: customer-facing support (brand-owned, or Reach Care if contracted)
L2: Reach Technical Support
L3: advanced Reach platform / network specialists (and carrier teams when needed)
Where do all customer issues start?
All customer issues start at L1.
L1 owns customer communication and only escalates when required.
Do L2 or L3 teams speak directly with end customers?
No.
L2 and L3 communicate via tickets and updates back to L1.
L1 (Customer Care)
What does L1 handle?
L1 is the customer’s first contact. L1 typically handles:
sign-up and onboarding questions
order status and tracking
plan, billing, and payment questions (customer-facing support)
activation and post-activation help
basic troubleshooting (device checks, simple connectivity checks)
checking what’s available in Reach Central
creating escalation tickets for L2 when needed
When should L1 escalate to L2?
Escalate when:
the action can’t be completed in Reach Central
standard troubleshooting is complete and the issue persists
a suspected outage needs confirmation
an unknown error appears (include the exact message)
the request requires backend changes (for example, identifier or address updates)
L2 (Reach Technical Support)
What does L2 handle?
L2 handles technical and backend requests that require deeper access. Common examples:
confirming outages and incident impact
account status updates (activation, disconnection, resets)
identifier updates (IMEI, ICCID)
customer profile updates (billing address, shipping address, email)
coverage validation for a specific location
live usage checks and data reset investigation
order status validation when it’s not visible to L1
refund status checks and coordination with Finance
How does L2 communicate?
L2 does not contact end customers.
L2 updates the ticket and communicates status back to L1.
L3 (Advanced platform and network support)
What does L3 handle?
L3 handles complex, systemic, or platform-level issues. Common examples:
data synchronization mismatches (usage, throttling, allocations)
persistent connectivity issues requiring deeper network investigation
app login/auth issues that aren’t tenant-config related
complex billing or eligibility issues that require specialist review
cross-system incidents that impact multiple customers or tenants
Who can escalate to L3?
Only L2 escalates to L3.
This keeps triage consistent and prevents duplicate investigations.
The exact split of responsibilities can vary by contract. If scope is unclear, raise it through L2.
Ticketing and escalation flow
What is the standard escalation flow?
Customer contacts L1
L1 troubleshoots and attempts resolution
If needed, L1 raises a ticket to L2
L2 investigates and resolves
If needed, L2 escalates to L3
L3 resolves and updates L2
L2 updates L1
L1 updates the customer
What should L1 include in an escalation ticket?
Include enough detail for L2 to reproduce and confirm impact:
customer identifiers needed to locate the account
device identifiers (IMEI) and SIM/eSIM identifiers (ICCID), if relevant
timestamps and timezone
exact error messages (copy/paste where possible)
steps already taken by L1
scope (single customer vs multiple customers)
location (city/state/ZIP) for coverage or performance issues
Can L1 contact L2 or L3 outside the ticketing flow?
No.
Use the ticketing flow so updates are tracked and auditable.
Common questions
Who handles refunds or billing discrepancies?
L2 coordinates investigation and works with Finance as needed.
L1 communicates outcomes to the customer.
Last updated