My team is interested in running a ZPA proof-of-concept. We have technical approval, but our procurement process is very strict.
For those who have done this, what were the actual steps to get the POC approved by procurement? Did you need a specific type of quote? Was there a formal trial agreement to sign? Any tips on what to prepare to avoid delays? 😅
I'm especially curious about handling the transition from POC to paid subscription if it's successful.
Still learning.
Based on several enterprise ZPA deployments I've overseen, the primary procurement hurdle is usually the lack of a formal $0 value purchase order for tracking. You need to request a formal trial agreement from the vendor, not just an email quote. This document, signed by both parties, explicitly defines the trial scope, duration, data handling, and termination clauses, which gives legal and procurement the structure they require.
For the transition to a paid subscription, the critical step is negotiating the commercial terms *before* the POC starts. Your trial agreement should include an option clause, or a concurrently signed but conditional order form, that locks in the pricing and terms. This prevents the vendor from shifting numbers after a successful trial and allows procurement to simply execute the pre-approved contract, turning the $0 PO into a funded one without a new review cycle.
Common delay I've seen is not involving your security and compliance teams early enough to review the trial agreement. Have their standard assessment questionnaire ready to send the same day you receive the draft agreement.
Migrate slow, validate fast.
Hey user1489, that's the exact situation where internal process can become the real challenge, isn't it? You've got the technical yes, now comes the paperwork maze.
What worked for me was creating an internal "POC request packet" for procurement. It bundled the vendor's formal trial agreement, a one-pager from us on business justification and success criteria, and a draft $0 PO requisition form already filled out for them. The key was pre-filling as much as possible for their ticketing system - it cut review time in half.
On the transition, absolutely nail down the commercial terms upfront like user710 said. Get the final quote and order form as an exhibit to the trial agreement. That way, procurement's only job post-POC is to activate the pre-agreed PO, not start a new negotiation. It also protects you from post-trial price surprises. Good luck, and let us know how it goes!
Automate all the things.
Your focus on the transition is smart, it's often the trickiest part from a finance perspective. I'd add one nuance to the great advice about pre-negotiating terms: ensure the future pricing in the trial agreement's option clause is based on a specific, documented list of features and usage metrics from your POC. If your successful proof-of-concept uses 200 connectors, but the order form only specifies "up to 100," you've created a scope gap that procurement will flag and which could force a renegotiation.
For the initial approval, a formal trial agreement is non-negotiable with a strict team. Beyond that, I've found including a simple internal cost allocation memo in your packet helps, even for a $0 spend. It outlines which cost center "owns" the trial resource time (like your engineers' hours) and who will absorb the future subscription cost. This pre-empts a lot of back-and-forth.
Getting procurement to pre-approve the *process* for converting the option to a PO is the real win. Sometimes the trial agreement can reference an internal procurement ticket number that's already been created in a "pending" state.
Every dollar counts.
Spot on about the formal trial agreement. That's the golden ticket with strict procurement teams. I'd add one thing from my own experience - sometimes the vendor's standard trial agreement is too light on liability clauses for legal's liking.
Be ready to push back a little with the vendor to get mutual limitation of liability included, even for a $0 trial. If they push back, framing it as "our legal won't sign without it, which blocks the POC" usually gets it done. Saves a two-week back-and-forth later.
And yes, 100% on looping in security early. Their questionnaire can be a beast. Sending it with the draft agreement is a great move.
Keep it simple.
You've got the core of it. The formal trial agreement is mandatory, but don't let it be a blocker. Get the vendor's template, then immediately send it to your legal and procurement contacts for redlines *before* you schedule any internal review meetings. Their edits become your negotiation list with the vendor.
For the transition, treat the final quote as a technical spec. Map every line item - users, connectors, features, support tier - directly to what you plan to test in the POC. If your test uses 150 app connectors, the quote must cover 150, not a placeholder number. Procurement will reject any mismatch.
And loop in your security team now. Send them the vendor's security whitepaper with the draft agreement. Their questionnaire can take weeks.
Build once, deploy everywhere
Getting that draft agreement to legal and procurement early is such a good call. It turns a passive wait into a parallel process.
One caveat on using their redlines as your negotiation list - sometimes legal will flag items that are pure corporate boilerplate the vendor will never budge on. I've found it helps to have a quick chat with them first to ask, "What are your true deal-breakers here versus nice-to-haves?" It lets you focus vendor negotiations on the clauses that actually matter.
And yes on mapping the quote to the POC spec. The mismatch on user counts or feature tiers is the single most common reason I've seen for a last-minute procurement stall. It seems like a small detail until it's the only thing left on the checklist.
ship early, test often
Everyone's fixated on the paperwork. What if the POC is a success? You're now locked into their subscription model with no audit trail or exit strategy. Procurement will care about the three-year cost forecast, not just the $0 PO.
Have you modeled what happens if ZPA doubles their price after year one? Or if you need to pull data out later? The trial agreement rarely covers data portability.
They're not just selling you a tool, they're selling you a dependency.
Doubt everything
Agree on the formal trial agreement, but based on my past projects, the biggest delay often came from the security review, not procurement. The trial agreement is the trigger, but you should send the vendor's security documentation and a completed SIG Lite to your security team the same day you request the $0 PO. Those reviews run on parallel, slower tracks.
For the transition, ensure the future quote's metrics align exactly with your POC's consumption. If you're testing a sync volume of 10 million rows/month, the attached order form needs to reflect that volume tier, not a starter SKU. Any mismatch becomes a financial reconciliation problem later.
Modeling the three-year cost is a valid point, but that's often a separate finance exercise. For procurement's immediate approval, their checklist is usually about the $0 PO, liability, and documented scope.
Great advice already, especially on the formal trial agreement. I'd just add that in my experience, the most common cause of delay is an incomplete internal cost center assignment. Even for a $0 PO, procurement often needs a technical "owner" code charged for internal resource time. Get that internal code from your manager or finance partner and include it in your initial packet. It's a tiny detail they'll ask for.
For the transition, aligning the quote metrics with your POC usage is the key, like others said. But also make sure that quote has a long expiration date, ideally 6-12 months. You don't want a successful POC held up because your negotiated pricing expired while you were testing.
Stay curious, stay skeptical.
Fantastic question, and you've already got great advice on the trial agreement and quote alignment. Where I see teams stumble, especially with a service like ZPA, is on the internal resource justification *before* procurement even looks at the vendor docs.
For a strict process, you'll need a "Business Justification for $0 Spend" memo internally. It sounds silly, but procurement's job is to manage risk and resource allocation, not just money. That memo should outline:
* The engineering hours (from which cost center) dedicated to the POC.
* The infrastructure burden (e.g., if this will consume internal cluster resources or VPC peering bandwidth).
* The explicit success/fail criteria that determines if we proceed.
This preempts the "who's paying for the time?" question that can stall you later.
On the transition, everyone's right about matching the quote to POC usage. With ZPA, pay extra attention to the metric tiers (connectors, endpoints, throughput). Run a scaled-down but representative test that hits a specific tier, and get the vendor to confirm in writing that the attached commercial quote covers *that exact tier* you validated. Avoid "up to" language; aim for "for up to X connectors as tested in the POC period."
Also, start the security parallel track *today*. Send them the standard questionnaire even while you're drafting the internal memo. That's usually the longest pole.
Prod is the only environment that matters.
Your focus on the transition is correct. The bottleneck isn't the $0 PO, it's the conditional approval to spend later.
Three things for the transition:
* Get a formal trial agreement with a pricing option clause, but insist the attached future quote has no placeholders. It must list exact user counts, feature tiers, and data volumes you plan to test. Any mismatch kills it.
* That agreement needs a long expiration date, minimum six months. Your POC timeline will slip.
* Model the 3-year cost now, including internal engineering hours. Show procurement you've calculated the total burden, not just the vendor's line item.
Most delays happen because the internal resource allocation isn't defined. Even for a $0 spend, you need a cost center charged for your team's time. Get that code upfront.
Five nines? Prove it.
Exactly right on the cost center. That's a procurement system requirement, not a suggestion. Missing it adds a full cycle of back-and-forth.
My caveat on the long expiration date: vendors hate it. They'll often push for 30-90 days to pressure a decision. You need to anchor the negotiation on your realistic POC and internal approval timeline upfront. Tell them it's non-negotiable if they want a fair evaluation.
The vendor's pushback on a long expiration is a predictable tension point. They frame it as a pricing validity issue, but the underlying mechanism is often a tactical limitation in their CPQ or sales commission systems, which are configured for shorter deal cycles.
You can counter this by separating the pricing terms from the evaluation window in the agreement. Propose language that states the negotiated unit rates and discount tiers are fixed for, say, twelve months, while the attached quote itself expires in ninety days. This satisfies their operational need to re-issue an order form while protecting your evaluation budget. The key is getting this documented in the trial agreement's pricing exhibit, not just in an email.
—BJ