Our biggest competitor was a PDF

Between 30 and 40 percent of our enterprise deals were dying after the buyer had already decided they wanted us. Not on product, not on price. In the security review, on two questions we could not answer yes to. The fix took four days and moved our enterprise close rate from 60% to 92%. The harder problem was that none of those losses were labelled correctly in our own CRM.

Gracker.ai helps B2B SaaS companies get found when their buyers ask an AI assistant instead of a search engine. Answer Engine Optimization, Generative Engine Optimization - whatever you call the category, the job is the same: making sure that when someone asks ChatGPT or Claude or Google's AI mode which vendor solves their problem, your name is in the answer.

That is a marketing problem, and we sell to marketing teams. Which is why it took us longer than it should have to notice that our pipeline was leaking somewhere marketing had no visibility into.

Key Takeaways

• We lost 30-40% of enterprise deals in the security review, after winning on product. Those deals were worth $50K to $200K annually each.
• Two questions decided it: SAML or OIDC single sign-on, and SCIM provisioning. There is no partial credit on either.
• Building it in-house was estimated at two to three senior engineers for eight to twelve weeks, using the same engineers who build the product people actually buy us for.
• We did not change our authentication. We put enterprise SSO in front of it, for the customers who required it. Four days from integration to production.
• In 90 days: close rate 60% to 92%, sales cycle 120 to 75 days, auth tickets down 78%, and more than 20 hours a month returned to customer success.
• Check your closed-lost reasons. Ours said "went quiet", "timing" and "no decision". They never said SSO.

We were losing 30-40% of enterprise deals after we had already won them

Our enterprise deals were dying late. Not at the demo, not at pricing, not in a bake-off against someone else's product. They were dying after the buyer had already decided they wanted us - in the security review. Between 30 and 40 percent of them.

If you have not been through an enterprise security review, the shape of it is this. Somewhere after the commercial conversation and before the contract, a questionnaire arrives. It is long, it is not written by the person who wants to buy your product, and it is scored. Most of it you can answer. And then there are two lines that you either answer yes to or you do not have a deal:

Does your product support SAML or OIDC single sign-on against our identity provider?

Does your product support SCIM provisioning?

The second one is the one people underestimate. Enterprise IT is not asking out of curiosity. They are asking because they have a compliance obligation to prove that when an employee leaves, that employee's access to every SaaS tool disappears without a human remembering to do it. Our enterprise customers were bringing us teams of 500+ users. Nobody manages that by hand, and no security team accepts "email us and we'll delete the account" as a deprovisioning story.

We could not answer yes to either. And the losses were invisible in the funnel, because they did not look like losses - they looked like deals that went quiet.

Two bad options, one of them a quarter long

Our CTO laid out the choice, and neither side of it was appealing.

Build it. The estimate was two to three senior engineers for eight to twelve weeks. SAML 2.0 and SCIM 2.0 are published specifications, and any competent engineer can read them - that is not where the time goes. The time goes into the difference between a SAML implementation that works against your test identity provider and one that works against a real enterprise tenant, where assertions are signed differently than you expected, attributes are mapped in ways the spec permits but you did not anticipate, and group membership arrives in a shape you have to reverse-engineer from a customer's staging environment on a call. Then multiply that by every identity provider your customers use. And those were the same engineers who would otherwise be building the AEO engine that is the actual reason anyone buys Gracker.

Replace our authentication. Move to a platform that already had these features. Which means migrating every existing account off working authentication onto something new, and accepting the risk of a change that touches every user we have, while enterprise deals sit in the pipeline waiting for us.

The deals in question were worth $50K to $200K annually each. So the cost of getting this wrong was not abstract, and the cost of taking a quarter over it was not abstract either.

We spent longer than we would like to admit going back and forth on which of those two was less bad, which is the sign of a badly framed question.

The third option, and four days

The reframe was realising that we did not need to change our authentication at all. We needed to put enterprise SSO in front of it, for the specific customers who required it, and leave everything else exactly as it was.

That is what we did, with SSOJet. Our existing login continued to work untouched for the customers who use it. For enterprise customers, SSOJet handles the SAML and OIDC connection to their identity provider and the SCIM connection to their directory, and hands us an authenticated user. Our application did not need to learn SAML. It still does not know what SAML is.

It took four days from integration to production. Not four days to a demo - four days to enterprise customers signing in through their own identity providers.

What we wired up:

• SAML 2.0 and OIDC connections to Azure AD, Okta, Google Workspace and OneLogin. The enterprise IdP landscape is not a long list, and it is the same names over and over.
• SCIM 2.0 provisioning, so accounts are created, updated and deactivated from the customer's directory rather than from our admin panel or a support ticket.
• Group-based access control, with the customer's own directory groups mapped to roles in Gracker. Enterprise buyers ask for this specifically: they want to manage who can do what from the place they already manage everything else, not from a settings page in your product.
• Just-in-time provisioning, so a user authorised in the customer's directory who has never signed into Gracker before gets an account on first login rather than a support ticket.
• Webhooks on user lifecycle events, so provisioning changes propagate into our own data model rather than sitting in an identity layer that our application cannot see.

The last two are where our actual engineering time went. Turning on SSO is configuration. Deciding what a deprovisioning event means inside your product - what happens to that user's saved reports, their scheduled runs, the content they own - is application logic, and no vendor can write it for you. Budget for it.

What changed in 90 days

The closure rate is the number that matters, and it is worth being precise about what it means. We did not get better at selling. We stopped losing deals we had already won, to a document.

The sales cycle number has the same character. Security questionnaires that used to take weeks to navigate now get completed in days. When a prospect asks about SSO and SCIM, the answer is "yes, fully supported" and the conversation moves on - instead of a version of "not yet, but it's on the roadmap", which is a sentence that tells an enterprise buyer you are not ready for them.

There is a second-order effect we did not anticipate. SCIM removed an ongoing cost we had been absorbing without accounting for it. Every enterprise customer used to generate a slow trickle of account admin - add this person, remove that person, this team reorganised. That work went to customer success, it was never on a roadmap, and it scaled linearly with every enterprise customer we added. Directory sync gave our customer success team back more than 20 hours a month.

We now close Fortune 500 customers in under 60 days. Eighteen months ago we were losing them to a PDF.

What I would tell you

If you sell to enterprises and you have not hit this yet, you will, and you will hit it at the worst possible moment - on a deal that is already in motion, with a timeline you do not control. The question is only whether you meet it with a quarter of engineering ahead of you or four days.

And check your closed-lost reasons. Ours did not say "SSO". They said "went quiet", "timing", "no decision". The security review is not a stage most CRMs model well, and a deal that dies there often gets logged as something else entirely. We were losing to a PDF for longer than we knew.

About the numbers in this post

Every figure here is Gracker.ai's own pipeline and operational data, measured over the 90 days following the integration and compared against the equivalent prior period. No third-party benchmark is quoted and none is implied. Your numbers will differ with your deal sizes, your buyers' security posture, and how much of your pipeline reaches a formal security review at all.

The four-day figure is elapsed time from starting the integration to enterprise customers signing in through their own identity providers in production. It is not time to a demo.

Individual enterprise customers are not identified, and "23 Fortune 500 companies" is a count rather than a list, because our agreements govern what we can say about named accounts.

Disclosure: Gracker.ai pays for and runs SSOJet in production for enterprise SSO and SCIM provisioning. This post is our account of that project. We were not paid to write it, and SSOJet has published their own version of the same story.

Frequently asked questions

What is SCIM, and why do enterprise buyers insist on it?

SCIM is a published standard for keeping the list of user accounts in your product synchronised with a customer's identity directory, so accounts are created, updated and deactivated automatically. Enterprises insist on it because they carry a compliance obligation to demonstrate that access is revoked when someone leaves, centrally and without depending on a person remembering. Single sign-on alone does not satisfy that: it stops a departing employee signing in through the identity provider, but their account still exists in your system.

Can you add enterprise SSO without replacing your existing authentication?

Yes, and that reframe is what solved this for us. Enterprise SSO can sit in front of your existing login and apply only to the customers who require it, while everyone else continues on the authentication you already have. No account migration is involved. We did not consider it for weeks, because "build or replace" is how the question is usually posed and both of those answers are bad.

How long does it actually take to build SAML and SCIM in-house?

Our estimate was two to three senior engineers for eight to twelve weeks. Reading the specifications is not the cost. The cost is the gap between an implementation that passes against your test identity provider and one that survives a real enterprise tenant, multiplied by every identity provider your customers use.

Which identity providers do you actually need to support?

In our experience the enterprise landscape is short and repetitive. We connected Azure AD, Okta, Google Workspace and OneLogin, and that covered our enterprise base. A long tail exists, but it is much thinner than initial research suggests.

Our enterprise deals keep going quiet. How do we tell if this is why?

Read the questionnaires rather than the CRM field. Deals blocked in a security review rarely get logged as a capability gap, because from the seller's side the buyer simply stops replying and nobody tells you which question you failed. If "went quiet", "timing" and "no decision" account for a large share of your enterprise closed-lost, treat that as a missing instrument rather than an answer.

What does manual account admin actually cost?

More than it looks, because it never triggers a decision. Each request takes five minutes, so it is never escalated and never lands on a roadmap, but it scales linearly with every enterprise customer you add. Ours had quietly settled on customer success. Directory sync returned more than 20 hours a month to that team.

Conclusion

We were losing a third to nearly half of our enterprise deals to a document, at $50K to $200K a year each, and our own reporting told us those deals had gone quiet.

The technical fix was four days, and it did not require touching the authentication our existing customers use. The expensive part was the eighteen months before it, spent without the instrument that would have shown us the problem.

If you sell to enterprises, go and read the last ten security questionnaires you received. The answer is either already in them, or their absence is telling you something too.

Gracker.ai uses SSOJet for enterprise SSO and SCIM provisioning. Their write-up of this project is here.