What I learned building Customer Success functions from scratch, twice.

The first time I was asked to build out a Customer Success function from scratch, I made the mistake almost everyone makes. I opened a tab, searched for "Customer Success framework", and started reading. By the end of the afternoon I had a Notion doc full of health scores, traffic lights, NRR formulas, customer journey maps, playbooks for renewals, playbooks for expansion, playbooks for at-risk accounts. Beautiful stuff. Some of it I lifted almost verbatim from the SaaS CS community.

Then I tried to run any of it past an actual customer. A Tier 1 enterprise merchant, processing nine figures a year, with a procurement team older than I am and a payments architecture that touched four acquirers and two PSPs. They did not want a health-score dashboard. They wanted to know why one of their declines had spiked in Germany last Thursday and whether I could get someone on a call about it in the next forty minutes.

That is the gap. Most Customer Success literature is built around SaaS, and most SaaS CS is built around volume: hundreds of small accounts, segmentation tiers, mostly self-serve, mostly automated. Payments at the enterprise end is the opposite. It is dozens of relationships, each individually material to the revenue line, each different enough from the next that the same playbook is rarely the right one. The question isn't "how do we scale CS." The question is "how do we do CS at all, here, with these customers, with this product."

I have now done it twice. Once at APEXX Global, where I implemented and grew a new Relationship Management function on the orchestration side of payments, managing a portfolio that ended up sitting at over £8 million ARR. And now at Enfuce, where I joined as one of the founding members of the Customer Success function under new leadership, this time on the issuer-processing side. Two different layers of the stack, two different sets of customers, two different companies at different stages. But the lessons rhyme.

Here is what I have actually learned, written down honestly rather than for the kind of audience that wants the seven-step playbook.

01. The first hire is the wrong hire to optimise for

When a payments company decides it needs CS, the temptation is to hire someone who has built a CS function before, hand them a remit and let them go. This rarely works the way leadership thinks it will. The person who has built a CS function before has built one somewhere else. They built it for that company's product, that company's customers, that company's commercial model. Almost none of that ports cleanly.

What the first hire actually needs to do, in the first six months, is something closer to ethnography. Sit in on every customer call. Read every renewal contract. Find out where the money actually comes from. Find out which customers product is afraid of and why. Find out who answers the phone at 2am when the gateway goes down. None of this is in a framework. It is the prerequisite to writing one that fits.

The mistake leadership makes is judging the first hire by output in the first quarter. The mistake the first hire makes is producing it. You end up with a framework that looks impressive in a board pack and fits no actual customer in the building.

02. You can't standardise what isn't standard yet

One of the things that consistently bit me, both at APEXX and at Enfuce, was the urge to write down "the process" too early. There is enormous internal pressure to do this. Sales wants to know how handover works. Finance wants to know how forecast meetings run. Product wants to know how feedback gets channelled. Everyone wants a flowchart. Especially the people who are not doing the work.

The problem is that for the first nine to twelve months, there is no process. Or rather, there are forty processes, all running in parallel, all in your head, all subtly different per customer. Trying to flatten that into a single playbook prematurely produces something that is true on average and useful to nobody specifically.

What I have learned to do instead is keep a running document of every decision I made and why. Why did I run that QBR quarterly instead of monthly. Why did I escalate that issue to the CTO directly and not through their account director. Why did I push back on that pricing change rather than let it go through. After about six months of doing this, the patterns start showing up. That is when you can write the framework, because by then it is describing something that actually happened, not something you hope will.

03. The first thing you build is not the framework. It is the trust

Internal trust. Not the customer's trust. The customer's trust comes with time and consistent delivery and is largely outside your control. Internal trust is what you build deliberately, in the first months, with the rest of the business.

The reason this matters: CS, especially in a payments business standing it up for the first time, has no natural home. Sales thinks you're stealing renewals. Product thinks you're stealing the roadmap. Operations thinks you're stealing escalations. Finance does not know what you do. Everyone defaults to suspicious unless you give them a reason not to.

What I have found works is the opposite of what people expect, which is to be relentlessly transparent about what you're doing and why, and to deliberately give credit to other teams in front of the customer. If product ships something, tell the customer product shipped it. If sales negotiated the contract that's now expanding, tell the customer sales did that. Your job, internally, is to make the rest of the business look good to the customer. Their job, in return, is to make you good at yours. This is the deal. It takes about six months to land, and once it has, everything else gets easier.

04. Tooling will not save you, but bad tooling will sink you

At Enfuce I spent a meaningful chunk of my first year working with internal teams and third-party partners to rebuild the Salesforce environment from the ground up. Not because I love Salesforce, but because the existing setup was actively in the way of doing CS properly. Account hierarchies didn't match how the business actually sells. There was no concept of health, no concept of programme milestones, no clean way to see what a customer was actually using versus paying for.

The temptation, when you walk into something like this, is to build a Customer Success palace on top of it. A fully instrumented health score, automated playbooks triggered by usage drops, dashboards for every conceivable metric. I have built versions of this. I have also watched them not get used, because the CSMs were too busy being on calls with customers to update them, and the customers didn't change their behaviour because of a colour-coded square on a screen somewhere.

The version that actually works, in my experience, is the opposite. Build the smallest possible tool that captures the smallest number of fields that you will genuinely look at every Monday morning. For me that is renewal date, exposure, last meaningful interaction, three open items, and any current escalations. Five things. If a CSM cannot answer those five things off the top of their head about every account they own, no dashboard is going to save them.

05. The biggest accounts are the easiest, and that is the trap

This one is counterintuitive enough that it took me both jobs to really see it. The biggest, most strategically important accounts tend to be the easiest to manage in the day to day. They have mature teams. They communicate well. They know what they want. They escalate properly. They turn up to QBRs.

The trap is concluding from this that they are the lowest risk. They are not. They are the highest risk, because the day they leave is catastrophic, and when they decide to leave it is almost always because of something you didn't see coming. Often something months out, often something that was raised politely in a sentence buried halfway through an otherwise positive review. The signal is always there. You have to be paying attention with the right ear.

My personal rule, which I would not be able to defend in a framework diagram but which I would defend in a conversation: spend more time on the customers who seem fine than on the ones who are loudly complaining. Loud complaints are easy. They tell you what to do. Quiet attrition is what costs you the renewal.

06. Cross-sell is the byproduct of being useful, not the goal of a quarter

At APEXX I drove a 15% revenue uplift through cross-sell and upsell across my book. The way leadership tends to read that is "Kieron ran a successful cross-sell campaign", and the way I would read it, honestly, is that I spent two years being properly useful to my customers and the cross-sell was the receipt at the end.

Cross-sell in payments at the enterprise end is not a campaign. It is the natural outcome of a customer thinking of you when their problem changes. If they are launching in a new market, are you the first call. If they are looking at a new payment method, are you the first call. If their CFO is asking why their auth rate looks the way it does in Italy, are you the first call. The answer is yes or no. You cannot fake yes with an email campaign.

What this means in practice is that the CS team is the most under-rated commercial function in most payments businesses. Not because they "drive expansion revenue", a phrase I have said in meetings and slightly cringed at while saying. But because they are the people the customer thinks of first when a new commercial problem appears. That is the entire game. If you build a CS function that gets thought of first, the revenue follows. If you build one that doesn't, no playbook will compensate.

07. The hardest part is none of the things in this article

The hardest part of building a CS function from scratch, twice, is not the frameworks or the tools or the politics. It is the discipline of staying in the work while building it. Of taking the customer call when you also have a board paper due. Of running the QBR even when nobody internally would notice if you didn't. Of saying no to the small thing that doesn't matter so you can say yes to the small thing that does. Most CS functions die slowly, not because anyone designs them badly, but because the first few people doing the work get pulled in too many directions, lose the thread, and the customer feels it before anyone in the building does.

The version of this job I am most proud of, both at APEXX and now at Enfuce, is the version where the customer cannot quite tell who in the building did what for them. They just know things work, things get resolved, things grow. That is the function working. It is also the version that is least visible internally, which is its own structural challenge and probably a topic for another post.

If you are about to hire your first CSM, or you are the first CSM about to walk in on Monday and try to build something, the only real advice I would give is this: go slow at the start. Listen more than you write. Trust nothing you read on the internet about Customer Success, including this article. The customers will tell you what good looks like. Your job is to be the kind of person they tell.