How do I contact Cloudflare sales and what should I prepare for a Cloudflare One or Magic WAN proof of concept?

Most teams reach out to Cloudflare sales when they’re ready to move beyond VPNs, legacy MPLS, and scattered security tools—and want to test Cloudflare One or Magic WAN in a real environment. To get value quickly, you’ll want two things ready: a clean way to contact the right Cloudflare team, and a focused proof of concept (PoC) plan that mirrors your “day 1” production goals, not a lab you’ll never roll out.

This guide walks through both: how to contact Cloudflare sales, and exactly what to prepare for a Cloudflare One or Magic WAN proof of concept so you can connect, protect, and modernize your network with minimal disruption.

How to contact Cloudflare sales

You can reach Cloudflare sales directly from the main site:

Go to https://www.cloudflare.com
In the top navigation, choose:
- “Contact sales” (for general sales inquiries, enterprise plans, and PoCs), or
- “For enterprises” → “Contact sales” for larger deployments
For Cloudflare One (SASE / Zero Trust) or Magic WAN (Cloudflare WAN), use:
- Cloudflare One / SASE pages → “Contact sales”
- Network services / Cloudflare WAN pages → “Contact sales”

If you already have a Cloudflare account, you can also:

Log in, then click “Request a demo” or “Contact sales” from the dashboard.
Work through your existing Cloudflare account team if you’re already an enterprise customer.

When you submit the form, you’ll typically be asked about:

Company size and industry
Primary interest (e.g., Cloudflare One, Magic WAN, or broader connectivity cloud strategy)
Use cases (e.g., replace VPN, secure remote users, decommission MPLS, unify traffic inspection)
Regions where you operate and where users/apps are

This context helps Cloudflare match you with the right specialists and pre-align the PoC scope.

The quick overview: what you’re buying time to prove

What It Is:
A PoC for Cloudflare One (agile SASE / Zero Trust) and/or Magic WAN (Cloudflare’s WAN-as-a-Service) using Cloudflare’s global connectivity cloud as the control point for security and routing.
Who It Is For:
Network, security, and infrastructure teams that want to test Zero Trust access, SASE, and WAN modernization before committing to a full rollout.
Core Problem Solved:
Reducing the risk of network transformation. A PoC lets you validate that Cloudflare can:
- Replace or reduce VPN and backhauling
- Secure users and apps with Zero Trust policies
- Move from MPLS / hub-and-spoke to a cloud-native WAN
- Maintain or improve performance and reliability

What to prepare before your Cloudflare One PoC

For Cloudflare One, you’re proving that Cloudflare can act as your SASE and Zero Trust fabric: connecting users, apps, and Internet access through Cloudflare’s edge, where every request is evaluated for identity and context.

1. Define 2–3 concrete Zero Trust outcomes

Go into the first sales and solution-architect conversation with clear, limited goals. Good examples:

Replace VPN for a set of internal web apps
“We want SSO + MFA for 5 internal web apps and zero inbound ports, for 300 users.”
Secure outbound Internet access for a pilot user group
“We want DNS-level and HTTP-layer filtering for 100 users, enforced everywhere (office, home, travel).”
Lock down SSH/RDP access to a critical environment
“We want identity-based SSH access to a production environment with full audit logging.”

Your PoC should not be “replace everything we have in 30 days.” Focus on a slice with real user impact and clear success metrics.

2. Gather your identity and device context details

Cloudflare One uses your IdP and (optionally) device posture to drive policy. Come prepared with:

Identity provider (IdP):
- Which IdPs you use: Okta, Azure AD, Google Workspace, Ping, etc.
- Whether users are consolidated in one IdP or multiple
- Whether you already enforce MFA and where
Groups and attributes:
- Key AD/Okta groups (e.g., “Finance,” “Engineering,” “Contractors”)
- Any attributes you use for least privilege (department, location, job role)
Device posture (if applicable):
- Endpoint security tools (EDR/AV, MDM, OS patching tools)
- Whether you want policies like “only corporate-managed, healthy devices can access system X”

Cloudflare’s Zero Trust policies will evaluate requests against these signals at the edge, so knowing what’s available helps design realistic rules.

3. Choose pilot applications and traffic flows

Identify a small but meaningful set of resources to onboard:

Internal web apps (best first step)
- HR or finance portal
- Developer tools (Jenkins, GitLab, Jira)
- Admin panels or internal dashboards
Non-HTTP apps (optional second phase):
- SSH access to key servers
- RDP to jump hosts
- SMB file shares
- Databases or custom TCP services

For each resource, note:

Where it is hosted (on-prem data center, VMware, cloud VPC like AWS/Azure/GCP)
Current access pattern (VPN, direct public access, IP allowlists)
Any existing inbound firewall rules or VPN concentrators

You’ll likely use Cloudflare Tunnel (Argo Tunnel) for private apps so that apps are exposed via outbound-only tunnels—no opening inbound ports.

4. Clarify your current network egress model

Cloudflare One can secure:

User → Internet traffic (SWG / DNS / HTTP filtering)
User → private app traffic (Zero Trust access via Access + Tunnel)
Branch / data center → Internet traffic (via GRE/IPsec to Cloudflare or the WARP client)

Prepare:

A basic network diagram: offices, data centers, cloud VPCs, and how traffic currently exits (MPLS, local breakouts, centralized firewalls).
Where your existing DNS, proxies, and firewalls sit.
Where you’d be comfortable inserting Cloudflare in the path during the PoC (e.g., “pilot group of users points WARP client at Cloudflare,” or “this branch routes HTTP traffic via Cloudflare”).

5. Define clear PoC success metrics

Agree internally (before the call) on how you’ll evaluate the PoC. Examples:

User experience:
- Internal apps feel like SaaS: one SSO login, no VPN client
- No noticeable latency added to key applications
Security posture:
- All access requests logged centrally
- Ability to enforce MFA and per-app policies
- No open inbound ports for PoC apps
Operations:
- Time to onboard first app/user group (e.g., “within 1–3 days”)
- Policy change workflows are simpler than legacy firewall/VPN changes

Share these with sales/SE so the PoC is structured around measurable outcomes.

What to prepare before your Magic WAN PoC

With Magic WAN / Cloudflare WAN, you’re testing whether Cloudflare’s network can replace or augment your WAN—often in parallel with Cloudflare One for security. The aim is to connect branches, data centers, and clouds into the connectivity cloud without backhauling or hardware sprawl.

1. Inventory your sites, circuits, and WAN architecture

Magic WAN PoCs go smoother when you have a clear map of your current WAN. Prepare:

Site list for the pilot
- 1–3 branches, plus optionally a data center or cloud VPC
- For each: bandwidth, primary/backup ISP links
Current WAN model
- MPLS, SD-WAN, Internet-only, or hybrid
- Existing network hardware (routers, firewalls, SD-WAN appliances)
Routing protocols and addressing
- Use of BGP vs static routes
- IP ranges used per site

You don’t have to touch your entire WAN. Start with a subset where you can test new paths without impacting critical production.

2. Decide target use cases for Magic WAN

Some focused PoC patterns that work well:

Branch-to-Internet offload via Cloudflare
- Route all or selected traffic from a branch to Cloudflare for security + performance.
Branch-to-branch / branch-to-DC connectivity
- Replace MPLS/hub-and-spoke with Cloudflare network paths between sites.
Cloud VPC interconnect
- Connect AWS/Azure/GCP VPCs and on-prem via Cloudflare instead of DIY mesh.

Share your top 1–2 use cases so the Cloudflare team can choose the right technical path (e.g., GRE/IPsec tunnels, Cloudflare Network Interconnect).

3. Gather security and policy requirements

Magic WAN is usually paired with Cloudflare One services (e.g., Firewall-as-a-Service, Secure Web Gateway). Capture:

Which security controls you currently apply at the WAN edge:
- Firewall rules (L3/L4)
- Web filtering
- IDS/IPS
What you want to test:
- Central policy with local enforcement
- Reduced hardware footprint
- Simplified change management for new routes and security rules

This helps decide the shape of the combined PoC (Magic WAN + Cloudflare One).

4. Prepare a change window and rollback plan

Your network team will want guardrails:

Identify low-risk sites or test VLANs for first tunnel cutover.
Agree on a maintenance window and a simple rollback (e.g., switch traffic back to existing router or remove GRE route).
Confirm success/failure criteria per test (packet loss, latency, application reachability).

The Cloudflare team will help design this, but walking into the sales conversation with your operational constraints already mapped out speeds things up.

How Cloudflare One and Magic WAN PoCs typically run

The exact steps will be tailored to your environment, but most PoCs follow a similar pattern.

Discovery and design (sales + solutions engineer)
- Review your goals, scope, and environment.
- Map desired outcomes to Cloudflare One and/or Magic WAN capabilities.
- Choose pilot apps, sites, and user groups.
- Align on success metrics, timeline, and owner on your side.
Initial configuration
- Connect your IdP to Cloudflare Zero Trust.
- For Cloudflare One:
  - Deploy Cloudflare Tunnel from an internal environment to Cloudflare edge for private apps.
  - Configure Access policies based on identity and device posture.
  - Optionally deploy WARP client to pilot users for secure web gateway and Zero Trust networking.
- For Magic WAN:
  - Configure GRE/IPsec tunnels or interconnect from pilot sites to Cloudflare.
  - Set up routes and basic network policies.
Pilot rollout
- Onboard a small group of users or a subset of traffic.
- Validate:
  - Users can reach apps via Cloudflare without VPN.
  - Traffic flows through Cloudflare edge as expected.
  - Logs and analytics show every request is evaluated and recorded.
Tuning and expansion
- Adjust policies (e.g., refine user groups, tighten access rules).
- Optionally add more apps, branches, or traffic types.
- Compare performance vs your baseline (latency, page load, reliability).
Review and next steps
- Revisit your defined success metrics.
- Decide on rollout path: which apps/sites to add next, what legacy hardware or VPN use can be reduced, how to operationalize changes going forward.

What to share with Cloudflare sales in your first conversation

To get a Cloudflare One or Magic WAN PoC scoped efficiently, have these answers ready:

Primary goal for the PoC
- “Replace VPN for X apps / Y users”
- “Test Internet egress security for Z users”
- “Pilot WAN modernization for A branches”
Rough scale
- Number of users
- Number of sites
- Regions where you operate
Core platforms
- IdP: Okta, Azure AD, Google Workspace, etc.
- Hosting: on-prem DCs, AWS/Azure/GCP, SaaS mix
- WAN: MPLS, SD-WAN vendor, Internet-only
Timeline
- When you want to start
- Any hard deadlines (e.g., MPLS contract renewal, data center exit, VPN hardware refresh)
Security and compliance drivers
- Regulatory constraints
- Logging and audit requirements
- Any “no inbound ports” or “no VPN for contractors” mandates

This lets Cloudflare propose a PoC that’s aligned with your reality, not a generic lab.

Summary

To contact Cloudflare sales for a Cloudflare One or Magic WAN proof of concept, use the “Contact sales” and “Request a demo” paths on cloudflare.com or from the Cloudflare One and Network Services product pages, and specify that you’re interested in Cloudflare One (SASE / Zero Trust), Magic WAN, or both.

Before you speak with sales, prepare:

Clear, narrow PoC goals (VPN replacement, secure web access, WAN modernization).
Details on your identity provider, key apps, sites, and traffic flows.
A short list of pilot users/sites and concrete success metrics.

Going into the conversation with this level of clarity helps Cloudflare design a PoC that proves what matters: that the connectivity cloud can connect your users and locations, protect your apps and data at the edge with Zero Trust, and give you a practical path to modernize your WAN without risky, big-bang changes.

Next step

Get Started