> 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/general/mvno-launch-faq.md).

# MVNO Launch FAQ

Common questions about launching a managed MVNO on Reach.

### Quick answers

<details>

<summary>How do I build my own MVNO?</summary>

You can build one from scratch.

It is slow and expensive.

You must source and integrate:

* carrier or network access
* provisioning
* billing
* payments
* tax
* care tooling
* reporting
* fraud controls
* fulfillment

The faster path is Reach’s managed MVNO platform.

Reach runs the core stack.

You focus on brand inputs and go-to-market.

If you’re deciding, talk to Reach about launch options.

Ask about MVNO sandbox paths to validate flows.

</details>

<details>

<summary>What’s included out of the box vs paid add-ons?</summary>

Included in the standard managed MVNO scope:

* core web and app experience
* activation and provisioning flows
* billing
* payments
* care tooling (Reach Central)
* reporting and standard dashboards
* standard APIs

Anything beyond template or config boundaries is usually a paid add-on.

Add-ons are typically time and materials (T\&M).

</details>

<details>

<summary>How fast can we launch, and what are the main launch dependencies?</summary>

Typical flow:

1. scope and requirements
2. provide brand and operational inputs
3. Reach config and build
4. staging review
5. sign-off
6. go-live

Common launch delays:

* brand assets and copy arrive late
* payment decisions are not finalized
* SSO readiness is unclear
* network and SIM decisions are pending

</details>

<details>

<summary>What do we need to provide during onboarding?</summary>

Typical onboarding inputs:

* brand identity and assets
* support contacts and escalation paths
* plan selection and pricing
* payment descriptor and gateway decision
* domain and DNS inputs
* credentials for brand-owned integrations

Common examples of brand-owned integrations:

* analytics
* tag manager
* affiliate tooling

</details>

<details>

<summary>What customizations are allowed in my brand?</summary>

BAU branding and content must fit standard templates and specs.

Common examples:

* logos
* colors
* banners
* copy
* SEO fields

Anything beyond that is scoped work.

It is usually a bolt-on or custom build.

</details>

### Network identity and SIMs

<details>

<summary>Will customers see our brand on-device (SPN/611), and what are the constraints?</summary>

It is network-dependent.

Some branded display and 611 routing needs carrier work.

It can add lead time.

It can require new SIM production.

See [SPN FAQ](/faqs/network/spn-faq.md).

</details>

<details>

<summary>What SIM models do you support (pSIM, eSIM, SIM-in-hand), and who owns inventory/fulfillment?</summary>

Reach supports:

* pSIM
* eSIM
* SIM-in-hand flows

Fulfillment options:

* Reach fulfills end-to-end
* you hold bulk SIM inventory and distribute it

</details>

### Plans, swaps, promos

<details>

<summary>How do plans work: upgrades/downgrades, SIM swaps, and plan retirement?</summary>

Upgrades can be immediate.

Proration depends on your billing configuration.

Downgrades are next-cycle only.

SIM swaps are supported.

This includes pSIM ↔ eSIM swaps.

Plan retirement supports grandfathering.

Forced migrations are custom scoped work.

</details>

<details>

<summary>What promo/discount types can we run, and what are the guardrails?</summary>

Standard promo options include:

* coupon codes
* systematic promos

Standard guardrails:

* promos discount plan MRC only
* promos apply during purchase
* coupons can’t be removed once applied

More complex promo behavior is usually custom work.

</details>

### Payments, refunds, and dunning

<details>

<summary>How do payments, refunds, and non-payment (dunning) behave?</summary>

Autopay is required.

Customers must keep a payment method on file.

Payment retry and suspension follow a standard policy.

Data top-ups are non-refundable.

Mid-cycle refunds are not supported for:

* disconnections
* port-outs

See [Payment Gateway FAQ](/faqs/payments/payment-gateway-faq.md).

</details>

### Affiliates and reporting

<details>

<summary>How do I provide sales commission to my affiliates?</summary>

Commission management is usually handled outside Reach.

Common patterns:

* attribute via UTMs and GA4
* track in your affiliate tool
* reconcile using promo codes and standard reports
* pay partners externally

Deeper automation usually needs a custom integration or export.

</details>

<details>

<summary>What reporting do we get by default, and can we export it?</summary>

Standard dashboards and downloadable reports are available in Reach Central.

Common categories:

* ops
* support
* growth
* usage
* revenue
* logistics

Custom reporting is a paid add-on.

Some export mechanisms are also add-ons.

</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/general/mvno-launch-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.
