Hey everyone. We just finished rolling out Banyan to our team of about 300 users. We're a finance firm, so security is obviously a huge priority, which is why we chose it. The technical team loves the zero-trust model.
But... our user adoption has been really rough. The help desk is flooded. I'm trying to understand what we might have missed in the rollout planning.
The biggest pain point seems to be on mobile. Our sales and exec teams are constantly complaining that the app drops connection or they get "blocked" from simple internal sites they need, even after being authenticated. The transition from traditional VPN seems to have been a bigger shock than we anticipated.
Has anyone else scaled Banyan to a few hundred users, especially in a regulated industry? What were the key lessons for making it smooth for the less-technical users? Learning the ropes.
CloudNewbie
> "The technical team loves the zero-trust model."
That's often where the disconnect starts. Zero-trust isn't a magic wand, it's a pile of policies that can easily break mobile access if they're too aggressive. Dropping connections sounds like timeout settings or a shaky app, not user error.
For a regulated finance shop, did anyone pilot the mobile experience with actual sales folks before forcing it on 300 people? Compliance doesn't mean ignoring how people work.
What are the help desk tickets actually saying? "Blocked from simple internal sites" usually means someone over-engineered the access rules.
You're spot on about the disconnect. The "pile of policies" is exactly where cost models break, too. A zero-trust rollout is an infrastructure change with a direct labor cost impact that's rarely quantified. Every aggressive timeout or over-engineered rule creates a measurable spike in help desk volume.
What's the mean time to resolve these mobile tickets versus your old VPN? That's the number that turns a technical "shock" into a business case for a policy review. If the sales team's tickets are taking twice as long, the productivity loss is a real operational cost, separate from the Banyan license.
The question about piloting is really about a phased cost assessment. Rolling out to 300 users without a measured pilot in finance means you're accepting a blind spot in your user support cost forecast. You've essentially bought an unknown quantity of future help desk labor.
CostCutter
You're quantifying the impact correctly, but the root cause often lies in the architecture stage, not the policy review. That unknown help desk labor cost is the direct result of a single-tiered policy model.
Teams build for the most restrictive use case, applying it universally. A salesperson accessing a CRM on a mobile network needs different session timeouts and health check intervals than a developer pushing code over office Wi-Fi. If you don't architect for these classes of access from day one, you're forced into a global policy that will break a major user segment. The cost isn't just in tickets, it's in the re-architecting you now have to do under fire.
Did they model distinct trust broker configurations for mobile, campus, and remote desktop workloads? If not, every "fix" will be a brittle exception.
Boring is beautiful
Absolutely agree on quantifying the "pile of policies" as a labor cost. We saw a similar spike in support tickets during a major security platform change last year.
Your point about comparing mean resolution time to the old VPN is crucial. It turns an abstract complaint into a concrete metric leadership can't ignore. We found that when we presented the data as "each mobile ticket now takes 45 minutes instead of 10," it unlocked budget for immediate policy tuning and user training we should have had from day one.
Piloting with a cost lens - measuring those support hours per user group before a full rollout - is the only way to forecast that hidden labor hit.
Always A/B test.
That's a great way to frame it for leadership. I've found that turning the data into a cost-per-ticket really drives the point home.
When you tracked the resolution time difference, did you also capture the type of issues causing those long tickets? I'm wondering if the 45-minute ones were mostly about re-architecting access policies on the fly for specific apps, versus simpler fixes.
It makes me think you need two metrics: one for the immediate support burden, and another for the engineering time to adjust the underlying policy architecture.