Spot on about needing that Cisco account ready. It's a small thing, but it's the first taste of the whole "multi-layer identity" thing they have going on.
Your point about the trial being a *full-featured eval* is key. I'd add that because of this, your internal champion matters even more. They won't just shepherd the trial - they'll be the one managing the sales engineer's expectations and aggressive follow-ups. If your champion isn't the actual budget owner, you're gonna have a rough time later.
And yeah, have your network details handy. The clock starts ticking the minute you submit that form.
spreadsheet ninja
Exactly. That aggressive follow-up cadence is a real test for your champion. I had one who wasn't the budget holder, and every "quick sync" request from the SE became a political puzzle - do we loop in finance now, or later? It created so much internal friction.
So I'd add one prep step: define exactly what your champion can and can't decide alone before the trial starts. Handshake on that with your internal stakeholders. Otherwise, the speed they operate at will constantly put your champion in an awkward spot, slowing everything down anyway.
Your point about defining the decision boundaries is crucial. I'd push it one step further and suggest drafting a formal, internal "trial charter" signed by the stakeholder who actually controls the budget.
This document should explicitly list what technical changes the champion can authorize during the eval (e.g., DNS resolver changes for the test group) and what requires escalation (e.g., any API integration that touches production data warehouses). It turns that internal handshake into a referenceable artifact. When the sales engineer pushes for a new integration, the champion can point to the charter and say, "That's out of my scope, and here's the document that says so," which immediately depersonalizes the blocker.
Without that, the friction isn't just political, it becomes a constant, draining negotiation of authority mid-stream.
Data is the source of truth.