Technical customer success fundamentals

Support is reactive and ticket-shaped: a customer has a problem, raises it, and the interaction ends when the problem is resolved. Customer success is accountable for whether the customer gets the business result they bought, which nobody raises a ticket about. That difference sets everything else. Support is measured on resolution time and satisfaction per interaction, customer success on retention, adoption and expansion across a contract term. It also means a customer success manager can be doing badly while every ticket is closed on time, because the account is quietly not using the thing it paid for. The cost of the model is that the outcome depends heavily on decisions inside the customer's organisation that you can influence and cannot control.

Candidates quote net retention as a single figure without being able to say what went into it, which an interviewer tests by asking for the arithmetic.

Cohort: the 10 accounts you had at the start of the year
Starting annual recurring revenue          1,000,000

During the year:
  2 accounts churned entirely                -140,000
  1 account reduced its licence count         -30,000
  4 accounts expanded seats or modules       +220,000
                                            ---------
Ending ARR from that same cohort              1,050,000

Gross retention = 1,000,000 - 140,000 - 30,000 = 830,000
                  830,000 / 1,000,000 = 83%

Net retention   = 1,050,000 / 1,000,000 = 105%

Two numbers, one cohort, and the difference between them is the whole story. Gross retention counts only losses and is therefore capped at one hundred per cent; it answers "how much of what we had did we keep". Net retention adds expansion back in and can exceed one hundred; it answers "did this cohort grow".

The trap is reading the net figure alone. At 105% net and 83% gross this business is losing roughly a sixth of its revenue base every year and covering it with growth inside the surviving accounts. That works while the expansion holds and collapses the moment it does not, because expansion is concentrated in a handful of accounts while the losses are spread across many. An interviewer asking about this is checking whether you understand that a healthy net figure can conceal a retention problem that will surface a year later.

Two more details matter. New customers acquired during the year are excluded, otherwise you are measuring sales rather than retention. And the cohort must be fixed at the start of the period, or a shrinking denominator flatters the result.

Logo churn counts customers lost, revenue churn counts money lost, and the two diverge whenever your customers are different sizes. A business can lose a quarter of its logos and almost none of its revenue if the departures are small accounts, or lose one logo and a tenth of its revenue if that logo was an enterprise. Reporting only one of them is how a board gets a misleading picture. The pair is diagnostic when read together: high logo churn with low revenue churn usually points at a weak self-serve or small-business segment, while the reverse points at a concentration risk in a few large accounts and a real problem in enterprise delivery.

Time-to-first-value is the interval between a contract starting and the customer getting a result they would notice if you took it away. The definition matters more than the measurement, because the temptation is to declare value at a milestone you control — provisioning done, training delivered, integration connected — none of which is value to the customer. The customer decides, and the useful test is whether a named person inside their organisation could describe the benefit to their own manager without mentioning your product's features. Defining it credibly forces you to know what the account bought for, which is why interviewers ask about it.

A health score compresses several signals about an account into one comparable number so that a team carrying dozens of accounts can decide where to spend its week. That is its only real purpose, and it is worth saying so, because the common misuse is treating the score as a prediction. It is a triage tool: a red account is an instruction to go and look, not a conclusion. The cost is that any weighted composite can be gamed and can average away the one signal that mattered — an account can score well overall while its executive sponsor has gone silent, which is the single most predictive signal there is.

Interviewers ask because candidates apply for one and describe another, and because the same title means different things at different companies.

Role                     Owns                  Measured on        Technical depth
-----------------------  --------------------  -----------------  -----------------
Customer success         Adoption and the      Retention,         Enough to be
manager                  customer's outcome    adoption, health   credible, not
                                                                  to debug

Account manager          The commercial        Renewal and        Often little
                         relationship          expansion revenue

Technical account        The technical         Escalation         Real, including
manager                  relationship and      outcomes and       logs and APIs
                         escalations           technical adoption

Solutions or             Getting it live       Time to go-live,   Deep, hands-on
implementation engineer   and integrated       integration        build work
                                               quality

The rows overlap in practice and the boundary is drawn differently at every company, which is why the first question to ask in an interview is which of these the role actually is. A CSM job that carries a revenue quota is an account manager with a friendlier title, and a technical account manager role with no log access is a CSM. The distinction changes how you should prepare: a genuinely technical role will put you in front of an engineer who asks how you would investigate a failing integration, while a relationship role will spend the loop on stakeholder scenarios and commercial judgement.

Read down the measured-on column rather than across the rows, because that column is what actually decides behaviour. Anyone measured on revenue will eventually prioritise the conversation that moves revenue, and anyone measured on adoption will keep working an account that has already decided to leave. When one person holds two of these columns at once, which small companies do routinely, the tension is not resolved by the org chart — it is resolved by whichever number their manager asks about first.

Seniority moves along a different axis. A strategic or enterprise CSM carries fewer accounts with deeper executive relationships and is expected to influence the customer's own roadmap; a scaled or pooled CSM carries hundreds and works through programmes, campaigns and in-product guidance rather than named relationships.

A business review is a scheduled conversation with the people who fund the contract, about whether it is delivering. What makes it worthless is treating it as a usage report: a deck of adoption charts tells a sponsor what their own staff did, which they can get elsewhere and do not care about. What makes it valuable is arriving with a claim about their business, evidence for it, and a decision you want from them. The best ones end with the customer taking an action inside their own organisation. It is also the only reliable mechanism for discovering that your sponsor has changed priorities before the renewal tells you.

Land and expand is a go-to-market pattern where the first contract is deliberately small — one team, one use case, one region — and growth comes from repeating it elsewhere inside the same customer. It shifts the hard work from selling to proving, which is why it puts customer success on the critical path for revenue rather than beside it. The practical consequence is that the first deployment is a reference asset, not just a deployment: it needs a result someone will vouch for internally. The cost is that a badly chosen landing team can poison the whole account, because the next team's first question is what the first team thought.

Beyond the tasks, an onboarding plan needs four things a task list does not carry: the business outcome the contract was signed for, in the customer's own words; the named owner on their side for every dependency you do not control; a definition of go-live that someone could disagree with before it happens rather than after; and the date by which first value should be visible. Plans without these produce the characteristic enterprise failure of a technically complete rollout that nobody uses. It should also record what is deliberately out of scope for phase one, because the alternative is a quiet reinterpretation at the end about what was promised.

Candidates describe onboarding as a sequence of meetings, which tells an interviewer nothing about what is actually being de-risked and when.

Week 0     Handover from sales. Read the deal: the business case, the
           promises made, the sponsor, the compromises. Get the gaps in
           writing before the first customer call, not after.
Week 1-2   Kickoff with sponsor present. Confirm the outcome, name owners
           on both sides, agree the go-live definition and the first-value
           date. Identify every dependency you do not control.
Week 2-5   Technical setup: tenancy, SSO, provisioning, the integration.
           This is where the customer's security review and their data
           feed become the critical path, not your product.
Week 5-7   Configure the actual workflow with the team that will use it.
           Not a demo environment. Their data, their edge cases.
Week 7-9   Pilot with a real deadline. Watch where people fall back to
           the manual route and fix that specifically.
Week 9-12  Go-live for the landing team, first value confirmed by a named
           person, and a written baseline to measure the next quarter from.

Two things in that shape are worth defending in an interview. The critical path runs through the customer's organisation, not yours: security review, data access and the availability of the people who know the workflow are the usual causes of slippage, and none of them are yours to schedule. Recognising that in week one and escalating early is the difference between a delayed onboarding and a failed one.

The second is that the pilot has a real deadline attached. A pilot with no consequence generates polite feedback and no information, because nobody discovers the blocking problem until it blocks something. The week 7 to 9 window exists to surface the manual fallback while there is still time to remove it.

What the plan deliberately does not do is train everybody early. Enablement delivered before the workflow is configured is forgotten by the time it is needed, and it converts your onboarding into the thing people remember as confusing.

Scope gets cut because go-live dates are fixed by contract or by a sponsor's internal commitment while the customer-side dependencies slip. Cutting the ambitious use case in favour of an easy one is the fatal choice, because the easy one was not what the budget was approved for and therefore produces no result anyone defends. Cutting reporting, secondary integrations, or the second region is usually survivable. The way to protect yourself is to write down at kickoff which element of scope is load-bearing for the business case, so the conversation about cutting it happens with the sponsor rather than between two project managers.

The customer's sponsor, on evidence you supply. That sounds like a dodge and it is the opposite: it forces the go-live criteria to be written in advance in terms the sponsor recognises, which is the only thing that stops go-live becoming whatever was ready on the date. Your job is to make the decision informed — what works, what does not, what the workaround is, what the risk of proceeding is — and to have said all of it in writing beforehand. Where this goes wrong is a vendor declaring go-live to hit its own internal milestone, which transfers the whole risk to the customer without telling them.

A project plan tracks work to completion; a success plan tracks a customer towards an outcome and therefore outlives go-live. It names the business result, the measure of it, the baseline, the owners on both sides, and the checkpoints where you will jointly review whether it is happening. The important structural difference is that a success plan can be failing while every task is complete, and that is precisely the state it exists to make visible. It is also the document that makes a renewal conversation short, because the evidence has been accumulating in it for a year rather than being assembled in the last month.

A vague definition of value is what lets everyone declare success and then wonder why usage is flat six months later.

Weak:   "Customer is onboarded and the integration is live."
        Measurable, controlled entirely by us, and worth nothing
        to the customer.

Better: "The nightly feed from their warehouse lands without manual
        intervention for five consecutive business days."
        Real, but still a statement about plumbing.

Strong: "The reconciliations team closes month-end using our output
        instead of the two spreadsheets they maintain today, and
        the finance manager signs it off without a manual check."

Baseline recorded at kickoff:
        - 2 spreadsheets, maintained by 3 people
        - close takes 6 working days
        - 4 manual corrections in the last close

First value = first month-end closed from our output, with the
              spreadsheets not maintained in parallel.

The progression is the point. Each version is more work to define and harder to claim, and each is worth proportionately more at renewal. The strong version names a team, a recurring business event, and something the customer stops doing — that last element is what makes it undeniable, because a customer who has retired a spreadsheet cannot quietly conclude the product added nothing.

Recording the baseline at kickoff rather than reconstructing it later is what makes the claim survive contact with a sceptical finance director. Nobody remembers accurately how long the close took before, and a number you produce in month eleven with no provenance is treated as marketing.

Note also the phrase about parallel running. Customers frequently keep the old process alive alongside the new one, which is prudent and means value has not been delivered yet. Until the fallback is switched off, you have added work rather than removed it.

Everything the customer was promised that was not written into the contract lives only in the account executive's head, and a thin handover loses it. The three expensive losses are the real business driver behind the purchase, any commitment made verbally about capability or timing, and the political map of who wanted this and who resisted it. The failure surfaces weeks later as a customer expecting something you did not know about, and you cannot dispute it credibly because you were not in the room. The fix is a handover that is a conversation with written output, including an explicit question about what was promised that is not in the order form.

Adoption means the product is doing load-bearing work in a process the customer would have to replace if you disappeared. Logins measure attendance, and they can move in the wrong direction as adoption deepens, because a team that automates through your API stops visiting your interface. The useful measures are behavioural and specific to what the product is for: the share of eligible transactions flowing through it, whether the previous tool has been retired, whether the output is accepted downstream without a manual check. Those are harder to instrument, which is exactly why teams default to logins and then draw wrong conclusions from them.

Because people who used the product competently during onboarding did not forget how. If they stopped, stopping was rational: a step slower than the manual alternative, an approval they could not obtain, output their manager would not accept, a colleague who told them the numbers were wrong. Training addresses none of those, and offering it implies the problem is their competence, which is an expensive thing to suggest to a customer before a renewal. It is the default remedy because it is the one a CSM can deliver without anyone else's help, which is a reason it gets chosen and not a reason it works.

The instinct is to book an enablement session. The discipline is to establish what kind of problem it is first, because four different causes produce the same flat line.

flowchart TD
    A[Usage flat] --> B{Does telemetry capture<br/>work we know happens}
    B -- no --> C[Instrumentation defect<br/>re-baseline before acting]
    B -- yes --> D{Sponsor and champion<br/>still in post}
    D -- no --> E[Account changed hands<br/>rebuild the business case]
    D -- yes --> F{Is the live use case<br/>the funded one}
    F -- no --> G[Wrong workflow shipped<br/>re-scope]
    F -- yes --> H[Find the manual fallback<br/>and remove the blocker]

The branch candidates never check is the third. An account can pass every onboarding checklist, show real usage, and still be worthless to the customer, because enterprise deals are routinely sold on an ambitious use case and implemented on whichever one could go live inside the window. Everyone declares victory, and the workflow in production is not the one the budget was approved for, so no visible business result is produced and nobody defends the spend when attention moves elsewhere.

The first branch is worth an hour before anything else. Take one task you know the account performs, find it in the data, and confirm it appears. Proxies that broke client-side collection, an SSO migration that created a second tenant, a move from your interface to your API — each produces a flat line with no customer meaning at all, and opening a disappointment conversation with a customer who is not disappointed is difficult to walk back.

The final leaf is the one that leads to actual work. When people fall back to a manual route, they have told you precisely which step failed them, and they will usually say which if asked directly rather than surveyed.

A champion is the person inside the customer who does the internal work your product needs: answering colleagues' questions, defending the spend in planning, and carrying the narrative for why the tool exists. When they leave, all three go at once and the account looks fine for a quarter before the consequences appear. The response is not to find a friendly user and relabel them. It is to establish whether anyone currently inside the customer can explain the purchase, and if not, to rebuild the business case with whoever inherited the budget — which is a fresh sale conducted without a sales process.

By producing a result the second team's manager finds credible, then removing the reasons the second team would say no. Those reasons are usually not about your product: it is somebody else's data, a different approval chain, a team whose incentives point elsewhere. The mechanism that works is a documented outcome from the pilot with a named person willing to be asked about it, plus a repeatable configuration so the second rollout costs a fraction of the first. What does not work is announcing the rollout from the sponsor's office without that evidence, which converts an opportunity into a mandate people quietly route around.

Aggregate usage hides every interesting failure, so the useful reading is shape rather than volume.

Shape                  What it looks like            What it usually means
---------------------  ----------------------------  -------------------------
Concentration          Deep use by three people,     A pilot that never
                       200 licences provisioned      became a rollout

Weekly export spike    Heavy activity Friday,        Real work happens in a
                       silence otherwise             spreadsheet

Read-only              Logins and dashboards, no     Nobody has changed a
                       writes or actions             process yet

Breadth without depth  Many users, one shallow       Enablement happened,
                       feature each                  workflow did not

Plateau after go-live  Rises to a level in week      Adoption stopped at the
                       two, never moves              landing team

Each row implies a different intervention, which is the point of reading shape at all. Concentration is a rollout problem and needs the second team's manager, not more licences. The export spike is the most actionable of the five, because it identifies the exact step of your product a team gave up on and it is usually one report or one bulk operation away from being fixed.

Read-only usage is the most dangerous to misread, because it looks like engagement and is in fact a decision not to depend on you. A customer who only reads has kept its old process running, and the renewal conversation will discover that nothing was retired.

The plateau shape is worth checking against the licence count rather than against a target. If usage plateaued exactly at the size of the landing team, the account is not stalled, it is un-expanded, and that is a different conversation with a different person.

Breadth is how much of the organisation touches the product, depth is how much of a workflow it carries. They fail differently and are frequently confused when reporting to an executive. Wide and shallow means enablement worked and nothing was rebuilt around you, which is fragile: nobody would notice its removal. Narrow and deep means one team genuinely depends on you, which is durable but small and vulnerable to that team reorganising. A healthy enterprise account grows depth first, in one team, and uses that as the argument for breadth — the reverse order produces an impressive user count and a renewal nobody will defend.

By converting a conclusion into a symptom without contesting the conclusion. An escalation arrives asserting the product is broken, and arguing with that in the first exchange means everything you say afterwards is heard as defence. Instead be specific about the observable: which request or action, at what time, in which environment, with which identifier, and what was expected instead. Nobody has to concede anything to describe a symptom. It is also the fastest technical route, because escalations run long mainly when the two sides are looking at different traffic, and one shared identifier ends that in an hour.

By bisecting the path with evidence the customer can generate without you, because a finding they produced is one they will accept.

sequenceDiagram
    participant App as Their application
    participant Proxy as Their gateway
    participant Edge as Your API edge
    participant Log as Your logs
    App->>Proxy: Request with the header set
    Proxy->>Edge: Header rewritten in transit
    Edge->>Log: Records what arrived
    Log-->>App: Same request id, different payload

The hop their engineer cannot see is the middle one. What leaves an application and what reaches your edge are two different things, and the infrastructure in between is nobody's declared responsibility — which is why most escalations that look like product defects live exactly there: a rewritten or stripped header, a retry that changed the HTTP method, a certificate chain that only fails from one region, a body truncated by a size limit.

The practical experiment is to remove their infrastructure from the path. Ask them to issue the same call from a laptop with a plain HTTP client and the same credentials, then compare it against what their pipeline sends. If the laptop succeeds and the pipeline does not, the boundary question is answered and you never had to assert anything; the experiment did it.

Intermittency is a signal in itself rather than a mystery. A fault on some requests and not others is usually the shape of several client instances behind a load balancer where one carries stale configuration, or of a change rolled out to part of a fleet.

Before concluding, check your own side in the window when the symptom started: a release, a config rollout, a rate-limit threshold, a certificate rotation, a deprecated field that quietly began returning a different status. Enterprise customers are entitled to that check, and skipping it means eventually being wrong in the one case where it mattered.

What changed and when, on both sides, and whether "failing" means errors, timeouts, or wrong results — three different investigations that arrive in the same sentence. Get the exact status code and body rather than a paraphrase, because a 401, a 403 and a 429 tell three different stories and customers report all of them as "rejected". Then bound it in time: the first failure's timestamp lines up against your release log and their deployment log, and one of those two usually contains the answer. Credential and certificate expiry deserve an early look because they produce sudden total failure with no code change on either side.

Because the failure happens in the customer's infrastructure while the symptom appears as your product not sending something. The usual causes are a receiver returning a non-2xx status so deliveries are retried and then dropped, a firewall or allow-list change on their side, a signature verification that broke when a secret rotated, or a handler that is not idempotent and therefore corrupts state when a legitimate retry arrives. From the customer's seat all of these look identical to missing events. Delivery logs on your side, showing what was attempted and what was returned, resolve most of them immediately, which is why asking for them first is the habit worth having.

An engineer receiving a customer escalation needs to reproduce it or rule it out, and most write-ups make both impossible.

Impact       Which customer, which environment, how many users or
             records affected, and what business process is blocked.
             State whether there is a workaround in place.

Symptom      The observable, with a request id and timestamp, plus the
             exact status and body. Not "the API is failing".

Scope        Is it one tenant or several. One endpoint or many. Started
             when, correlated with which release or config change.

Ruled out    What you already checked: credentials, rate limits, their
             proxy, the plain-client reproduction, the delivery log.

Ask          What decision you need and by when. A fix, a diagnosis, a
             workaround, or confirmation that behaviour is intended.

The section that earns you standing with an engineering team is the fourth. It says you spent your own time before spending theirs, and it stops the reply that begins "have you checked". Over a few escalations it changes how fast your tickets get picked up, which is a form of internal credit that is slow to build and quick to lose.

The impact line matters for a less obvious reason: it is what allows an engineer to prioritise honestly against other work. "Blocking the month-end close for a customer's finance team, no workaround" is a fact anyone can act on, while "customer is very unhappy" is pressure without information and is discounted accordingly.

The final section prevents the commonest failure of all, which is a ticket that describes a situation and never states what is being asked for. It then sits, correctly, behind everything that did.

Far enough to have narrowed the problem to one side of a boundary and to have eliminated the obvious environmental causes, and no further. The useful threshold is whether your next step requires code or data you cannot see; at that point continuing is guesswork dressed as diligence and the delay is costing the customer. Under-investigating burns engineering time and your own standing, but over-investigating is the more insidious failure because it is invisible and feels responsible. The judgement an interviewer is testing is whether you can say what you checked, what it ruled out, and precisely why you stopped there.

The technical finding is the easy half. The hard half is that a named engineer configured something wrongly and then escalated to their own management claiming a vendor defect.

Finding to deliver: a header their application sets is absent at our edge.

Avoid    "This is not a bug, your header is missing."
Instead  "We traced the id through both sides. It is set in your
          application and absent at our edge, which points at the hop
          in between."

Avoid    "Your team misconfigured the retries."
Instead  "The retries arrive as GET rather than POST, a known default in
          some proxies, and it explains every failed record."

Avoid    "No product defect was found."
Instead  "Root cause is in the request path. Here is the change, how we
          verified it, and what we are fixing so that it fails loudly
          next time."

The second line of each pair describes a mechanism instead of allocating blame, uses the plural where the investigation was genuinely shared, and carries something you are changing too. That last element is not politeness. It is what lets the customer's director read the update as a resolved joint investigation rather than as a vendor scoring a point off their own staff.

The sequencing matters as much as the wording. Take the finding to the engineer alone before it is written anywhere, agree together what the written update says, and let them send it. Your own summary stays factual about the mechanism and silent about fault.

Say the awkward part on a call and never first in writing, because written words are forwarded without their tone and a sentence that was gentle in conversation reads as an accusation to someone who was not in it. The engineer you protect here is the same one you will depend on for every future integration, and that is a self-interested reason as much as a decent one.

A composite score is a triage tool, and reading it as a prediction is the standard error.

Weighted score for one account:

  Product usage depth      30%   score 8/10  ->  2.4
  Breadth vs licences      15%   score 3/10  ->  0.45
  Sponsor engagement       25%   score 2/10  ->  0.5
  Support and escalations  15%   score 9/10  ->  1.35
  Success plan progress    15%   score 7/10  ->  1.05
                                              -------
  Composite                                     5.75/10  = amber

The arithmetic is unremarkable and the interesting part is what the average destroyed. Sponsor engagement at 2 out of 10 means the person who funds the contract has stopped turning up, which on its own is close to decisive, and the composite has diluted it into an amber that competes for attention with a dozen other ambers.

That is the general failure of weighted scores: they average a categorical risk against continuous ones. Some signals are not contributions to a score, they are gates. No executive sponsor, a champion who has left, a security incident, or a renewal inside ninety days with no conversation started should each turn an account red regardless of everything else.

The second failure is that most inputs are lagging. Usage, tickets and plan progress all describe what has already happened, and by the time they move the decision inside the customer has often been taken. The leading signals are relational and awkward to quantify: who replies, who attends, whether you are still invited to their planning, whether a new name from a competitor has appeared in a meeting.

Used properly the score answers one question — which five accounts do I look at this week — and every conclusion after that comes from looking, not from the number.

Because the inputs are mostly lagging and mostly generated by users, while churn decisions are taken by people who never appear in your telemetry. An account can show steady usage from a committed team right up to a budget review that eliminates the spend for reasons unrelated to the product: a reorganisation, a merger, a platform consolidation, a new CIO with a standard. The corollary for interviews is that a candidate who monitors only product signals will be surprised by every strategic churn. The signals that lead are relational, and the discipline is to treat a sponsor's silence as more serious than a dip in usage.

A silent account is one generating no tickets, no questions and no meeting requests, which is easy to read as contentment and is more often disengagement. The distinction is whether the silence is accompanied by depth of use. A team that uses the product heavily and asks nothing has genuinely absorbed it; a team that uses it lightly and asks nothing has stopped caring, and nobody is going to tell you. Silence also removes your information supply, so you learn about the reorganisation, the competitor evaluation and the budget cut at the same time as the notice. Manufactured contact with a real purpose is the only remedy.

An escalation is a live problem the customer has raised and expects action on; a risk is your judgement that the account may not renew or may reduce, which the customer may not have voiced at all. They need different handling and are constantly conflated. Escalations have owners, clocks and a resolution; risks have a hypothesis, a mitigation plan and a review date. The important asymmetry is that an escalation is visible to everyone by definition while a risk is only visible if you raise it, and the failure mode is a CSM who carries a private worry for a quarter and surprises their own leadership with it.

A named cause rather than a mood, the specific evidence for it, the one thing that would have to change for the risk to clear, an owner for that change on each side, and a review date early enough to try twice. Plans fail when the cause is stated as a sentiment — "the sponsor is unhappy" — because nothing follows from it. Plans also fail when the mitigation is entirely yours, since most churn causes have a customer-side dependency, and a plan that does not ask the customer for anything is a plan the customer is not part of. The review date should sit well before the notice window.

As soon as you have a specific reason rather than an impression, and always early enough that a response is still possible. The instinct is to wait until you have a plan, which is exactly wrong: the value of an early warning is the options it preserves, including executive contact, engineering effort and commercial flexibility, all of which need lead time. The professional standard is that nobody senior should ever learn of a risk from the customer. Raising it with a hypothesis and an ask is not an admission of failure, and treating it as one is how a manageable risk becomes a surprise churn.

A save play is a deliberate intervention on an account you expect to lose: executive contact, a scoped piece of engineering work, a commercial concession, or a re-implementation against the use case that actually matters. It is too late when the decision has already been made and communicated internally on the customer's side, because at that point you are asking someone to reverse a position in front of their colleagues, which is a much larger request than the original one. That is why the timing of risk detection matters more than the quality of the play, and why concessions offered late buy a delay rather than a save.

At the beginning of the term, which sounds like a slogan and is a description of where the evidence comes from. A renewal is decided by whether the customer got the result, whether a person is willing to say so, and whether the sponsor still has a reason to care — none of which can be assembled in the final month. What happens near the date is a commercial process, and its difficulty is set entirely by the previous eleven months. The practical version is that a success plan with a recorded baseline and dated outcomes turns the renewal conversation into a short one, and its absence turns it into an argument about impressions.

It varies by company and you should ask, because the answer changes the job substantially. Where CS carries the renewal number, the role has a commercial edge and a quota-like pressure that shapes every conversation with the customer. Where sales carries it, CS supplies the evidence and the risk assessment while someone else negotiates, which protects the trusted-adviser position at the cost of some influence over the outcome. Neither is wrong. What is wrong is a company that has not decided, because then the renewal is owned by nobody until sixty days out, which is the pattern behind most avoidable churn.

A constraint the customer is already hitting. A team requesting access it does not have, licences fully consumed, someone building a workaround for a capability that exists in a tier they have not bought, a second department asking the first how it did something. These are observable facts about their behaviour rather than an opinion about their needs, which is what makes raising them legitimate rather than pushy. The test is whether the customer would recognise the problem before you named the product: if yes, you are helping them solve something they already have; if no, you are selling, and you should route it through someone whose job that is.

Interviewers ask this because candidates report a renewal as won or lost when most enterprise renewals are neither.

Renewing account, original contract:
  200 seats at 400 per seat                 80,000
  Premium support module                    15,000
                                            ------
  Total ARR                                 95,000

At renewal the customer:
  reduces to 150 seats                     -20,000   50 seats x 400
  drops premium support                    -15,000
  adds the reporting module                 +9,000
                                            ------
  Renewed ARR                                69,000

Retained: 69,000 / 95,000 = 73% of this account's revenue
Reported as: renewed, with 26,000 of downsell and 9,000 expansion

Called a win, this is a 27% net loss on the account, and the module addition disguises part of it. That is why gross and net retention are reported separately and why a renewal rate measured in logos is close to useless in an enterprise business.

The diagnostic question is which line moved and why. Fifty seats removed usually means fifty people were provisioned and never used it, which is an adoption failure that happened ten months earlier and was visible in the usage-per-licence figure the whole time. Premium support dropping is a different signal: either the value was never demonstrated, or the customer's own team became competent enough not to need it, and only one of those is bad news.

The expansion line is the one to be honest about internally. Nine thousand of new module revenue on an account that shed thirty-five thousand is not evidence that the account is growing, and presenting it that way is how a business ends up with a comfortable net retention figure sitting on top of a deteriorating base.

Most enterprise contracts renew automatically unless the customer gives notice a set period before the term ends, commonly one to three months. That window is the real deadline, not the term end, and it is the single most commonly missed date in customer success. Two consequences follow. Any risk work must be complete before the window opens, because after it a customer who has served notice is negotiating from a different position. And a customer who forgets the window and renews by default has not decided to stay, which is a fact worth knowing rather than a result worth reporting.

By finding out what the request is really about before answering it, because "we need a better price" is the polite form of at least three different situations: budget pressure unrelated to you, a genuine belief that the value does not match the price, and a procurement team doing its job. Each needs a different response. Where value is the issue, a discount treats the wrong problem and establishes a lower price for every future term. Where it is a procurement ritual, a small structured concession in exchange for something — a longer term, a reference, a case study — closes it. The concession you never make quietly is one with nothing asked in return.

Establish the real reason and record it accurately, because a churn reason is one of the few pieces of honest product intelligence a company gets and it is routinely softened into uselessness. Then run the exit properly: data export, offboarding, contractual obligations met, and the relationship preserved with the individuals, who will work somewhere else within a few years. Where the cause was a capability that is genuinely coming, say so plainly and leave the door open with a date rather than a hope. What you do not do is spend the remaining term on a save play whose only real function is to defer the loss past a reporting boundary.

By bringing evidence about the shape of the problem rather than the size of the account. How many other customers have asked for it and how similar their versions were, whether it is a segment characteristic rather than one customer's taste, what the workaround costs in support hours and professional services, whether its absence has already appeared in lost deals. State the revenue risk once, plainly, as one input. The reason to hold the account size back is that a team moved by it once will be asked for the same lever next quarter by everyone else, and a roadmap steered by whoever is loudest at renewal never ships anything difficult.

The difference between an ask that gets a decision and one that sits in a backlog is almost entirely in how it is framed.

Template for one ask, filled in for a bulk-correction request:

Business event that breaks
    Month-end close cannot complete inside their two-day window
    without correcting rejected rows in bulk.

Evidence
    Last three closes each needed 400+ single-row edits. Screenshot
    and the export are attached.

Other accounts affected
    Three in the same segment have asked for the same thing. Two of
    them described it as a blocker rather than a preference.

What we already tried
    A scripted workaround run by professional services. It works and
    costs us six hours a month per account, and it needs their data
    in our hands, which their security team dislikes.

The decision I need, and by when
    Is bulk correction on the plan, could it be, or is it a no?
    A no is usable. I need it before their renewal opens in
    eleven weeks so they can build a manual control instead.

A filled-in template does three things a one-line request does not: it names the business event that breaks, it separates blocking requests from preferences so product can decline part of it without declining all of it, and it asks a question with a decidable answer.

The section that buys you standing is the one recording what you already tried. It tells a product manager that the alternatives have been explored rather than that a customer complained loudly, and it converts the cost of the gap into a figure someone can compare against the cost of building. An ask without it reads as a request to be relieved of a difficulty.

That last point is the one candidates miss. "Can we build this" invites deferral. "Is it in the plan, could it be, or is it a no, and if it could be what would have to move" forces a real answer, and a real no is more useful to you than an indefinite maybe because it is something you can carry to the customer.

When the decision needed sits above the people currently in the room, or when a relationship has degraded to the point where the working-level conversation cannot recover it. Executive involvement is a limited resource that loses power with use, so it should arrive with a specific ask and a briefing, never as a gesture of seriousness. Two failure modes are common: escalating to your own executive without telling the customer, which they discover and read as going around them; and arranging an executive call with no decision to make, which consumes both sponsors' goodwill and teaches them that your escalations are theatre.

It pairs a senior person at your company with the customer's sponsor so a relationship exists above the working level before it is needed. Its real function is insurance: when something goes badly wrong, or when the customer's sponsor is replaced, there is an existing channel rather than a cold introduction during a crisis. It also gives you a route to hear about the customer's strategic changes early, which is where strategic churn comes from. It fails when the pairing is nominal — an executive who appears once a year, unbriefed, and asks a question the account team answered last quarter.

The boundaries are drawn differently everywhere, and confusion about them is where customers end up repeating themselves to four people.

flowchart TD
    C[Customer] --> S[Support<br/>ticket, break-fix]
    C --> CS[Customer success<br/>outcome and adoption]
    C --> PS[Professional services<br/>paid build work]
    S --> ENG[Engineering<br/>defects and fixes]
    CS --> PM[Product<br/>gaps and roadmap]
    CS --> S
    PS --> CS

The edge worth noticing is the one from customer success back into support. A CSM who bypasses the support queue to get a friendly engineer to look at something is solving today's problem by destroying tomorrow's: the issue is now invisible to trend reporting, unowned when they are on leave, and the engineer has learned that the queue can be skipped.

The other frequently blurred boundary is professional services. Work that is genuinely a paid build — a custom integration, a data migration, a bespoke report — delivered free by a CSM to save a renewal sets a precedent inside the account that every future request is free, and it makes the services organisation's pricing unenforceable.

What customer success uniquely owns is the outcome. Support owns incidents, services owns delivery, product owns the plan, and none of them is accountable for whether the customer got what they bought — which is why the role exists and why it has no authority over most of what it depends on.

Plainly, with a reason at the level you are permitted to give, with something concrete you will do instead, and with a statement of what would change the answer and when you will next discuss it. The third element is what candidates leave out and it is what converts a refusal into something the customer can act on. An undated maybe is worse than a no, because it removes their ability to plan: they cannot buy a point solution, brief their auditor, or resource a workaround, and they eventually learn the truth at the worst moment and conclude they were managed rather than told.

Say so early, in your own words, before the customer establishes it themselves. Specifically: what happened, what the impact on them was, what you have done, and what changes so it does not recur — and no explanation of internal process, which reads as excuse-making to someone whose month-end broke. Then be careful about the second incident, because a customer forgives a failure handled well and does not forgive discovering that the account team knew and shaded it. Where a commercial remedy is warranted, offer it rather than waiting to be asked; offered it costs a credit, requested it costs the relationship as well.

Typically a recruiter screen, a hiring-manager conversation about how you run accounts, one or two scenario rounds, a live exercise, and cross-functional interviews with support, product or sales depending on where the role sits. The live exercise is the round that decides it: usually a mock customer call — an escalation, a difficult renewal, a business review — where the interviewer plays the customer. For a technical role, expect a separate round with an engineer on how you would investigate a failing integration. Ask which of these the loop contains, because preparing for a relationship loop and getting a technical one is a common and avoidable failure.

Evidence of diagnosis rather than endurance. The weak version narrates how unreasonable the customer was and how patiently it was absorbed, which demonstrates temperament and nothing else. The strong version establishes what the customer was actually reacting to — a broken commitment, a missing capability, an internal position they had to defend — then what you did that changed the situation, what it cost, and what you would do differently. Interviewers are also listening for whether the customer stays a person in your telling. A story in which the customer is simply irrational usually means the diagnosis never happened.

The mock call is where most candidates lose the loop, usually by solving too early.

First 2 minutes    Establish the symptom and its business impact in the
                   customer's terms. Do not explain, do not defend, do
                   not offer a fix. Ask what has broken for them.

Next 3 minutes     Acknowledge specifically. Name the impact back, in
                   their words, so they know it landed. Then say what
                   you know, what you do not, and how you will find out.

Middle             Separate what is decidable now from what needs
                   someone not on this call. Give a real answer to the
                   first and a named owner and date for the second.

If it is a no      Say it. Give the reason at the level you can, offer
                   the concrete alternative, and state what would
                   change the answer.

Close              Recap the commitments with dates and owners, confirm
                   the customer agrees that is the list, and say when
                   you will next speak. Then send it in writing.

Two things in that shape are being scored. The first is the discipline of the opening two minutes: interviewers deliberately play a customer whose complaint is vague, and the candidates who fail are the ones who guess at a cause and start fixing it. Asking what has broken for them, and waiting, is the whole test.

The second is whether you commit to anything specific. A call that ends with sympathy and no dated owner is a call the customer will have to make again, and the interviewer, who has taken these calls for real, will notice immediately.

The written follow-up matters more than its size suggests. Saying you will send a summary, and what will be in it, is what separates someone who has run accounts from someone describing how they imagine it works.

What the CSM is measured on, and whether the number is theirs or shared. Specifically: does the role carry a renewal or expansion target, how many accounts and of what size, what the health-score model is and who acts on it, who owns the renewal commercially, and whether adoption is measured in a way anyone trusts. These answers describe the job far more accurately than the description does. A role measured on retention with a hundred accounts and no product influence is a different profession from one measured on outcomes across eight accounts, and the interview is your only chance to tell them apart.

Your book size and total contract value, your gross and net retention if you know them, the renewal outcomes you were personally accountable for including the downsells, one or two adoption results with a baseline attached, and the churn you experienced with its real cause. Vagueness here is read as either inexperience or ownership of nothing, and it is the fastest way to lose credibility in a senior conversation. Where you cannot disclose figures, give the shape and the ratio rather than a shrug — "eleven accounts, largest about a third of the book" answers the question without breaching anything.

Directly, with the real cause, including the part that was yours. Interviewers ask precisely because the answer is hard to fake: someone who has actually lost an enterprise account can say when they first knew, what they tried, what the customer told them at the end, and which earlier decision they would change. The failure modes are blaming the product, blaming the previous account team, or producing a churn that was entirely outside your control, which reads as evasion whether or not it is true. Claiming never to have lost one is worse, because it says either inexperience or absence of accountability.

A strong answer establishes the facts before acting. Sixty days is likely inside or near the notice window, so check the contract's notice date first; it changes the urgency more than anything else. Then find out whether the sponsor still holds the role, because their absence is more often a reorganisation than a judgement, and that is a different problem from displeasure. Meanwhile reconstruct the evidence of value from the success plan and its baseline, and identify who else inside the account would object to losing the product.

The action has two prongs. Reach the sponsor by a route that is hard to ignore but not aggressive — a short ask with a decision attached, or your executive sponsor to theirs — while building the case with the working-level people affected. Tell your own leadership immediately, with the facts and an ask, because at sixty days only the options needing lead time are left.

A weak answer sends a friendly check-in, waits, and treats silence as a communication problem to be solved with more communication. It never asks the two questions that decide everything: when notice is due, and whether the person has left.