How I'd build the territory, run the motion, and prove it on a real account
"Six slides. The first three narrow down — ninety days, then the acts and who I say what to, then the fifty accounts and how they split with the SDR. Four is the message I arrive with, five is the competitive objection I'll get, and six is one real account worked end to end with the bits I'm guessing about labelled as guesses."
Segment note: this is Digital Natives, not the bank from the role play. Engineering-led buying, launch-driven compelling events, egress as a real line item. Do not reuse the banking framing.
N hides these notes · O overview · D layout check · F fullscreen
Pattern before action · hypothesis before outreach · disqualification before coverage
"I'd rather be slow for thirty days than wrong for ninety. The expensive mistake a new AE makes isn't being quiet in month one — it's burning twenty accounts in week two with a message built on an assumption nobody validated. Month one is pattern, month two is hypothesis, month three is the only part you can hold me to."
"The first two blocks are reversible — if the map's wrong I redo it, if the hypothesis is wrong the account leaves the list. The third isn't. That's the one I'd want to be measured on."
It's there on purpose. Security review and procurement are the two things that make a committed deal slip a quarter, and both start late by default. Starting them in month two is what makes the month-three forecast defensible rather than hopeful.
The act is chosen by the trigger, not by the size of the account. The angle is chosen by the seat.
| Act 1 · Core Web & Security Entry | Act 2 · SASE / Zero Trust Expansion | Act 3 · Workers / Edge Compute Entry | |
|---|---|---|---|
| Solutions | CDN, DNS, WAF, DDoS, Bot Management | Access, Gateway, Magic WAN, CASB | Workers, KV, R2, Vectorize, Workers AI |
| ICP | Massive web/mobile traffic · e-commerce, media, fintech, ticketing · heavy image, video and public API volume | 200–500+ office and remote staff · distributed or multi-site · heavy SaaS adoption. Arrives past ~300 employees, when someone inherits a VPN they did not choose | Digital-native or SaaS · engineering-heavy org · continuous deployment, API-first |
| Signals I can verify from outside | dig the apex and the API hostname — a first-gen CDN CNAME is a dated renewal, a bare origin IP is an exposed origin · status-page incident history · public post-mortems | Job posts naming a specific VPN or firewall vendor · an acquisition (two directory estates) · a new office or market · an announced ISO 27001 / SOC 2 programme | GitHub and engineering blog — runtime, framework, deploy cadence · platform and SRE job posts · a published latency or cost problem · an announced AI feature with no stated inference infrastructure |
| Compelling event | A launch, a seasonal peak, an incident post-mortem, a cloud bill review | A VPN or firewall renewal, an audit finding, a headcount jump | A latency SLO miss, a new market launch, an AI feature on the roadmap |
| VP Infrastructure · Head of Web Ops | Origin load and what peak events cost |
| CISO · Head of Security | Bots, account takeover, client-side script exposure |
| E-commerce Director | Conversion measured against latency, on their funnel |
| Head of Platform · SRE | Incident surface and time to mitigate a new vector |
| CISO | Contractor and third-party access, and the audit finding about it |
| VP IT · Head of Enterprise Network | The concentrator as a single point of failure; licences per seat on a workforce that moved |
| CIO | Four consoles, four renewals, one control plane |
| Head of Compliance | Evidence assembled per audit cycle, across how many vendors |
| CTO · VP Engineering | Engineering time spent on infrastructure instead of product |
| Chief Architect | Removing a tier from the architecture, not adding one |
| Head of Product · Growth | The latency SLO, and the market launch it gates |
| VP Finance · FP&A | Egress as a line item; what the cloud bill does as traffic grows |
| Existing free-tier user in the account | Internal referrer — the warmest path in the building |
"The three acts aren't equally likely in digital natives. One and three are the entries — the buyer is technical, the pain is latency or spend, and they'll try the free tier before they take a meeting. Two is the expansion act here, not the way in. I'd rather tell you I've modelled that than hand you a matrix I inherited."
"And the bottom half is the bit that actually gets replies. The same job title cares about different things depending on which act you're in — a CISO in Act 1 is thinking about bots, a CISO in Act 2 is thinking about who still has VPN access after their contract ended. Same person, two completely different emails."
"Bottom right. In digital natives somebody in the engineering org is almost always already on the free tier. Finding that person converts a cold account into a warm one, and it costs one search."
If there's a laptop in the room, offer to run a lookup live. Four seconds, free, and almost no candidate does it.
Because 80% of the revenue will come from 20% of the book — so the tiering has to be right before the cadence starts
| Cloud spend | Current and projected on AWS, Azure, GCP |
| Hands-on-keys (HOKs) | How many DevOps, SREs, cloud engineers and developers |
| Cloud Center of Excellence | Does one exist, and how centralised is the cloud strategy |
| $1M ARR potential | Reasonable probability of passing $1M inside 18 months |
| Tier | Profile | Strategy |
|---|---|---|
| 5–10 Tier 1 · 10–20% |
Meets most of the four variables — high cloud spend, a large HOK team, a CCoE, and a credible path past $1M ARR | Maximum personalisation and exhaustive contact mapping. Broken down by business unit or product line, not treated as one entity — intensive multi-threading, because in an account this size the buying centre is a BU, not the company |
| 15–20 Tier 2 · 30–40% |
Good growth potential, modern infrastructure, or an identified migration or modernisation project — without Tier 1 scale or immediate certainty | Structured sprints. Phased prospecting with a cadence of at least 7 touches across 2 weeks per contact set. Promoted to Tier 1 the moment a dated trigger and a $1M path both appear |
| 20–25 Tier 3 · 40–50% |
Smaller stack, limited visibility of spend, no immediate signal of pain or an active project | Nurture and blitz. Cold-call blitzes outside the priority sprints, semi-automated sequences, and the nurturing cadence — waiting for an intent signal, a trigger or an inbound lead rather than manufacturing urgency |
"Fifty accounts, but I'm not going to pretend I'll work them evenly. Eighty per cent of the revenue comes from about twenty per cent of the book, so Tier 1 is capped at five to ten accounts and it gets disproportionate time. Spreading effort evenly across fifty accounts is the most common way to miss a number while looking extremely busy."
"Cloud spend tells me whether there's budget. HOK count tells me whether there's anyone to sell to — in this segment the practitioner is the buyer. A Cloud Center of Excellence tells me whether a decision can be made centrally or I'm selling to eleven teams. And the $1M path tells me whether it's worth a Tier 1 slot at all."
"Tier 1 accounts get broken down by business unit, not treated as one account. At that size the buying centre is a BU with its own stack and its own budget — selling to 'the company' is how you end up with one champion and no deal."
This is the tiering discipline from my current playbook, adapted. Worth saying — it shows the method is practised rather than invented for the interview.
Being honest about capacity: four live accounts for me, four for the SDR. Everything else is nurture.
| Account | Week 1 | Week 2 | Week 3 | Week 4 |
|---|---|---|---|---|
| A1 Tier 1 · BU split | 8 · 8 | 8 · 8 | 8 · 8 | |
| A2 Tier 1 · BU split | 8 · 8 | 8 · 8 | 8 · 8 | |
| A3 Tier 2 | 8 · 8 | 8 · 8 | 8 · 8 | |
| A4 Tier 2 | 8 · 8 | 8 · 8 | 8 · 8 | |
| Touches / week · mine | 16 | 32 | 32 | 24 |
| + SDR, same shape | 16 | 32 | 32 | 24 |
| Who | Seats |
|---|---|
| The SDR | HOK and HOK+ — DevOps, SRE, cloud and platform engineers, and the leads above them. They are closest to the pain and they answer technical questions |
| Me | Buyers and executives — CTO, VP Engineering, Chief Architect, Finance. Plus the business case and MEDDPICC in every account |
| The SDR, full cycle | Two accounts, start to finish. Their own discovery, their own next steps, with me in the room but not leading — because the fastest way to get an SDR promoted is to let them run something, and the fastest way to lose one is not to |
| Nurturing cadence | Playbooks, best practices, relevant events, market news and competitive moves — sent to the whole book, not just the live sprints. It keeps Tier 3 warm at near-zero cost and it is the reason a Tier 3 account picks up the phone when its trigger finally lands |
| Channel | The 3–5 integrators already working my accounts, plus opening new partners where there is a gap. A partner who can name my accounts is worth more than a directory listing |
| Hyperscaler alliances | Partner managers, to find committed cloud spend — marketplace transaction shortens procurement materially |
"Four live accounts at a time. Not fifteen — four. Eight contacts each, three touches per contact, twenty-four touches per account across a three-week sprint. Four of mine and four of the SDR's means eight accounts genuinely in motion in any given week, and the grid staggers so a sprint finishes before the next pair starts. I'd rather tell you a number I can actually hit than one that sounds impressive in an interview."
Four concurrent accounts on rolling three-week sprints is roughly 17 sprints a quarter for me and 17 for the SDR — about 34 of the 50 worked properly per quarter, with Tier 1 taking repeat sprints. The rest sit in nurture until a trigger lands. That is a book that gets covered, not a book that gets listed.
"The SDR works hands-on-keys and the layer just above. They're closer to the pain and they can hold a technical conversation. I work buyers and executives, and I carry the business case. Where we'd overlap is Tier 1, so there the split is named per contact and written down."
"I'd also hand the SDR two accounts to run end to end, with me in the room but not leading. Partly it builds the pipeline, mostly it builds them. The fastest way to get an SDR promoted is to let them run something; the fastest way to lose one is to never let them."
"Nurture — and I mean a real cadence, not a dormant list. Playbooks, best practices, events, market news, competitive moves. It costs almost nothing and it's the reason a Tier 3 account takes the call when its trigger finally shows up."
Current state → Cloudflare advantage → future state
1. Say Cloudflare "supports" the PCI DSS requirements. Never "guarantees compliance" — no vendor guarantees a customer's compliance, and that single word is a mark-down.
2. Keep numbers and company names apart. The −45% latency figure is from the Forrester TEI study, not from Garmin. A study figure attached to a customer name is an error a technical buyer catches.
3. Attribute and date the latency/conversion stat. "Amazon found in 2006 that 100ms cost about 1% of sales — what's your version of that number?" is a discovery question. The same stat delivered bare invites a correction.
"This is deliberately the Act 1 and Act 3 story — there's no Zero Trust on it. In digital natives, Act 2 is the expansion motion rather than the entry. I've got the one-slide Act 2 version if you want it."
Current-state metrics · named proof, qualitative only · modelled ranges labelled as modelled
| TTFB and LCP Public and measurable before the call. Measure it and bring it. |
| Monthly egress spend, $/TB Ask for the cloud bill line. This is the one hard number per account. |
| % of requests that are bots They often don't know. Not knowing is the finding. |
| Time to remediate a new attack vector Tells you whether security is automated or heroic. |
| ↑ Conversion and LTV through speed · ↓ TCO through consolidation and egress removal |
| ↑ Uptime, on a 100% availability SLA (Enterprise) |
| ↓ Client-side exposure, supporting the PCI DSS 4.0 client-side script requirements |
| Shopify "Cloudflare helps us find a simple way to achieve something very complex that we can scale and maintain." — Duncan Davidson, VP Developer Productivity |
| Canva — global media delivery and availability under sustained load |
| Discord — bandwidth and protection at volume |
| Garmin — API delivery and attack mitigation |
| Anthropic · OpenAI · Stripe · Character.AI · CoreWeave The AI-native cohort — relevant to any Act 3 conversation |
| Latency / TTFB | −30% to −50% |
| Egress on assets moved to R2 | $0 contractual, not modelled |
| Automated abuse blocked | >99% |
| TCO via consolidation | −35% to −50% |
| Core Web Vitals | measured on their own RUM |
The weakest content in any value framework is the unsourced percentage. Labelling the block as BVA model output and saying the "we'd build yours" line converts the weakest part of the deck into the next step — and demonstrates exactly the rigour the interviewer is listening for.
The $0 egress row is a pricing fact, not a model output. State it flatly.
What changes for the customer · what I circulate to the team · where we lose and where we fit
| 1 · Cost stops scaling with revenue Data egress from $0.09/GB to $0. At 10 TB/month that is $10,800 a year eliminated — not renegotiated |
| 2 · Billed for compute, not for waiting Where the architecture depends on third-party APIs, the hyperscaler bills wall-clock time. Cloudflare bills CPU only |
| 3 · Demand peaks without capacity planning No pre-warmed instances, no commitments. A 50% fall in traffic still carries 100% of the reserved-capacity cost |
| 4 · Geographic expansion without an infrastructure project One deployment, presence in 348 cities. No region selection |
| 5 · The API entry toll is eliminated ~$2,100 a year at 50M requests/month on API Gateway REST. Not a lower rate — the cost line does not exist |
|
1 · "How many GB left your cloud last month, and what did you pay for them?" Why — a figure they usually do not have to hand Lever — direct quantification of the saving |
|
2 · "Of the milliseconds billed on your most-invoked function, how many are compute and how many are waiting on a provider?" Why — an un-instrumented metric. Exposes the cost of billed waiting Lever — billed on compute, not on the clock. A structural asymmetry, not a discount |
|
3 · "How much capacity do you hold for peak, and what happens to that bill on the days there is no peak?" Why — reveals permanent over-provisioning and live commitments Lever — no provisioning, no commitment. Qualifies the timing |
|
4 · "When you open a new market, how long until the infrastructure is live, and who deploys it?" Why — puts the platform on the critical path of the commercial roadmap Lever — one deployment, global reach. Expansion without a project |
|
5 · "How many people spend time on infrastructure in a normal week, and what would they have built instead?" Why — converts infrastructure cost into opportunity cost Lever — TCO across four dimensions. The saving sits outside the invoice |
| Where the hyperscaler wins Compute-intensive, predictable volume — reserved capacity beats usage billing · Deep AWS integration — SQS, SNS, Step Functions, DynamoDB Streams, IAM: rewrite cost can exceed savings · GPU for ML training — Workers AI is inference, not training · Databases past 10 GB — D1's cap means sharding |
| Where we fit — pattern, then proof |
| A new market opens a regional deployment cycle → Workers + Durable Objects · Baselime $1,940→$325/day, −83%, three engineers, under three months |
| Peak sizing carried permanently → Workers + KV · DevCycle 10× deploy spikes, no reserved EC2 |
| Real-time needs four services assembled → Durable Objects · Kaizen Gaming 600,000→1,000 origin connections, 300 servers removed, bandwidth −90% |
| Enterprise onboarding burns DevOps on SSL → Cloudflare for SaaS · HubSpot 47,000 sites in 5 days, provisioning 5 days → 90 seconds |
| Engineering capacity lost to deploy windows → Durable Objects with hibernation · Liveblocks 500M messages/24h with 10 engineers |
Left and right are client-safe. The middle column is internal — if you are screen-sharing with a customer, do not show this slide; use the left column verbally and keep the questions in your head.
It is true of I/O-bound functions calling third-party APIs and false of CPU-bound ones, so never state it as a universal. The safe form: "in architectures like yours — mostly third-party API calls — it tends to run around ninety per cent. What does yours look like?" That converts a claim you'd have to defend into a question they have to answer, and the answer is the quantification.
And the source's own warning, worth knowing: "the difference between 5ms of CPU and 500ms of elapsed time identifies a promising candidate; it is not itself a price ratio." So use it to qualify, not to price.
"This is from an independent architecture book, not our marketing — the author has a chapter called 'When Not to Use Cloudflare' and I read that one twice."
Bring it out the moment a technical interviewer starts testing you. Volunteering where Cloudflare loses converts you from a vendor into an advisor in about one sentence — and it's the most reusable thing in this deck.
Four dimensions: infrastructure, development, operational, maintenance. Cloudflare's advantage shows most clearly in development and operational — so the honest argument is the opposite of column 1: the strongest case is rarely the monthly bill. The arithmetic that sets the floor: $500/month saved against a $50,000 migration is eight years to break even.
~95% of bookings and ~90% of expense reports run with zero human touch. Availability and latency gate revenue directly.
| Q2 this year | $250M credit facility — a four-lender private credit syndicate. Earmarked for product, AI and the US spend launch |
| Q3 this year | MCP with write actions, GA — mainstream AI assistants book travel, submit expenses and create events for ~11,000 customers. Agentic write access to a financial system |
| Sept, this year | Spend product launches in a second major market — combined travel + spend, bring-your-own-card. that market already ~30% of new business globally; in Europe up to 40% of new deals are the combined product |
| Q3 this year | Hostpay partnership — account-to-account rails replace virtual cards for hotel payments, with settlement SLAs |
| Announced | A corporate charge card in that market — spend controls, cashback, global payments. A third regulated money-movement workload |
| Last quarter | Hotels at 98.0% uptime vs 100% everywhere else — highest-volume component, and the one Hostpay lands on |
"Ninety-five per cent of bookings and ninety per cent of expense reports run with no human in them. The platform isn’t supporting the business — the platform is the business. Which means availability and latency aren’t an engineering concern, they’re a revenue concern, and that changes who I can have the conversation with."
"Their hotels component is the only one not at a hundred per cent, and it’s the one they’re landing new payment rails on. That’s one conversation, not two."
Tier 1 on all four variables — multi-cloud spend, ~850 HOKs in Barcelona, a platform decision-maker functioning as a CCoE, and a clear path past $1M. So it gets the BU-level breakdown and repeat sprints, not a single pass.
Company name, individuals, partners and precise figures changed or rounded. Say so if asked — showing you anonymise a live account before publishing it is a professional signal, not a weakness. In the room: "it’s a real account in my patch, anonymised in the written version."
Each angle comes from something they published themselves · MEDDPICC, with paper process running in parallel from day one
| Who · what we know | The angle, and the act behind it |
|---|---|
| Tomás Herrero Staff SWE, Foundations. Published their MTTR target and the miss Entry |
"You published a 30-minute MTTR target and you're at 31. How much of that is deploy and how much is diagnosis?" Act 3 — rollback by routing. Their CI pipeline rollback P95 is just under four minutes; ours is seconds. He wrote the article, so the number is his, not mine |
| Daniel Roth SVP Strategic Finance. $250M of new debt; margin 40s → ~70% |
"You're expanding margin on borrowed capital. Can I audit three lines — inter-cloud egress, the API toll, and billed waiting time?" Act 3 — R2 and CPU billing. Multi-cloud AWS+GCP makes inter-cloud egress the one case with no counter-argument |
| Lena Vasquez President Product & Technology. Shipped MCP write access to ~11,000 customers The deal |
"Your MCP now has private data, untrusted content and write capability in one system. Who authorises an agent to move money, and where is that logged?" Act 1 + Act 3 — AI Gateway for model-spend governance and agent control. Single platform decision-maker |
| Security & Compliance Unworked. an EU e-invoicing mandate in force; US payments live; a charge card coming Opens first |
"Three regulated money-movement workloads shipped in six months. What does the audit trail for an agent-initiated payment look like?" Act 1 — enter via MCP action audit, not data residency: residency is a crowded conversation they already have answers for |
| Element | Action |
|---|---|
| Decision process · Economic buyer | London or Barcelona? Any unexpired AWS reserved commitments? Nothing else starts until both are answered |
| Paper process · Compliance Runs in parallel from day one | Security questionnaire, DPA and marketplace route opened at the start, in parallel with discovery — not at the end. Test whether an existing cloud commit can carry the transaction. This is the single thing that makes a committed deal slip a quarter |
| Identify pain · Champion | Technical entry on the published MTTR. Find the free-tier user inside engineering and make them the internal referrer |
| Metrics | Quantify in ranges, never point estimates. Below ~$30,000/yr identified, the account leaves the priority list — no migration pays back inside a fundable horizon |
| Decision criteria | AI Gateway and agent governance to Lena Vasquez. Kept out of the cost conversation entirely |
| Competition · Close | Bounded test on the hotels component, success criteria written before it starts. Security already cleared, so the only remaining variable is the result |
"The plan is MEDDPICC, and the one thing I've changed is where compliance sits. Paper process and the security review start at the beginning, in parallel with discovery — not at the end. Three regulated money-movement workloads in six months means their security team is already the busiest group in the building. If I open that thread late, the deal is technically won and commercially slipped a quarter. Opening it first costs me nothing and protects the close date."
"Before you ask whether this is even my account: the group HQ moved outside Iberia last year, and the Salesforce record only says VIAPERQZ, S.L.U. because that's the Spanish legal entity. What keeps it in my patch is that the buying centre for a platform decision is the engineering organisation, and around eight hundred and fifty of them sit in Barcelona — their largest engineering hub. But I'd rather be straight: if Lena Vasquez makes this call from London, this is a co-sell with the neighbouring team and I'd propose that in week one rather than discover it in week six."
"I'm not going to suggest you move off DynamoDB. If you're using Streams and IAM the way most teams at your scale are, the rewrite outruns the saving and I'd be wasting your time. What I'd put in front of it is a layer — your ECS and Dynamo stay exactly where they are."
Related constraints to have ready: D1 caps at 10 GB per database, and Workers AI is inference, not training.
"Not their product engineers — and the reason is our own gap. No production debugger, no flame graphs, and automatic tracing doesn't cross service bindings or Durable Objects. They'd find that in the first hour. I use them as validators once the platform conversation is live, never as the way in."
"They're mounting new settlement rails on the only component that isn't at 100%. That's from their own status page, and it's impossible to answer with 'we're fine.'"
Metrics, decision criteria, decision process, paper process and champion are all unknown today — the table is the plan for filling them, not a claim that they're filled. A full MEDDPICC on an account nobody has spoken to says you fill fields in rather than qualify them.
Tier 1 on all four variables — multi-cloud spend, ~900 HOKs in Barcelona, a platform decision-maker who functions as a CCoE, and a clear path past $1M. So it gets the BU-level breakdown and repeat sprints, not a single pass.