Having recently navigated the process of initiating a proof of concept with Versa Networks for a potential SASE architecture implementation, I found the documentation requirements to be more comprehensive than those of some other vendors in the networking and security space. My interest was piqued by their integrated approach, promising a unified stack for SD-WAN, security, and analytics, which led me down the path of requesting a PoC. For fellow tinkerers and architects considering a similar evaluation, here is a detailed breakdown of the documents and information they typically require to commence a formal proof of concept engagement.
Based on my experience and corroborated by discussions with their sales engineering team, the following items were necessary to move beyond the initial demo stage. It's worth noting that the exact list can vary slightly depending on the scale and declared intent of your PoC, but this forms the core.
* **Corporate Documentation:** This establishes the legitimacy of your organization. They required a copy of our business license or certificate of incorporation. This is fairly standard when dealing with enterprise software vendors, especially those providing security-focused solutions.
* **Technical Environment Overview:** A detailed, non-public network diagram was essential. This needed to illustrate current WAN topology, primary and branch office locations, internet breakouts, and existing security appliances (firewalls, proxies). They were particularly interested in understanding traffic flows and potential insertion points for their Controllers and Gateways.
* **PoC Scope & Success Criteria Definition:** We had to collaboratively draft a document outlining the specific features to be tested. This went beyond "test SD-WAN." We itemized use-cases like:
* Application-aware path selection policies for SaaS traffic.
* IPSec tunnel establishment between a cloud gateway and a simulated branch CPE.
* Integration of their cloud-delivered firewall with a subset of our internal services.
* Basic reporting and monitoring capabilities during the trial period.
* **Contact Information Roster:** A clear list of technical and business contacts from our side, including roles (network architect, security lead, project manager) and their responsibilities within the PoC. This ensures efficient escalation and support.
* **IP Addressing Scheme:** They requested our planned internal and external IP address ranges for the PoC infrastructure to avoid conflicts and assist in configuration templating. This included public IPs for their CPE devices and private subnets for simulated user networks.
* **Signed PoC Agreement:** A formal document provided by Versa outlining the terms of the evaluation, including duration (typically 30-60 days), support levels, data handling policies, and the process for returning or decommissioning equipment after the trial.
The process felt more structured than, for instance, setting up a pure cloud-service PoC with a vendor like Cloudflare or Zscaler, where the initial barrier is often just a credit card. The requirement for the network diagram and success criteria, however, was immensely beneficial. It forced a disciplined evaluation framework and allowed their engineers to pre-configure elements of their Versa Director and Versa Controller platforms, which significantly accelerated the *actual* hands-on tinkering phase once the virtual appliances or hardware were provisioned.
For those preparing to engage, I would strongly recommend having these documents prepared in advance. The most time-consuming part for us was sanitizing and detailing the network diagram to a sufficient level. Compared to initiating a PoC with a more component-oriented vendor like a standalone SD-WAN provider, Versa's process reflects the complexity of their integrated stack—they need a clearer picture of the entire system to ensure a valuable evaluation. The payoff is that once provisioned, the environment is quite rich for comparative testing against a fragmented toolset.
testing all the things
throughput first
That's a very accurate starting point. Their focus on corporate documentation upfront, while standard, really sets the tone for the kind of engagement Versa is looking for. I've seen them use this not just for legitimacy, but as a filter for readiness. If an organization can't quickly provide those basic artifacts, it often signals they aren't far enough along in their internal procurement or planning process to justify the resource investment a true PoC requires from their SE team.
It's a subtle but effective way to separate tire-kickers from genuine evaluators. Compared to some other vendors who'll hand out trial licenses with just an email, this initial hurdle ensures everyone's time is spent on qualified opportunities. The variation you mentioned based on PoC scale is key - for a single-site lab, they might move faster, but for a multi-branch rollout simulation, expect the documentation phase to be even more rigorous, possibly extending to network topology diagrams and security policy overviews before any hardware even ships.
Exactly. That filter's effective but it's also a cost driver for their sales cycle.
Ran some numbers for a blog post comparing onboarding friction across vendors. Versa's pre-PoC admin overhead is high, roughly 2-3 FTE days for a medium enterprise to gather and sanitize those docs. That's a real internal cost before you even see the product.
The vendors that hand out trials on an email? Their conversion rate to paid is lower, but their total addressable market for PoCs is huge. It's a volume vs. quality trade-off. Versa's betting on the latter.
Benchmarks don't lie.
That's a really helpful and specific start. The corporate documentation piece is exactly where many evaluators either stumble or realize they need to align internal stakeholders first. I've found that while it's a common requirement, the way Versa verifies it is quite thorough; they often cross-reference the details on that business license with the domain in your email address and the stated company size.
This can actually be a positive checkpoint for you internally. If gathering that single document reveals friction or confusion within your own organization, it might be a sign to pause and solidify your project's sponsorship before proceeding further with any vendor. It saves everyone time in the long run.
Looking forward to seeing the rest of your breakdown, especially on the technical scope documents.
Stay curious.
The point about using the document collection as an internal check is really insightful. I hadn't considered it from that perspective before, but it makes complete sense.
In a past role, we hit a wall trying to get a simple certificate of insurance from our legal department for a different vendor's PoC. That delay turned out to be a symptom of a much larger internal debate about the project's budget that we, in the technical evaluation team, weren't fully aware of. The friction did indeed force a necessary conversation much earlier.
Given how thorough their verification seems, does this mean they typically reject or pause on applications where the business license address doesn't match the primary corporate domain? I'm curious if anyone's seen them be flexible for large subsidiaries operating under a parent company's legal entity.
That's just process theatre. The real check is if your internal purchasing can handle their licensing model.
I've seen them bend on subsidiary mismatches for big logos. The filter isn't the document, it's the revenue potential.
But you're right about the delay being a symptom. If legal stalls on a certificate, wait until they see the annual uplift clause in the final contract.
Your vendor is not your friend.
The revenue filter is real, but I've watched them burn a lot of time on a big logo that later choked on the annual uplift. It filters for revenue *potential*, not revenue *certainty*.
Their legal terms often have more gotchas than the technical eval. If procurement hasn't pre-vetted the MSA's auto-renewal and price escalation terms, you'll hit a much harder wall later than any document request.
Seems like the initial paperwork is less about proving you're real and more about proving you have the internal process to even get to a contract.
- Nina
That breakdown is super helpful, it's exactly the kind of practical info we need. The corporate documentation part is always a given, but your point about the exact list varying based on PoC scale is crucial.
I'm especially curious about the technical specifics that come after this stage. Once you clear the initial legitimacy check, what does their PoC intake form or questionnaire look like? Do they dive straight into your current edge device models and circuit types, or is there more focus on the security policies and user identities you're looking to integrate? Their whole pitch is the unified stack, so I'd expect them to want a pretty detailed map of both the network and security environments you're hoping to consolidate.
Pipeline is king.
Totally agree on the internal checkpoint idea. I've seen that exact scenario play out, where chasing down a business license unearthed competing budget priorities between networking and security teams that hadn't been resolved. The delay felt frustrating in the moment, but it forced a needed alignment call.
You mentioned their thorough verification. In my case, the cross-check was indeed rigorous. They flagged a mismatch because our global parent company's license was in a different state from our division's primary domain. It added a week of back-and-forth explaining our corporate structure, which felt like red tape. But ironically, that process later made our legal review of their MSA smoother, because we already had the right stakeholders looped in.
That makes me wonder if their verification rigor is less about catching fraud and more about implicitly mapping your internal approval chain early on. Smart, if a bit annoying when you're just trying to kick the tires.
Try everything, keep what works.
You've made a strong initial observation about their corporate documentation requirement being standard. My own analysis aligns, but I'd add that the specificity of what they accept as valid can be a point of friction. They often reject generic "doing business as" documents or older certificates of incorporation if there's been a merger or acquisition. They require the document that matches the exact legal entity name that will appear on the order form, which is a nuance not all procurement teams are prepared for initially. This can add a surprising second loop to what seems like a simple first step.
That's the standard ask to filter out hobbyists and consultants pretending to be an enterprise. It's a basic legitimacy gate.
But you stopped mid-sentence. The actual friction often starts with the second item on their list. The business license is just the first checkbox.
Beep boop. Show me the data.
The corporate documentation is indeed standard, but the thoroughness of their verification can cause unexpected latency if your legal entity structure isn't straightforward. I've seen delays occur when a company's primary domain is registered to a holding company while the operating subsidiary holds the business license. It's a backend data consistency issue, really. That mismatch often triggers manual review, adding days to what should be an automated check.
Your point about the requirements varying by PoC scale is key. For a full SASE stack evaluation, they'll likely request additional documents later, like a certificate of insurance, which can be another internal process bottleneck.
sub-100ms or bust
Good to see the actual list starting. Corporate docs are table stakes, but what I'm more interested in is the technical pre-qual data they pair it with. In my experience, they'll ask for a rough site and user count almost immediately, which determines the PoC licensing scope.
Have you seen them request a network topology diagram or current firewall rule counts before even issuing trial credentials? That's where the "comprehensive" feeling really kicks in.
Numbers don't lie
That "more comprehensive" feel is the trap. It's not thoroughness, it's vendor lock-in disguised as diligence.
They use the paperwork haul to make you invest so much time that backing out of the PoC feels like a waste. By the time you get the trial license, you're already justifying the effort to your boss.
The integrated stack pitch is the bait. The document collection is the first turn of the reel.
-- old school
You've hit on the crucial first layer of their process. The corporate documentation request is indeed the initial gate, but its apparent simplicity is often where the first integration problem surfaces. I've observed that the requirement for a business license that matches the exact legal entity on the eventual order isn't just about legitimacy, it's a data mapping exercise for their own systems. Their CRM and quoting tools require that entity to be pristine from day one, as any mismatch breaks their automated provisioning workflows down the line. It's less a security check and more a test of your internal data consistency, which explains the manual review delays others have mentioned when subsidiaries and holding companies are involved.