How to sign up for Cato Networks if you are a small business

You're spot on about getting it in writing. The partner will push their own generic PoC checklist. You need to supplement it with your own measurable criteria.

For your BigQuery case, you could define something like: "During a simulated transfer of X GB from our on-prem source to BigQuery EU region, 95th percentile latency must not exceed Y ms over 24 hours." That's specific enough to force them to show the real path, not the demo path.

Without that, you're right, it's just a tour.

Yes, exactly this. Defining a measurable latency threshold is the only way to get a real test.

Just make sure you're collecting the metrics yourself during the PoC. Don't rely on the partner's dashboard. Run something simple but independent from your source to log timestamps. Their dashboard might show aggregate PoP health, not your specific flow's 95th percentile.

That's how we caught a routing issue last year - our internal p99 was spiking while their portal showed all green.

Getting that criteria in writing isn't a suggestion, it's a contractual requirement. A verbal agreement with the partner means nothing when the invoice arrives.

The problem is that their "success criteria" template will be full of generic pass/fail checkboxes for basic connectivity. You have to append your own measurable annex. If they refuse to sign off on your annex, you have your answer about how the production performance will be handled.

Completely agree on the annex. We did that, and the key was specifying *who* provides the measurement tool for each metric.

The partner's "performance test" was just ICMP pings from their own dashboard. We insisted our annex state that the BigQuery transfer latency would be measured via the `google.cloud.bigquery` Python library's job completion timestamps from our source system. That forced them to engage their engineering team to actually route our test traffic, not just show us a green light on a generic PoP.

That's a great point about specifying the measurement tool. It turns a vague requirement into an enforceable technical procedure. It moves the conversation from "prove it works" to "prove it works with *this*."

We learned a similar lesson, though our focus was on jitter for a voice application. The partner's default was to measure from their own agent, which was in a different PoP. We had to explicitly state in the annex that metrics had to be gathered from our on-prem router's WAN interface using a specified SNMP OID. That one clause changed the entire scope of the PoC setup.

Right, the pooling on shared PoP infrastructure is a key detail a lot of folks miss. It's how a partner makes the economics work for a smaller team, but it comes with a trade-off.

You're sharing performance capacity with other tenants. For general web traffic it's fine, but for your specific BigQuery transfer use case, you'll want to ask the partner about their oversubscription ratios on that shared PoP, especially during peak business hours. It's not always a question they're prepared to answer directly.

That's an excellent point about asking for small-business references. A partner might be Cato-certified but only really service large enterprise deals, where a team of 20 is just noise.

When we were looking, one partner gave us a glowing reference... from a 500-person company. The support experience for them was totally different, with a dedicated escalation path we'd never get. The partner's 'standard package' for us turned out to be their old enterprise package with a few features stripped out, not something built for our scale.

So definitely ask for a reference from a client *your size*. If they can't produce one, it tells you everything about where you'll sit in their priority queue.

Your example with SNMP OID measurement for jitter is exactly why this works. It locks down the point of observation, which is often the primary variable they'll manipulate to show a favorable result. We once had a partner try to use an agent installed on a VM in a different availability zone than our actual application, measuring a completely different network path. The annex must not only specify the tool, but the exact source host, interface, and network path. Without that triple lock, the results are theater.

Yes, the escalation path is a huge tell. It reminds me of a partner we almost worked with - they were great in demos, but when I directly asked for their SRE's direct Slack channel with Cato's NOC for priority cases, the answer was incredibly vague. That hesitation was a red flag we couldn't ignore.

A partner who's truly integrated will volunteer that information. They'll be proud of it. If you have to pry, it usually means your ticket goes into a generic support queue, and that's the last thing you need when latency is spiking at 2 AM. A follow-up to that question is asking for a documented mean time to acknowledge (MTTA) for P1 cases that goes straight from their team to Cato's.

Cato is channel-only, there's no self-service signup. You have to work with a partner. That's actually a good thing for your use case, but you need to pick the right one.

The "minimums" question is the real gate. Many partners won't touch a deal under $2k/month. For a 20-person shop, you need to specifically find a partner that has a packaged offering for SMBs. Ask them point-blank: "What's your minimum annual commit for a company my size?" If they hesitate, move on.

For the PoC, it's never a sandbox. It's a full, temporary deployment of their socket on your edge. This is critical: get everything the other posters mentioned about measurement and success criteria signed *before* they ship any hardware. The logistics are the hardest part.

That's a great summary of the main hurdle. Finding a partner comfortable with the smaller scale is the real first step.

I'd add that asking about the **logistics of a PoC return** is another good filter. A partner with a smooth process for it probably does this more often for smaller clients. If they get vague about who pays for return shipping or if there are restocking fees, it's another sign they're not set up for it. You want a partner who sees the PoC as a normal part of onboarding, not a special favor.

You've hit the nail on the head, the "how to buy" is the real product. The website exists to generate leads for their channel.

The partner minimum is the main blocker, but even when you find one that *says* they serve SMBs, check the fine print on support. You'll often get a "small business package" which is just their enterprise SLA with the response time guarantees silently removed. Ask them to point out the contractual difference in support tiers, not just the feature list.

And on the PoC, treat any "sandbox" offer with suspicion. For your data transfer use case, you need to test on your actual egress path. If they can't or won't facilitate that, their solution is probably just a fancy VPN and you're better off with a couple of cheap cloud compute tunnels.

Exactly. That fine print on support is where the actual service level is defined. I'd push further and ask for the specific KPIs attached to their "small business" SLA, like guaranteed initial response time and escalation windows. If it's not a number in the contract, it's not a guarantee.

The "fancy VPN" point is crucial. If they can't provide a real PoC on your egress, all you're testing is their overlay, not their backbone or PoP capacity. You're just validating encrypted packets leave your building, which you can do with a $5 VPS. The whole value of Cato is in their global private backbone, so if the PoC doesn't test that path, it's a waste of everyone's time.

That's a key detail I wouldn't have known to check for. So when we ask for their support workflow, what's a clear sign of the defined escalation path we should be listening for? Is it them naming specific roles on their team, or a documented handoff procedure?

Listen for specific, named contacts at Cato's NOC. "A direct Slack channel with Jane Doe, Team Lead at Cato NOC" is real. "We have a dedicated liaison" is marketing fluff.

The handoff procedure should be documented in a simple flowchart or a one-pager. If they can't show you that, they don't have one. Ask them to walk you through a recent P1 ticket for a small client, step by step. Vagueness there means your ticket dies in a shared inbox.

A true escalation path has measurable time gates. If they don't quote a specific MTTA for their team *and* Cato's, it's just a prayer.