Linear #172: The Relationship Between Customer Success & ACV, Hadrius, Early Steps In Transforming Into An AI Company
One vSaaS breakdown. One biz story. One 'how to'. In your inbox once a week.
Today’s newsletter is sponsored by Xplor Pay. In their latest case study, they show how a POS provider embedded payments using PayFac as a Service without taking on the burden of compliance, risk, or merchant onboarding.
Learn how white-labeled payments, streamlined setup, and flat-rate pricing helped the platform improve the experience while unlocking new recurring revenue. Read the full case study.
Alright, let’s get to it…
A question I got recently was…
How much time/effort would you say your onboarding takes for your vSaaS?
What about normal support?
Does that vary by plan/price tier and approximate ACV?
I love this question because most founders obsess over CAC and ACV on the way in…
But they don’t spend enough time thinking about the delivery burden after the contract is signed.
And in vertical SaaS, that’s where a lot of the bodies are buried.
Here’s the benchmark they sent me:
ACV: ~$5K
Sales process: 1–3 hours on Zoom calls to close
Onboarding: 5–10 hours of training + 5–10 hours of data migration
Total onboarding: 10–20 hours per logo
Ongoing support: ~1 hour per month
Observation: for every 100% increase in ACV, onboarding time only goes up about 20%
Honestly? That’s pretty healthy.
And it highlights something a lot of founders miss:
Implementation should not scale linearly with ACV.
If your ACV doubles and your onboarding doubles too, you’re not building leverage.
You’re just selling a nicer version of services.
The goal is not to eliminate implementation. The goal is to make sure that as ACV goes up, implementation effort grows much more slowly than revenue.
That is exactly what this persons data suggested.
At roughly $5K ACV, spending 10–20 total hours to get a customer live can make sense if:
the customer retains well,
support stays contained,
and onboarding creates a durable moat rather than a recurring headache.
What would worry me?
If the same customer also needed endless custom setup, weekly handholding, or bespoke migration work that never got productized.
That’s where people fool themselves.
They call it “white glove.”
What it really means is “we haven’t built the product yet.”
So how do I think about it?
ACV doesn’t just shape GTM.
It also shapes implementation architecture.
Low ACV often pushes one toward PLG or marketing-led motions; mid-range ACV leans inside sales; high ACV usually forces higher-touch selling. This isn’t law it’s just what I typically see. The same basic logic applies after the sale. Higher ACV generally supports more human touch — but if you’re doing it right, the effort should rise sublinearly, not one-for-one with revenue.
Here’s the simple mental model I’d use:
Tier 1: Low ACV / light-touch
Think small accounts, simpler workflows, lower switching cost.
Standardized onboarding
Template migration
Group training / office hours
Async support first
Product does most of the work
If these customers need lots of calls, custom data cleanup, and one-off workflows, your margins are going to get cooked.
Tier 2: Mid ACV / guided onboarding
This is roughly where your example sits.
A few sales calls are fine
10–20 onboarding hours can work
Some migration help is fine
Monthly support can stay lean if the product is clear
The key is turning repeated onboarding work into product, docs, automations, and checklists
This is often the sweet spot in vertical SaaS.
The customer is paying enough to justify real help.
But not so much that you need a mini-consulting firm attached to every new logo.
Tier 3: Higher ACV / high-stakes onboarding
Once ACV climbs, the implementation burden usually shifts from “training users” to “changing operations.”
Now you’re talking about:
integrations,
data mapping,
policy design,
stakeholder alignment,
executive reporting,
and internal change management.
That’s not just onboarding anymore. That’s operational transformation.
And yes, higher ACV accounts absolutely deserve more touch.
But the best vertical SaaS companies still keep control of the process by making implementation modular, repeatable, and tiered.
That’s the magic.
Not “no humans.”
Precise humans, in the right places.
There’s some good external support for this idea too.
One good onboarding playbook I reviewed recommends using ACV thresholds as routing logic: accounts above roughly $5K estimated ACV can qualify for more human-guided onboarding, while larger accounts may justify even more strategic support. It also suggests very different CS coverage models by segment — roughly 1:20 for high-touch enterprise, 1:100 for hybrid accounts, and automation-first for true self-serve cohorts.
That same playbook had one nugget I really liked:
When accounts stall, speed to human help matters a lot. Customers who got help within 4 hours had a 3–4x higher recovery probability than those that waited 72 hours. That tracks with what most of us have seen in practice. Not every customer needs high-touch onboarding — but the right customer, at the right stuck moment, absolutely does.
So if I were answering the original question directly, I’d say this:
My take
For a vSaaS business at around $5K ACV, 10–20 hours of onboarding per new logo plus ~1 hour/month of ongoing support is very reasonable — if retention is strong and the work is becoming more repeatable over time.
And yes, this should vary by plan and ACV.
But the variation should look more like this:
Higher ACV = more structured onboarding
Not necessarily dramatically more onboarding hours
Higher ACV = more strategic support moments
Not necessarily infinite reactive support
In other words:
Revenue should scale faster than service load.
That’s the game.
Because once implementation effort starts rising faster than ACV, the software model starts leaking.
And when founders tell me they have a $5K ACV product that takes 40–60 hours to onboard every customer, I usually have the same reaction:
That’s not a SaaS margin profile.
That’s a services margin profile wearing a SaaS costume.
Quick PSA:
Hadrius & Why More Vertical Start-Ups Need To Focus On Solving Compliance
Compliance is one of those categories that most founders avoid because it looks painfully boring from the outside.
But if you’ve been around vertical software long enough, you know that “boring” is often where the monster businesses live.
Hadrius is a great example of that.
They’re building AI-native compliance infrastructure for financial institutions — RIAs, broker-dealers, private funds, and compliance consultants. The wedge is straightforward: automate the ugly stuff that nobody wants to do manually anymore — communications review, marketing review, archiving, employee oversight, firm oversight, and trade surveillance — and pull it all into one system of record.
That market is not small.
YC’s company page says 30,000+ financial firms spend a combined $16B+ a year on ongoing SEC compliance, while still relying on consultants, law firms, and legacy software glued together with spreadsheets and manual reviews. That’s the kind of market that looks sleepy until you realize how much pain is buried under the surface.
And the founding story is exactly the kind of thing I love in vertical SaaS.
The team behind Hadrius didn’t just “discover” compliance from a market map. They ran an SEC-registered robo-advisor themselves, Quantbase, and felt the pain firsthand. Out of that pain they built Hadrius in 2023. They later raised a $2M seed round with participation from Y Combinator, Lynett Capital, Singularity Capital, Dorm Room Fund, Unpopular Ventures, and a handful of fintech founders/operators.
This is textbook vSaaS behavior:
You start with a painful workflow.
You solve the thing that is both mandatory and miserable.
Then you expand into adjacent workflows that already touch the same data, the same users, and the same compliance clock.
That’s exactly what Hadrius appears to be doing.
Their product suite now spans Marketing Oversight, Communications Oversight, Employee Oversight, Firm Oversight, and Transaction Oversight. In other words: they didn’t stop at one point solution. They’re trying to become the compliance OS.
And there are some real proof points showing up.
On its current site, Hadrius says it serves 500+ client institutions, covers $5T+ in AUM across clients, saves 19+ hours per user per week, reduces false positives by 90%+, and claims a 10x reduction in marketing review cycle times. In a regulated vertical, those are not vanity claims. Those are “I can justify this purchase to my boss and to an auditor” claims.
The other thing I like here?
They’re not pitching “AI magic.” They’re pitching regulator-ready evidence, zero-data-retention AI, WORM-compliant storage, SOC 2 Type II compliance, RBAC, SSO, and audit-readiness. That matters. In vertical software, especially in regulated markets, the winner usually isn’t the company with the flashiest demo. It’s the one the buyer trusts enough to put in the workflow.
This is the broader lesson.
AI in vertical SaaS gets way more interesting when it stops being a chatbot and starts becoming a compliance operator, a claims operator, a dispatch operator, a billing operator, a credentialing operator.
That’s where the value piles up.
That’s where the data moat gets deeper.
That’s where the expansion revenue starts to show up.
Hadrius is interesting not just because it’s an AI company.
It’s interesting because it’s attacking a vertical where the pain is mandatory, the workflow is recurring, the switching costs can get real, and the trust layer matters a lot.
And if they keep moving from wedge to workflow suite, you can start to see the shape of a very serious business.
Early Steps In The Transformation To An AI Company
A lot of software companies are still treating AI like a feature.
Add a copilot.
Add a summarizer.
Add a “generate with AI” button somewhere in the UI.
Cool. Fine. Better than nothing.
But that is not the same thing as becoming AI-native. And I think this is where a lot of incumbents are going to get smoked.
The companies that win this next wave won’t just sprinkle AI on top of old workflows. They’ll rebuild the workflow itself.
That’s the big idea behind Intercom’s transformation, which Eoghan McCabe and the team have talked about pretty openly. Intercom moved from legacy SaaS assumptions toward an AI-first operating model by reorganizing teams, re-architecting parts of the codebase, building rigorous internal eval systems, and shifting pricing toward outcomes.
So if you’re running a vertical SaaS company today and you’re not AI-first yet, here’s the playbook I’d follow.
Step 1: Pick one workflow where labor is still doing the work
Not one feature. One workflow.
That’s the key.
Find the place in your product where your customer is still paying with labor:
reviewing claims
checking compliance
writing notes
calling patients
routing jobs
reconciling invoices
answering repetitive messages
moving data from one system to another
That is your wedge.
Hadrius didn’t start with “let’s add AI to finance.”
They attacked recurring compliance work that was already mandatory and already painful. That’s why the wedge makes sense.
Step 2: Create a small AI strike team with a single owner
One of the smartest lessons from Intercom is organizational, not technical.
They centralized AI talent, created focused workstreams, and assigned a Directly Responsible Individual to each mission-critical effort. No mushy committee ownership. No “everyone owns it.”
If you want to become AI-native, do not bury AI inside your normal roadmap grooming process.
Spin up a team.
Give it a workflow.
Give it a number.
Give it a boss.
Step 3: Rebuild the system so AI can actually operate
This is where most companies quit.
They want AI-native output from a legacy stack that has:
messy data,
brittle workflows,
poor instrumentation,
weird permissions,
and no clean system of record.
Intercom’s team has talked about re-architecting core systems and even modernizing parts of the stack because AI leverage depends on the underlying foundation. Their point was simple: AI is not an add-on. The foundation matters.
In vertical SaaS, this usually means:
cleaning workflow data,
tightening permissions,
exposing the right actions through APIs,
building evaluation infrastructure,
and defining what “good” actually looks like.
No clean data, no real AI operator.
Step 4: Prototype internally first, then with design partners
Another Intercom lesson I like: prototype early, test internally, then go out to market with real conviction.
They built internal eval systems, tested against historical data, and ran large-scale experiments before opening things up more broadly. They also used internal teams as early users before putting unstable systems in front of customers.
This is how I’d do it in vertical SaaS:
Phase 1: internal dogfooding on your own workflows
Phase 2: 3–5 design partners
Phase 3: narrow commercial rollout
Phase 4: broader launch with clear success metrics
Do not skip the eval layer.
If you can’t measure resolution quality, speed, accuracy, hallucinations, or downstream impact, you don’t have an AI product yet.
You have a demo.
Step 5: Price the outcome, not the seat
This is one of the most important mindset shifts.
Intercom’s AI product, Fin, pushed outcome-based pricing — charging for a successful resolution rather than a seat. If the AI escalates and doesn’t finish the job, the customer doesn’t pay for the resolution. That changes the internal culture. Suddenly everyone is aligned around actual customer value. This is a lot easier to say than do, but give it a shot…
In vertical SaaS, that idea gets very interesting.
What if you charged for:
claims resolved,
compliance reviews completed,
invoices reconciled,
messages handled,
appointments booked,
or dispatches completed?
Not every product can move all the way there.
But every founder should at least ask the question.
Because AI-native businesses are often much closer to outcome economics than legacy SaaS businesses.
Step 6: Change the org, not just the product
This is the part people don’t want to hear.
Becoming AI-native usually means changing:
hiring,
team structure,
success metrics,
product rituals,
and what “good” looks like across engineering and GTM.
Intercom described this as a real operating-model shift, not a feature launch. They centralized talent, emphasized speed and experimentation, and hired for versatility while still building deep specialist capability where it mattered. BVP Atlas
That’s the opportunity for vertical SaaS founders.
You already have the domain context.
You already understand the workflow.
You already know where the labor is hiding.
Now you need to rebuild your company around eliminating that labor in a trustworthy way.
That’s the difference between “AI-enabled” and “AI-native.”
One gets you a press release.
The other gets you a new company.
And if you’re feeling behind on this, don’t panic.
The good news is vertical SaaS founders usually have a few huge advantages over horizontal teams:
We know the workflow better.
We know where the bodies are buried.
We know what “good enough” actually means in the real world.
We know where the human still has to stay in the loop.
That matters a lot.
So if you’re not AI-native yet, start with one painful workflow, one great team, one measurable outcome, and one real design partner set.
Do that well and you’ll be way ahead of the founders still shipping AI glitter.
You’ve got this.
Do me a solid and forward to a friend :-)