> For the complete documentation index, see [llms.txt](https://docs.reachplatform.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.reachplatform.com/faqs/support/support-model-faq.md).

# Support Model FAQ

L1/L2/L3 responsibilities and the standard escalation flow.

### Quick answers

<details>

<summary>What is the Reach support model?</summary>

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)

</details>

<details>

<summary>Where do all customer issues start?</summary>

All customer issues start at **L1**.

L1 owns customer communication and only escalates when required.

</details>

<details>

<summary>Do L2 or L3 teams speak directly with end customers?</summary>

No.

L2 and L3 communicate via tickets and updates back to L1.

</details>

### L1 (Customer Care)

<details>

<summary>What does L1 handle?</summary>

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

</details>

<details>

<summary>When should L1 escalate to L2?</summary>

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)

</details>

### L2 (Reach Technical Support)

<details>

<summary>What does L2 handle?</summary>

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

</details>

<details>

<summary>How does L2 communicate?</summary>

L2 does not contact end customers.

L2 updates the ticket and communicates status back to L1.

</details>

### L3 (Advanced platform and network support)

<details>

<summary>What does L3 handle?</summary>

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

</details>

<details>

<summary>Who can escalate to L3?</summary>

Only **L2** escalates to L3.

This keeps triage consistent and prevents duplicate investigations.

</details>

{% hint style="info" %}
The exact split of responsibilities can vary by contract. If scope is unclear, raise it through L2.
{% endhint %}

### Ticketing and escalation flow

<details>

<summary>What is the standard escalation flow?</summary>

1. Customer contacts **L1**
2. **L1** troubleshoots and attempts resolution
3. If needed, **L1** raises a ticket to **L2**
4. **L2** investigates and resolves
5. If needed, **L2** escalates to **L3**
6. **L3** resolves and updates **L2**
7. **L2** updates **L1**
8. **L1** updates the customer

</details>

<details>

<summary>What should L1 include in an escalation ticket?</summary>

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

</details>

<details>

<summary>Can L1 contact L2 or L3 outside the ticketing flow?</summary>

No.

Use the ticketing flow so updates are tracked and auditable.

</details>

### Common questions

<details>

<summary>Can L1 update IMEI or ICCID?</summary>

No.

IMEI and ICCID updates are handled by **L2**.

</details>

<details>

<summary>Can L1 update billing address, shipping address, or email?</summary>

No.

These updates are handled by **L2**.

</details>

<details>

<summary>Who handles refunds or billing discrepancies?</summary>

**L2** coordinates investigation and works with Finance as needed.

L1 communicates outcomes to the customer.

</details>

<details>

<summary>What if billing completed but usage didn’t reset?</summary>

Escalate to **L2**.

L2 validates the billing event and investigates usage reset behavior.

</details>

<details>

<summary>Is BYOD supported?</summary>

Yes.

The device must be **unlocked** and **compatible** with the network.

</details>

<details>

<summary>Is eSIM supported?</summary>

Yes.

L1 can guide standard activation. Escalate to L2 for provisioning failures or backend mismatches.

</details>


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.reachplatform.com/faqs/support/support-model-faq.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.