Linear #168: What do Org Charts Look Like in an AI World? How To Avoid Embedded Payments Failure Rates
One vSaaS breakdown. One biz story. One 'how to'. In your inbox once a week.
I’m hosting a live workshop next week with the Co-Founder of an AI firm who has implemented agents 100+ times at A TON of comapnies. I think you’ll enjoy it…
If you’ve been curious about AI Agents and what they can do for your business, then this live workshop is for you.
We’re keeping it intimate and only allowing the first 25 founder sign-ups!
5 seats left.
Alright, let’s get to it…
Embedded Payments Don’t Fail Because of Tech. They Fail Because We Treat Them Like a Feature.
Alright, let’s get to it.
Most vertical SaaS teams don’t choose to underperform in payments.
They do the “right” stuff: pick a processor, ship the integration, update onboarding docs, train support, announce it to customers… and then sit back waiting for adoption to roll in like it’s a product-led growth miracle.
And when it doesn’t, the story we tell ourselves is almost always external.
“Merchants don’t like change.”
“This vertical is unique.”
“Payments just takes time.”
Sometimes that’s true. But if you’ve been around vSaaS long enough, you start noticing a pattern that’s way more uncomfortable:
Embedded payments rarely fails because the technology doesn’t work. It fails because leadership launches it like a feature instead of building it like a business.
And those are two very different mindsets.
The Companies Doing Real Numbers in Payments Made a Decision (Not a Guess)
The vSaaS platforms generating 40–70%+ of total revenue from payments didn’t stumble into it. They didn’t “add payments” and accidentally wake up with a money-printing machine.
They made a deliberate call that payments would be a core business line with:
a clear owner (not “shared across product + partnerships”)
a real number they obsess over (attach rate, activation speed, GP $)
incentives tied to outcomes
executive visibility every single week
When payments is treated like a side quest, adoption stays optional. When payments is treated like a business line, the organization starts behaving differently—because it has to.
The Shift: From “How Do We Add Payments?” to “How Does Payments Change the Business Model?”
Low-performing teams ask: “How do we integrate payments?”
High-performing teams ask something more strategic: “If payments works, how does it change the economics and operating model of our SaaS?”
That question forces decisions you can’t dodge.
Product stops treating payments like a checkout screen and starts treating it like a merchant experience. Not just “can they run a card,” but “how fast can they get live,” “do they trust payouts,” “does reconciliation make their bookkeeper less angry,” “does this feel safer than what they’re doing today.”
Sales and Customer Success stop pitching it like an add-on and start treating it like a required part of the platform’s success. Not in a sleazy way—more in a “this is the modern way the software works” way. The best teams don’t hope merchants adopt. They build a motion where merchants naturally end up there because the path is clear, supported, and repeatedly reinforced.
And finance—this one matters—stops seeing payments as pass-through revenue. Because it isn’t. Payments is margin, risk, chargebacks, underwriting, pricing strategy, and (if you’re doing it right) a meaningful driver of LTV expansion.
You can’t run that like a feature.
Marketing Isn’t Optional. It’s the Adoption Engine.
Here’s where a lot of SaaS leaders get it twisted: they think payments adoption is a sales problem.
It usually isn’t.
Yes, sales helps. Yes, CS helps. But the strongest vSaaS payments motions are marketing-led and sales-supported, because what you’re really doing is changing behavior. You’re asking a business to re-route how money moves. That’s not a “new feature.” That’s trust.
So what actually drives adoption?
Repetition and clarity.
Merchants adopt when the value is so obvious they feel dumb not doing it. They adopt when the story shows up in-product, in lifecycle emails, in webinars, in case studies, and in conversations with your team—consistently.
And importantly: not “Now with payments!”
More like: “Want faster cash flow?”
“Want less admin work?”
“Want cleaner reconciliation?”
“Want to stop chasing invoices?”
You’re not selling payments. You’re selling outcomes.
Say whaaaaaaaat—marketing actually matters.
Incentives Tell You What the Company Really Believes
If payments revenue isn’t reflected in compensation plans, it’s not a priority. Full stop.
You can write all the strategy memos you want. But if AEs don’t get paid on attach, if CSMs don’t get measured on activation, if exec meetings never review payments KPIs, then payments is just a thing you integrated… not a business you’re building.
When incentives line up, the whole machine tightens:
Sales cares earlier.
CS cares longer.
Product cares about friction.
Leadership cares about the weekly number.
That’s when adoption stops being “nice to have” and becomes inevitable.
Rails Are Table Stakes. Operator Experience Is the Differentiator.
Most providers can give you processing rails. Cool. That’s the minimum.
What matters is whether the partner (and your internal team) actually understands the messy operator reality of vertical SaaS: onboarding flows, underwriting edge cases, support volume, disputes, pricing packaging, renewals, and the constant tension between growth and risk.
One example that’s interesting here is Xplor Pay—not because they have magical APIs, but because they are the only payments provider I’ve ever seen that actually operates vertical SaaS businesses.
They do both so they get it. Having built and scaled 20+ vertical SaaS platforms and have seen attach rates as high as 95% in some verticals. That kind of performance typically comes from getting the full system right: product + GTM + incentives + operations, not just “we embedded a payments button.”
The Takeaway
Embedded payments doesn’t succeed because you integrated it.
It succeeds because leadership decides to run it like a business line—complete with ownership, economics, marketing-driven adoption, and incentives that force focus.
If your payments attach rate is stuck right now, ask yourself the real question:
Are we dealing with a product friction problem… a value communication problem… or an incentives problem?
You’ve got this.
What do Org Charts look like in an AI world?
The old way of building vertical software was pretty linear:
Build a wedge product → add modules → sell seats → become the system of record
It wasn’t wrong. It was just… the best we could do.
The new way is different:
Software doesn’t just track the work.
It does the work.
That’s the shift LLMs enabled: automating tasks that traditional vertical SaaS could never touch. And the budget you’re competing for changes too, from IT to labor.
And once you’re replacing “1–2 FTEs worth of work” (or pricing like you are), the org chart changes.
So what are the roles that make sense in this new age? Org Charts will never look the same again...
A few ideas:
1) Industry Expert
The person who knows the ugly edge cases, compliance gotchas, and what users actually do at 6:30am. No operator = no truth.
2) Workflow Architect
Old product shipped screens. Took them weeks/months.
New product shows full UI prototypes and screens to customers immedietly. Explains what the agent does, what the human is tasked with. Where the ROI ends up.
3) Ontology / Data / Agent Knowledge Expert
If your AI is “doing work,” it needs a real-world map: entities, states, definitions of “done,” and what “correct” means in this industry.
4) Applied AI Engineer
This is the builder turning “cool demo” into production ready software. They should be in every meeting with the Workflow Architect and the customer. Engineers hiding in ivory towers and behind PM's is OVER.
6) Trust Lead (Security / Compliance / QA)
You need someone accountable for guardrails, auditability, and what happens when the model is wrong.
7) AI GTM AE
This is a sales person that uses all sorts of AI tools and Agents to get prospects into meetings. Lazily sifting through the CRM and sending a few handwritten emails is DEAD.
8) Adoption Owner (CS that ships outcomes)
Old CS: QBRs + renewals.
New CS: instruments usage, drives behavior change, automates ROI reporting.
If you’re building vertical software today…
The question 2 years ago was “should we add AI?”
Now it should be...
Is our Org Chart actually designed for a radically different business?






