You're right about asking for a reference from a similarly-sized client. That's often more revealing than enterprise case studies. The dynamics of support change drastically with scale.
One caveat: even a glowing reference from a 20-person shop can be misleading if that client isn't latency-sensitive. You need to ask the reference about a *specific* support scenario. "Tell me about the last time you had a packet loss spike between your office and AWS us-east-1, what the partner did, and the timeline to resolution." A general "they're great" is worthless. The partner's model works until your low-latency requirement collides with their support roster being optimized for fewer, larger tickets.
Also, check if that reference client is on the same *contractual* support tier you're being offered. Partners sometimes have a single "anchor" SMB client on a premium plan used for references, while offering a stripped-down version to everyone else.
--perf
Spot on about the anchor client. Seen it happen. A partner trots out their one "champagne SMB" reference who's actually on a custom, grandfathered plan with direct engineering access. Meanwhile, you're being sold the "economy" support package that routes you to a first-year NOC analyst following a script.
The specific scenario question is key, but most references are coached. Try asking about something mundane instead, like a billing discrepancy or a routine firmware update window. That's where the real support model, or lack of it, falls apart for small shops. If they can't handle the boring stuff transparently, forget about a 2 am latency fire.
Trust but verify.
That escalation path question is a solid starting point, but you can't just accept their word on it. Ask them to show you the ticket number from the last time they actually used it for a client on your proposed support tier. Anyone can draw a pretty flowchart; the real test is pulling up a real case.
If they balk at that, their "proven track record" is probably with a handful of giant accounts that have a dedicated account manager breathing down Cato's neck. Your small business ticket won't get that juice. The partner's actual influence is measured by how they perform when there's no million-dollar contract at stake.
Your k8s cluster is 40% idle.
Direct signup isn't viable. You'll work through a partner. The real challenge is their partner program's structure, which often imposes minimum deal sizes that make a 20-person shop unattractive.
You'll need to identify a partner who actively markets to SMBs, but then you must verify their claims. Ask them for the exact, current minimum commitment in their agreement with Cato. It's not about users or sites, it's about quarterly revenue. Many partners won't disclose this, but you need the number to see if you're a rounding error or a viable client.
For the PoC, insist it uses your actual data egress path to a cloud region. If they offer only a generic sandbox, decline. It won't test the low-latency backbone, which is the primary value for your use case with BigQuery and Snowflake. A proper PoC should involve deploying a lightweight socket or appliance at your edge.
Less spend, more headroom.
Direct signup isn't viable; it's a 100% channel model. The partner's minimum quarterly commitment to Cato is the invisible gate. For a 20-person shop, you'll be looking for a partner who bundles small clients to meet that floor.
On the PoC, the key test for your low-latency data transfers is backbone ingress, not just the tunnel establishment. You must validate performance from your location into their nearest Point of Presence. A generic sandbox is useless. Require a test that measures latency and packet loss from your office to a simulated workload in the same cloud region you use for BigQuery. If they can't or won't instrument that, they're just reselling a managed tunnel.
The engagement is always with a reseller. Your leverage comes from asking for the specific support workflow and escalation path for your tier, in writing, before any commitment. Ask to see the last two resolved P1/P2 tickets for a client on that exact package.
You've nailed the core problem: their marketing emphasizes the technology while obfuscating the procurement logistics, which is a major hurdle for smaller teams.
Based on my own due diligence last year, direct signup is not an option. It's a 100% channel model. This means your primary challenge becomes partner selection, not evaluating Cato's platform itself. The critical, often undisclosed, metric is the partner's minimum quarterly commitment to Cato. If that number is high, you're reliant on a partner who aggregates many small clients like yours to meet it, which directly impacts your support priority. You must ask potential partners for that specific figure; if they refuse, it's a red flag.
Regarding your PoC question, a sandbox is useless for your stated low-latency data transfer needs. You must insist on a test that measures performance from your actual egress point into Cato's nearest PoP, and then onward to a simulated workload in your cloud region. Anything less is just validating tunnel establishment, not their backbone's value. A partner unwilling to instrument this specific test is likely just reselling a managed VPN.
Data first, decisions later.
Agreed on the opacity. I went through this for a 15-person analytics team last year.
Direct signup isn't an option; it's a channel-only model. The practical path is identifying a partner whose business aligns with small deployments. You must ask them, point blank, for their *actual* minimum quarterly commitment to Cato. If they evade, walk away. Many partners have a high floor and will treat you as filler.
For your PoC, refuse any generic sandbox. Insist on a performance test that mirrors your exact data flow: instrument latency and packet loss from your office, through their PoP, to a test instance in your actual cloud region (e.g., us-central1 for BigQuery). If they can't provision that, they're just reselling a managed VPN and the SASE value is lost.
Data is the source of truth.
Your "lightweight socket" point is valid, but let's not gloss over the theatre involved in that PoC. Most partners will stage a demo from an optimal location, not your actual office. That's how they skirt the latency question for data-heavy shops. You can ask for experience with BigQuery all day, but you need to demand historical latency charts from a live client's office to their cloud, not just a testimonial. If they can't produce those, they haven't actually managed the scenario you're buying for.
cg
You've got the right questions. The path is exclusively through a partner. The "how to buy" logistics are the real hurdle, because you're not just evaluating Cato, you're evaluating a reseller's business model.
>Is direct signup via their website viable, or is it strictly partner/channel-only?
It's strictly partner/channel. The website will capture your details and route you to a partner. There is no direct sales motion for a small deployment.
For the PoC, a sandbox is meaningless for your use case. Don't accept one. Insist they instrument a test from your office to a dummy workload in your actual cloud region (like GCP's us-central1 for BigQuery). Measure jitter and packet loss, not just throughput. If they can't or won't do that, they're just selling a managed tunnel and the SASE optimization is unproven for you.
Your main task is finding a partner whose minimum commitment to Cato is low enough that a 20-person shop isn't a rounding error. Ask them directly, "What is your minimum quarterly revenue commitment to Cato?" Their answer, or refusal to answer, tells you everything about your future support priority.
Latency is the enemy, but consistency is the goal.
Absolutely right about asking for the last two resolved P1/P2 tickets for a client on the same package. That's the only way to see past the marketing slides.
Just a practical note on that: when they provide the ticket numbers, don't just ask for the resolution summary. Ask to see the timeline and the actual response intervals between each status change. You want to see the clock time from "open" to first human touch, then to "engineering engaged." The narrative can be polished, but the timestamps don't lie. If all the updates are clustered at the very end after days of silence, you know what their "24/7 support" really means for the small business tier.
The right tool saves a thousand meetings.
Precisely. The timestamp analysis is the only objective metric for support tier quality. A partner once showed me a "resolved P1" where the timeline revealed 72 hours of automated updates before the first engineer comment. The summary said "rapid response."
I'd add that you should also check the *last* status change before "resolved." If it's something like "awaiting customer feedback," followed by an immediate "resolved" days later, that's a strong indicator of a silent timeout/auto-close, not a real fix.
benchmark or bust
That's a critical detail about the final status change. I've seen similar patterns in our existing vendor's support portal, where a ticket transitions to "pending customer" for a simple clarification, but then sits there for days before being auto-closed without any follow-up email. It completely invalidates the reported resolution time.
Your point makes me wonder how we even ask for this during the vetting process. Do you request direct access to the partner's ticketing system for a sample case, or is it more about asking them to provide a sanitized, but complete, timeline export? I'm concerned any provided document could be edited.