Separate the AI You Sell From the AI You Run On.
To set the scene: a fraud-detection company just shipped a cutting-edge model that catches synthetic identity fraud in real time. It's a hit.
Meanwhile, their most trusted account manager, hoping to renew her best customer's contract, is still building the QBR slides the old way: pulling last month's numbers into a spreadsheet, then checking them against an email from finance because the two never quite match. The company's product finds fraud faster than any person could. Its own team still can't produce a basic status report without a human-in-the-loop. It doesn't have to be this way anymore.
At Rampwell, we're seeing this kind of split across a few companies we're talking to at the moment. It's not rare. Often in my career, I've seen CFOs and boards undervalue projects that would help the GTM team proactively make more money, going back to my dotcom days. Best case, maybe they hire a presumed 'rock star' (with predictable 50/50 results). But very few decision makers are looking at ways to make the business work smarter, not harder. And that's a function of the following issue: most companies building AI are running one AI project, and leaving the other one - lower risk, higher value - on the table.
Two projects, one budget line
The first project, predictably, is the AI that ends up in what the company sells: a fraud check built into a payments platform, a scoring model layered onto a security scan. Everyone in the company already has a name for this. It's the AI roadmap. It shows up in the board deck and the weekly updates. The success of this effort often depends on marketing getting the messaging right.
The second project is the AI that helps people run the company itself: the account brief before a sales call, the forecast that used to take an entire Friday, the next best action. This project rarely gets a name. When it does get one, it's usually "ops," and ops tends to lose the budget fight to the roadmap.
| Goes into the product | Runs the business | |
|---|---|---|
| Who sees it | Customers | Employees |
| Where it lives | The roadmap | Whatever's broken |
| Who owns it | Product | Whoever's stuck with it |
| How it gets funded | Automatically | Only if someone fights for it |
Neither project stands in for the other. A company can run the first one for years and not materially touch the second.
Why the mix-up costs real time
A few roadblocks keep showing up in our pipeline conversations lately, and none of them are about whether the AI works.
Who pays, and for what. More than one deal we're tracking is stalled on a single conversation between two operating leads about ongoing token costs. Nobody's debating whether the tool is capable. The invoice hasn't been agreed on yet, and until it is, nothing ships.
Looking for consensus when everyone already agrees. A deal sits for weeks because someone wants full internal socialization before signing, which usually means a dozen more meetings with people who were never going to say no. The technical objection died a month ago. The org chart hasn't caught up.
Output that could be about anyone. Imagine a deck-generation skill. Left alone, it keeps defaulting to generic boilerplate instead of pulling specific facts fed about the prospect, because nothing forced it to reach for the specific version over the average one. That's what every buyer is testing for in a pitch, whether they say so or not: does this know my business, or the average of everyone's business. Most sales-cycle friction comes down to somebody running that test.
None of these are technology problems. They're what happens when two AI projects share one conversation and nobody separates them.
Have your cake, and ...
Most bet on which project they think will pay off faster, because the roadmap looks like the safer choice. It comes with a date, and a line on the P&L that reads revenue.
But be the one who bets on the other one. I'm telling you - wiring your business to run better with smart, calculated bets on AI workflows is the safer bet. It's the AI that helps run the company touches every person on an ordinary Tuesday, not just the customers using the one feature that shipped last quarter. It doesn't need a launch. It needs someone to notice the same reconciliation is happening twice and fund fixing that on its own terms, instead of as a footnote to the project that already has a launch date. Anyone on the revenue side knows what I'm talking about.
Back to the fraud-detection company. The model catching bad transactions in real time is great work, and people love it. The QBR slide still built by hand every quarter is a different problem, sitting one desk over, waiting for someone to fund it.
You can have both!