This episode of What the SaaS?! is different. For the first time, we brought in a voice from outside Auth0. Bharg Sharma is a software engineer on the authentication team at SafetyCulture, the workplace operations platform used by over a million people across construction, manufacturing, and logistics.
SafetyCulture sells to enterprise organizations, the kind running hundreds of locations, managing workforces that are never at a desk, in industries where a broken workflow is not an inconvenience. It is a safety issue. And like every B2B SaaS company scaling into enterprise, SafetyCulture knew they were about to hit the identity wall. What Bharg shared was not theory. It was a before, an after, and the numbers that explain the gap.
The Real Cost of Doing It Manually
Before self-service enterprise configuration, getting a new enterprise customer live on SSO was a multi-team project. Engineering was involved. Customer success was involved. Support was involved. The customer's IT team, or the contractors they hired for the occasion were involved. Then everyone waited for availability to align, and each setup took a couple of days.
"It was quite a collaborative process, a little bit more hands-on... it could take like a couple of days for that to happen. Every setup needed our involvement throughout the process."
A couple of days does not sound like much. But each customer came with its own identity provider, its own edge cases, its own timing constraints. Some ran Okta. Some ran Entra. Some ran custom in-house IdPs. Every configuration was a small bespoke project with little repeatability and no self-service off-ramp. Multiply that across hundreds of enterprise customers, each with their own setup, and the math changes quickly.
The most telling signal: approximately 30% of SafetyCulture's engineering customer support tickets were directly tied to SSO setup. And, this was just the act of getting configured. The process worked, it just could not easily scale.
The phrase Bharg used stuck with me: operational load. Not just at initial onboarding, but day-to-day. The manual approach is not a one-time cost, it compounds.
What the Self-Service Flow Actually Looks Like
The experience SafetyCulture built sits on top of Auth0's Self-Service Enterprise Configuration feature. From the customer's side: they log into SafetyCulture, click a modal that opens a new tab, and are walked through a step-by-step wizard — choose OIDC or custom SAML, configure the IDP settings, and test the connection. That last step matters more than it sounds.
"We didn't previously have this for customers... to be honest, this is an amazing feature."
The test-before-you-activate model changes the psychology of the entire setup. The customer is not committing to something they cannot yet see. They run a real login attempt through the configured connection before a single production user touches it. Only then do they return to the SafetyCulture app and flip the toggle to go live.
That toggle is intentional. SafetyCulture chose not to auto-activate a tested connection. The customer has to make a deliberate choice. That one design decision, forcing a conscious, final activation, changes the support story downstream. The customer who enables SSO purposefully is not the customer calling three days later confused about what happened to their login flow.
For teams worried about enterprise IT teams being overwhelmed by identity jargon: the step-by-step structure does most of that work automatically. The wizard does not surface every technical requirement at once. It asks for one thing at a time. Customers who are not ready can exit and come back when they are, the flow is designed to be resumed, not completed in one sitting.
Bharg also noted something forward-looking: SafetyCulture has observed customers starting the flow just to see what is required, then exiting before completing anything. Their next planned iteration is a preview of the full setup process surfaced inside the app, before the customer even begins. That is a small feature. It reflects a larger philosophy about meeting customers where their actual knowledge is, not where you assume it should be.
The Numbers After Going Live
SafetyCulture moved from proof-of-concept to general availability in two months. That timeline is short enough that it needs context. The reason they got there quickly was that the developer experience for building on Auth0's self-service profile enterprise configuration mapped closely enough to what they already had. The concepts translated. The APIs were usable. It was a focused project, not a multi-quarter rearchitecture.
Bharg went from prototype to "this is very doable, we should ship it" in a single sitting. That ease was part of the argument for moving forward.
Four months after going live, the results were measurable:
- 60% fewer SSO setup-related customer support tickets since the feature launched.
Both numbers are larger than I expected. Fifty percent self-completion means the flow is genuinely usable without assistance. Sixty percent ticket reduction means the other half, the customers who do need support are arriving with much more targeted, specific questions than the ones coming in before. The noise is gone. The signal that remains is real work.
Bharg framed it simply: "The customers can now explore this step-by-step flow before committing."
That phrase deserves its own moment. The old flow forced customers to commit before they understood what they were committing to. They would start a manual setup, reach a configuration screen they had not prepared for, and open a ticket. Now they browse the requirements before involving anyone. They show up with the right people and the right information already assembled. The coordination happens before the ticket, not because of it.
The Shift in What "Enterprise-Ready" Actually Means
Near the end of our conversation, I asked Bharg how his understanding of enterprise-ready had shifted.
"Instead of having like a tick box — like we support this feature — now we can say like customers can own it. They can own the whole self-serve flow, the SSO setup, they can test it. The focus is now more on self-serve, testing, and customers being able to audit it themselves."
That is a sharper definition than most B2B SaaS teams are working from. The old version of enterprise-ready is a capability matrix: do you support SAML? Check. Do you support SCIM? Check. Do you support attribute mapping? Check.
The new version asks a different question entirely: can your customer's IT admin walk into your product and do all of that themselves, without calling anyone, on a Tuesday afternoon, while managing ten other things?
The test is not what your product supports. The test is how your customer can operate independently.
This distinction also shows up before the deal closes. When your platform surfaces self-service configuration as a first-class feature, not a workaround, not a support-team-assisted process, the security review conversation changes. It shifts from "can your product do X?" to "how would we configure X ourselves?" That shift signals maturity in a way that a feature checklist never can.
What This Means If You Are Still Doing It by Hand
Bharg's advice for teams still handling enterprise SSO setup manually was direct:
"Putting a number on what the current SSO flow actually costs — the engineering team, support team — I think that's a great way to make a case to improve what you have."
That sounds obvious. What is surprising is how rarely it happens. The manual process becomes invisible because it functions, slowly, expensively, and in ways that do not scale, but it functions. The queue moves. The onboarding closes. Nobody files a post-mortem on a process that technically worked.
SafetyCulture found their number: 30% of engineering support tickets. Once that number existed, the argument for change was self-evident.
The other thing worth noting: the proof-of-concept took Bharg very little time. She built it. It was approachable. That ease was itself the argument for shipping.
Self-service enterprise configuration is not a major architectural bet. It is the infrastructure for your enterprise motion, the difference between an IT admin who calls your support team every time something changes, and an IT admin who owns their environment inside your product. One of those admins becomes an advocate. The other becomes a churn risk.
If enterprise customers are still filing tickets to get configured, that is not a support problem. It is a product problem. And it is a solvable one.
Consult our team to learn more about bringing self-service enterprise configuration to your platform.
To hear the full conversation with Bharg, listen to the complete episode of What the SaaS?!.
About the author
Sheena Allan
Product Manager