Buying the Same Revenue Twice

If I walked into your $20M SaaS company tomorrow and you said “find me another million dollars,” I wouldn’t have an answer for you. I’d have questions.

A million in recurring revenue? Cash this year? Profit? Those are different assignments. And how much are you willing to change the business to get it? Some CEOs are happy to add services. Others would rather leave money alone than build a company they don’t want to run. A million dollars can come with years of obligations.

I’d also want to know how much weight your customer relationships can take. It’s possible to find an expansion opportunity that looks beautiful in a spreadsheet and strains the relationship that made it visible.

Once those are on the table, I’d start in the same two places almost every time. Churn first, then expansion. The funnel matters too, but building a new source of demand can take longer than finding an opportunity among people who are already paying you.

They bought. They handed you a problem to solve. What I want to know is what happened next.

Start with the money that’s already leaving

If customers are leaving and nobody in the building can explain why, I’d want that understood before the company commits more money to growth.

You can have a strong acquisition engine and still be buying the same revenue over and over. New customers arrive, old ones go, everyone works harder than last year, and the number lands roughly where it started.

That’s an expensive way to stand still.

I spent four years building a first-party data activation platform, and churn was a significant use case. Much of that work was figuring out when somebody was dissatisfied, disengaging, or quietly no longer getting enough value out of what they’d bought, while there was still time for it to matter.

The thing that actually worked was refusing to trust any single signal. We read behavior against money. Engagement and product analytics on one axis, spending patterns on the other. On its own, either one told you very little. Put the two together in a matrix and a picture showed up that neither had alone, and the accounts worth worrying about were usually the ones that looked fine on one axis and had quietly slipped on the other. That gap, between how a customer uses the product and how they spend, is often where disengagement shows up first. Early enough to still do something about it.

The cancellation is the last event in a much longer story.

Somewhere upstream the customer stopped getting what they came for, or never got it at all, or their circumstances changed and nobody noticed.

A quiet account might be a happy account. It might also be an account that gave up. Usage helps here, but only if you connect it to the outcome the customer was buying. Logging in tells you somebody logged in.

So I’d read the sales conversation next to the onboarding history, next to the support tickets, next to the usage, next to the renewal. The same customer, all the way through, in one view. That’s what lets you test an explanation against what actually happened.

Why does it take so long?

I talk to companies that tell me it takes six to twelve months before a customer starts genuinely using the tool.

I have a hard time with that one. You persuaded somebody to buy. They signed. And now they’re waiting the better part of a year to get anything out of the decision. I start wondering how long it takes a competitor to notice.

Sometimes the reasons are real. Data has to move. Security reviews happen. The customer has homework and the customer is busy. But “enterprise software is complicated” is the kind of explanation that ends a conversation before anyone examines the actual work.

In conversations like these, it hasn’t taken much pushing before somebody in the room recognizes that a thing measured in months could probably be measured in days. Nothing had been shortened at that point. What we had were assumptions worth testing, and the question that got us there was embarrassingly simple: why does it take so long?

How much of that time is necessary work, and how much is a request sitting in somebody’s queue? Does the customer need the whole implementation before they get any value at all? Did a requirement from one difficult account quietly become mandatory for everybody?

I’d look for the smallest useful outcome a customer can reach. Then I’d measure whether getting there sooner changes activation, retention or expansion.

Early churn deserves its own read. It can mean you sold to the wrong customer, or that the product can’t keep the promise sales made, or that a good customer never made it through the front door. Three problems, three fixes, and sending all of them a discount at renewal is a way of never finding out which one you have.

Expansion starts with what they do next

After churn, I’d find the customers getting real value and watch what they do immediately afterward.

Where do they export the data? What spreadsheet do they open? Who do they hire to finish the job? What keeps showing up in support long after somebody decided it was out of scope?

If people are already working inside your product, you have an unusually good vantage point on the problems sitting next to it. You know something about the customer, they know something about you, and that combination is an advantage most companies leave on the floor.

It does not follow that every request deserves a feature. A large customer can make a persuasive case for turning your roadmap into their internal project plan. So I want to know whether several customers have the same problem, whether it costs them enough that they’d pay to make it go away, and whether you’re well placed to solve it. All three, not the one in front of you.

Then there’s the shape of the answer: a paid capability, a higher tier, a managed service, a partner arrangement. Services revenue comes with delivery obligations, a feature comes with maintenance for as long as it lives, and a partner puts somebody else between you and your customer. Which one is right depends partly on the company you want to run.

There’s a fairness question here too. If customers reasonably believe they already bought this outcome, charging them again to reach it can manufacture the exact churn you were trying to fix. Expansion has to give them something they value on top of the promise they already paid for.

The clues are spread across the company

At $20M to $50M ARR you have enough people to know a great deal about your customers. You also have enough departments for that knowledge to sit in five places and never meet.

Sales hears the thing a prospect would happily pay extra for. Customer success watches the workaround get invented two weeks after the contract is signed. Support answers the same question all week. Product logs a small feature request. Finance notices delivery costs creeping up.

Here’s a hypothetical to show the shape of it. Customers keep exporting reports and paying an analyst to reconcile them against another system. Support closes each export question as a ticket. Success helps with the spreadsheet. Sales mentions an integration in passing and moves on. Each interaction looks ordinary on its own. Put them next to each other and they might describe an expensive job your customers would pay you to take off their hands.

Or they might describe five unusually complicated accounts you should not build a product around. You don’t know which until you assemble the evidence.

Which is why I take everyone’s proposed solution with a grain of salt, mine included. Sales wants something it can sell, product wants a coherent product, success wants fewer unhappy customers. None of those views is wrong and none is sufficient.

Follow one specific customer problem across all of those departments and the conversation gets useful quickly. Now you can see who has it, how often, what they do about it today and what it costs them.

The unglamorous work deserves a look

Fixing, simplifying and stopping things are badly underrated ways to improve a business.

Companies accumulate work the way houses accumulate boxes. An approval gets added after something goes wrong. A report outlives the person who asked for it. A workaround becomes a process and then becomes somebody’s job. Give it a few years and people can explain how the work happens far more easily than why it exists.

So I’d look at the work sitting around your revenue. How many people touch a renewal? Why does a routine account change need engineering? Which custom obligations are still eating time long after the deal closed?

There may well be money in there. I’d just be careful about what kind.

Freeing up ten hours a week creates capacity. It becomes savings only if spending actually falls, and revenue only if you use that capacity to serve demand you couldn’t serve before. Until one of those happens, what you have is freed time. Useful and real, and not a dollar of ARR.

Retention works the same way. Keeping revenue you were on track to lose improves your position against the baseline you were headed for, which is not the same as growth above today’s run rate. If the assignment was a million on top of where you are now, you still need expansion or new sales to get there.

Being strict about this early saves everyone a lot of enthusiastic arithmetic later.

Make the million stand up to a few questions

Say, purely for illustration, you could retain $300,000 of ARR that was otherwise likely to walk, and sell a $10,000 annual add-on to seventy existing customers. Call that a million against the outcome you’d have had without those changes. It is not automatically a million of growth above your current run rate, and on its own it tells you nothing about cash collected this year, because billing terms and timing decide that.

Now the real work starts. Which accounts make up that $300,000? Why do we believe they’re leaving? Can we address the cause or only the symptom? Where are those seventy customers? Has any of them said out loud that they’d pay $10,000? What does it cost to build, deliver and maintain the add-on?

If the opportunity evaporates the moment you ask for customer names, it was never ready to be in a forecast.

I’d go after the pieces where you can get evidence quickly. Examine one cohort. Change one onboarding path. Put a clear offer in front of a handful of the right customers. Decide up front what result justifies continuing and what makes you stop, because deciding that afterward is how projects survive their own evidence. A polite “that sounds interesting” is weak evidence next to a customer committing budget.

Then give one person responsibility for the commercial outcome across departments. Without that, you can ship the feature, close the tickets, update the process and never once check whether the customer got enough value to stay or buy more. Set a date to review the customer outcome and the revenue together, with that person accountable for both.

A CEO does not need another room full of interesting ideas. The hard part is picking the one that deserves the company’s attention, and having enough evidence to leave the rest alone.

So if you asked me to find another million, I’d start by getting much closer to the customers you already have. Where does value take too long to arrive? Where does it break down? What do they still have to do for themselves after they’ve paid you? Somewhere in those answers there may be a problem you’re already equipped to solve and a customer ready to pay you to solve it.

Put that story together first. Then we can talk about where the next dollar comes from.