Getting Hired in Customer Success: The 2026 Playbook

Sort by revenue at risk multiplied by how much I can actually influence it. I start from movement rather than absolute state: an account that dropped twenty points this month matters more than one that has been amber for a year, because the amber one is probably mis-scored. Before acting I check whether the drop is explainable, a holiday period, a champion on leave, a seasonal business. Then I pick the play that matches the cause rather than running the same outreach at everything.

I would not know what to do until I split the number. 104 could be strong gross retention with almost no expansion, or weak retention masked by a few large upsells. Those need opposite interventions, and picking wrong costs a quarter. So first I decompose by segment and by cohort, and separate contraction from outright churn, because downgrades usually signal a value problem while churn often signals a fit problem. Then I pick the lever with the shortest feedback loop so we learn inside the quarter rather than reporting on it afterward.

Value is a comparison between what they expected and what they can currently observe, so I start with what was agreed at kickoff. If no success criteria were documented, that is the actual finding and it is ours, not theirs. Then I separate three causes: adoption, where they are not using it; configuration, where they are using it in a way that cannot produce the result; and expectation, where it was sold as something it is not. Each has a different owner and a different fix, and only one of them is solved by training.

When revenue stops tracking the number of licenses bought and starts tracking what the product actually does, the team that drives and evidences usage starts influencing the invoice instead of just defending it. Practically that changes three things for me: I need to know the unit the customer is billed on, I need that unit instrumented so I can see it moving, and I need to show the customer their own consumption curve before Finance does. It also makes under-consumption an early churn signal rather than a billing footnote.

A health score is a prediction, so it should be scored like one. I would take the accounts that churned and the accounts that expanded last year and look at what the score said about them 90 days before the event. If red accounts renewed at a similar rate to green ones, the score is decoration and people will quietly stop trusting it. Most scores fail that test the first time, usually because they weight what is easy to collect, like login counts, rather than what actually predicts, like breadth of use across teams or whether a second department ever onboarded.

I would go and watch before I propose anything. A clinician adopts a tool that gives them seconds back inside the workflow they already have, and abandons one that adds a step, regardless of how good the output is. So I would time the current path and the new path, including login and device setup, because that is usually where the saving is lost. Then I would look hard at the twenty percent who are using it, since they are the proof it can work here, and find what is different about their setup, their ward or their shift. Replicating an internal success is far easier than arguing with the other eighty percent.

I would separate the request from the need, and write down the clinical scenario including what happens if the system is wrong. In healthcare the cost of a false negative and a false positive are not symmetric, so the real question is which error this feature makes more likely and who absorbs it. Then I escalate the scenario rather than the feature request, because a clinical safety lead can reason about a scenario and cannot reason about a line in a backlog. Usually the outcome is not refusal, it is a different design with a human confirmation step.

Four approval chains that run on different clocks: clinical governance, IT security, data protection, and procurement. Then the integration surface, which usually means the record system and the identity provider, and is often owned by a vendor rather than the hospital. Then the data questions, where it lives, how long it is kept, what the audit trail has to show. And finally the shift pattern, because a hospital runs around the clock and if you only train the day shift you have trained a third of your users. In my experience the approval sequence drives the timeline far more than the technical work does.

I treat every report as real until it has been examined, and I capture the specific case: the input, the output, the context and the time. What I do not do is quote an accuracy rate at someone describing their own patient, because that tells them their experience is a rounding error. Then I close the loop with what was actually found, including when the system was right and the workflow was the problem, because that is still a finding worth telling them. One unexamined report costs more trust than ten errors handled transparently.

Time returned to the clinician per encounter, the share of documentation completed within the shift rather than after it, and how often the output needs editing before it is accepted. Those matter because they map onto things the hospital already tracks and already worries about: clinician burnout and turnover, discharge timeliness, and coding or billing accuracy. A login count tells me somebody opened the application. It does not tell me whether the ward got time back.

First confirm it is real and bound it: one merchant or several, one payment method, one issuing bank, one geography, one app version. Then establish whether it is rising or flat, because a climbing curve changes the severity. I would size it on money and trust exposure rather than on how many tickets have arrived, since tickets lag the failure by however long it takes customers to complain. I would notify the merchant before they notify us, with what we know and when the next update comes. Then work the funnel in order, initiation, authorization, callback, settlement, because the stage where it breaks names the owner.

Both statements can be true at once, because settled on the rail is not the same as credited to the customer's account, and those are different systems of record. So I pull the transaction reference and trace it through each system myself rather than collecting each team's summary of what their screen says. To the customer I give a time, not a status: "resolved by six this evening, or I will call you and tell you why" is far better than "we are investigating," because when money is missing an open-ended wait feels like loss.

Both sides are measurable, so I would stop arguing it as a philosophy. A control has a false positive rate and a prevented-loss value. The risk team can see the losses they stopped and genuinely cannot see the good customers who were blocked and quietly left, so that half of the equation is Customer Success's job to produce: how many legitimate customers were declined, what their expected lifetime value was, and how many never came back. Once both numbers are on the table the conversation stops being about who cares more about the customer.

Structure it around what you removed rather than what you added. The version I lived through: an operation running past 100,000 tickets a month with first response sitting around eight hours. What moved it under two was not more agents. It was routing on intent rather than arrival order, building the knowledge base from the actual top failure reasons instead of from a product manual, and automating payment status checks so an entire class of tickets resolved without a human. Capacity was redesigned, not expanded, which is why the number held when volume grew.

Four things and nothing else: what is affected, what is confirmed unaffected, what the customer should do right now, and when the next update lands. No speculation about cause, no long apology, no promise of a fix time I cannot keep. Then I hit that next update time even when there is nothing new to say, because the update itself is the message. In financial services silence is read as concealment, and the gap between incidents is where trust is actually built or lost.

We do not go live on the 28th. Payroll is the one workflow with a statutory deadline, real financial consequences for employees, and zero tolerance for a learning curve in week one. The two defensible options are to go live after the cycle completes, or to move earlier and leave enough room to run payroll in parallel in both systems and reconcile before cutting over. I would also say this to the customer rather than absorb it, because a three-day gap before payroll is not a schedule risk, it is a decision to put their employees' pay at risk.

You reduce what they have to do rather than trying to motivate them harder, because they are not unmotivated, they are at capacity. Concretely: take data preparation onto our side wherever the data allows it, give them decisions instead of tasks, so "pick A or B" rather than "define your leave policy," batch their involvement into short scheduled blocks instead of a steady drip of requests, and sequence the rollout so the first thing that goes live is whatever gives them hours back. Momentum in week three comes from them feeling lighter in week two.

HR signs the contract, employees decide whether it renews, just on a delay. Employee frustration does not arrive as churn risk, it arrives as HR being buried in internal complaints, and about two quarters later that becomes "this tool created more work than it saved." So I treat employee sentiment as a leading indicator of the buyer's future satisfaction rather than as a separate concern, and I give HR the usage and resolution data they need to defend the decision to their own leadership. Protecting the buyer means fixing the end-user experience before it reaches them.

Surface it immediately and in writing, because data problems that are absorbed quietly become our fault at go-live regardless of where they came from. Then classify rather than generalize: what is missing, what is duplicated, and what is internally inconsistent, since those need different owners. Migrate what is clean, quarantine what is not, and agree explicitly who fixes what by when. The one thing I will not do is silently correct fields I do not own, particularly compensation, tenure and entitlement, because a helpful guess there becomes a dispute with a legal dimension.

By deciding what stops being a human task. The standard motion, onboarding steps, check-ins, reporting, adoption nudges, should be delivered consistently without me being the delivery mechanism, and my time should go to exceptions and to accounts where a decision is actually pending. That requires triggers good enough to tell me which is which, which is the real work. I watched this happen directly: CSM capacity moved from roughly 25 to 30 enterprise accounts to 50 to 60 after the operating system was built, with no drop in satisfaction, because the system absorbed the repeatable part rather than the person working longer.

Work backwards from the contact forecast rather than the order forecast, because the two do not scale together, and contacts spike on the failures rather than on the sales. Pull last peak's top contact reasons, fix or deflect the top three now since those are the ones that will multiply, then freeze risky changes before the window opens. Pre-write the communications for the failures we already know will happen, because nobody writes well at 11pm in week two of peak. Everything that is going to be built must be built now; during peak the only job is execution.

I check whether it is them or the category before I say anything about cause. Pull their traffic, conversion and in-stock rate alongside the category trend over the same window, because if the whole category softened this is a market conversation and if only they softened it is usually their stock, pricing or a listing change. Most of the time it is something on their side and the platform is simply the visible thing to blame, so I bring the comparison rather than a defense and let the data carry it. And when it is genuinely us, I say so first, before they find it.

The customer bought an outcome, not a diagram of who does what, so I own the communication regardless of whose system failed. That means giving the resolution and the compensation rule without making them ask for it, since forcing someone to request what they are owed is where goodwill actually dies. Separately and invisibly to them, I take the failure data to the partner and drive the root cause with evidence rather than complaint. What I never do is explain our internal boundaries to a customer as a reason for the delay.

There is no universal number, and anyone who gives you one is quoting a different business. The way to reason about it is contacts per order multiplied by cost per contact, measured against contribution margin per order, because that tells you whether service is eating the unit or not. The lever with the most room is almost always contacts per order, and that is a product and operations problem rather than a support efficiency one. Chasing cost per contact in isolation usually degrades resolution quality, which raises repeat contacts, which raises the total. I would want to see the repeat contact rate next to any cost target.

Not simply the largest, which is the reflex answer. I would rank by revenue at risk weighted by how substitutable they are, because a mid-sized merchant with a catalog nobody else carries can be harder to replace than a large one selling commodity stock available from twenty others. I would also weight by whether the situation is recoverable, since spending the scarce hours on an account that has already decided is sentiment rather than strategy. Then I would make the decision visible instead of quietly letting the others slip, because an explicit tier people can see is survivable and silent neglect is not.