The work of making sure a customer gets the result they paid for, after the sale and before the renewal: onboarding an enterprise, growing real adoption, running technical escalations across an integration boundary, and reading an account well enough to know a year early whether it will stay.
High demand18 min readCustomer success manager, Technical account manager, Enterprise customer success manager, Implementation consultant, Solutions engineer, Customer success engineer, Director of customer successUpdated 2026-08-10
Assumes you know: Enough technical literacy to read an API response, a log line and an error code without help, A working idea of how software is sold and contracted to businesses, Comfort holding a conversation with someone who is annoyed with you
Overview
What this area actually covers
Everything that determines whether a customer who has already bought your product
gets the result they bought it for. Concretely: taking an account over from sales
without losing what was promised, getting the product into live use inside the
customer's own processes, finding out why usage stalled and fixing the actual
cause, handling the escalation when an integration fails and nobody yet knows
whose fault it is, judging whether the account is healthy from evidence rather
than mood, and arriving at the renewal with something a sceptical finance director
will accept.
The clearest way to define it is by its two neighbours. On one side is support,
which is reactive and ticket-shaped: a customer notices a problem, raises it, and
the interaction closes when the problem is resolved. On the other is sales, which
ends at signature. Customer success occupies the space in between and inherits the
one obligation neither of them holds — that the customer actually gets value —
which nobody raises a ticket about and no contract clause guarantees. A customer
success manager can be failing badly while every ticket is closed within its
target and every invoice is paid, because the account has quietly stopped using
the thing it bought.
The word technical in front of the title is doing real work, and it is the first
thing to establish about any role in this area. A technical customer success role
puts you inside the mechanics: reading a failed webhook delivery log, working out
whether a corrupted payload was mangled by the customer's own gateway, writing an
escalation that an engineer can act on, designing a data feed with the customer's
platform team. A relationship-oriented role in the same nominal discipline spends
its time on stakeholder maps, business reviews and commercial negotiation. Both
are legitimate and both are called customer success. They hire differently, they
interview differently, and preparing for one and being interviewed for the other
is a common and entirely avoidable failure.
What gets wrongly bundled into this area is worth naming. Account management is
not the same job: it owns the commercial relationship and is measured on renewal
and expansion revenue, which is a different set of incentives even when one person
holds both titles. Professional services is not the same job either: paid build
work — a custom integration, a data migration, a bespoke report — has a price and
a delivery contract, and a customer success manager who does it free to save a
renewal has taught the account that every future request is free. Support is not
the same job, and the boundary is the one customers most often notice breaking,
because a customer success manager who bypasses the support queue for a friendly
engineer has made the issue invisible to trend reporting and unowned the moment
they take leave.
There is one more boundary, and it decides whether someone is good at this. This
area is not about being liked. Being liked is a by-product of being useful, and a
great deal of the actual work is telling a customer something they do not want to
hear: that the configuration causing their outage is theirs, that the capability
they are waiting for is not coming, that the fifty licences they are paying for
were never used. The people who do this well are not the most agreeable ones. They
are the ones whose statements turn out to be true.
Now practise it
3 interview questions in Technical Customer Success, each with the rubric the interviewer is scoring against.
This section currently has one subsection, Enterprise Adoption, and the narrowness
is deliberate rather than a gap. The material an interviewer actually probes for a
technical customer success role clusters tightly around one thing — whether the
product is doing load-bearing work in a large organisation's processes — and
everything else on the loop is a variation on it.
Subsection
What it is for
Enterprise Adoption
Driving real product usage inside a large customer, and the technical troubleshooting that adoption depends on
Enterprise Adoption covers the whole arc from a signed contract to a workflow
that would break if you disappeared, plus the debugging that keeps that workflow
alive. It exists as its own subsection because adoption in an enterprise is not
the same problem as adoption in a self-serve product. In a self-serve product the
person who chooses the tool is the person who uses it, so if it is good they keep
using it. In an enterprise the person who chose it, the person who funds it, the
person who must integrate it and the people expected to use it are four different
sets of people with different incentives, and every one of them can stop adoption
without anyone deciding to.
What a reader will find inside is scenario work rather than definitions. The three
situations it currently carries are the ones that come up most in interviews for
this kind of role, and each is a different failure archetype. The first is an
account whose usage has gone flat after an onboarding everyone declared
successful, which is really a question about whether you can distinguish four
different causes that produce the same flat line: broken instrumentation, a
sponsor who has left, the wrong workflow having been shipped, and a team quietly
falling back to a manual route. The second is a customer who is certain they have
found a product bug, which is a question about bisecting an integration boundary
using evidence the customer can generate themselves, and about what you say when
the finding turns out to point at their own gateway. The third is a renewal at
risk on the strength of a feature the roadmap does not contain, which is a
question about how you ask product for a decision rather than a favour, and about
whether you can carry a real no back to a customer without either hiding it or
weaponising it.
Those three are worth treating as a set, because the same underlying skill runs
through all of them: separating what you can observe from what you have inferred,
and saying which is which out loud. Interviewers in this discipline are almost
always testing that separation, whatever the scenario on the surface.
Where it sits in a real business
Follow the money and the work will make sense. A business signs a contract for a
term, usually a year or multiples of it, and books the annual recurring revenue.
That revenue is not earned at signature — it is at risk for the whole term and it
recurs only if the customer chooses to let it. Sales creates it once; customer
success is the function that decides whether it keeps arriving, and whether more
arrives from the same account. That is why the function exists as a cost centre
that behaves like a revenue one, and it is why it has almost no authority over the
things it depends on.
Structurally, customer success sits at the junction of four internal functions and
one customer, and it owns something none of the others does.
Loading diagram…
The edge to look at is the last one. Every other arrow leaves customer success and
lands on someone who can say no, and the only arrow that decides the outcome
belongs to a person outside your company entirely. Influence without authority is
not a soft description of this job, it is the structural fact of it.
The value chain inside the customer matters just as much, and it is where a purely
relationship-driven approach runs out. The contract was funded because someone
believed a specific business process would get faster, cheaper or safer. That
process belongs to a team, the team has an existing way of doing it, and the
existing way works well enough that nobody will abandon it under mild
encouragement. Adoption therefore means displacing something — a spreadsheet, a
manual reconciliation, a nightly script somebody wrote and nobody maintains — and
the moment of real value is the moment the old thing is switched off. Until then
you have added work rather than removed it, which is why parallel running is the
most polite form of failure in this business.
A contract term walked end to end
The term has a shape, and the shape is the same across most enterprise software.
Knowing it is what lets you answer "when does renewal work start" without sounding
like you are reciting a slogan.
Loading diagram…
The interesting part of that chain is not any single box, it is where the critical
path runs. Between kickoff and technical setup, control passes to the customer's
organisation: their security review, their data access, the availability of the
people who understand the workflow. None of it is yours to schedule, all of it
slips, and the contractual go-live date does not move. That mismatch is the origin
of the characteristic enterprise failure — a technically complete deployment of
whichever use case could be delivered inside the window, rather than the ambitious
one the budget was actually approved for.
The second thing to notice is the gap between the last two boxes. Most enterprise
contracts renew automatically unless the customer gives notice a set period
before the term ends. That notice window, not the term end, is the real deadline,
and it is the single most commonly missed date in the discipline. Any risk work has
to be finished before it opens, because a customer who has already served notice
is negotiating from a completely different position — and a customer who forgets
the window and renews by default has not decided to stay, which is worth knowing
rather than celebrating.
Who does this work
The titles overlap and every company draws them differently, which is why the
first question to ask in an interview is which of these the role really is.
Role
Owns
Measured on
Technical depth expected
Customer success manager
Adoption and the customer's outcome
Retention, adoption, health
Enough to be credible, not to debug
Technical account manager
The technical relationship and escalations
Escalation outcomes, technical adoption
Real — logs, APIs, integrations
Customer success engineer
Hands-on technical problem solving for named accounts
Time to resolution, technical adoption
Deep, close to support engineering
Implementation consultant
Getting it live and integrated
Time to go-live, integration quality
Deep, hands-on build work
Account manager
The commercial relationship
Renewal and expansion revenue
Often little
Director of customer success
A team, a book of revenue, the operating model
Net retention, team performance
Enough to govern, not to execute
Read the measured-on column rather than across the rows, because that column
decides behaviour. Anyone measured on revenue will eventually prioritise the
conversation that moves revenue; anyone measured on adoption will keep working an
account that has already decided to leave. A customer success role carrying a
revenue quota is an account manager with a friendlier title, and a technical
account manager role with no log access is a customer success manager. Both exist
and both advertise under whichever name is fashionable.
A day in a technical version of the role looks like this. A block of the morning
on an escalation from the previous evening — pulling delivery logs, matching a
request identifier across two systems, working out whether the truncated payload
was truncated before or after it left the customer's estate. An hour preparing an
ask to product with evidence attached, because a capability gap has now blocked
the same business process at three accounts. A call with a customer's platform team
about a data feed nobody has documented. Then the unglamorous half: chasing a
security review, writing up a risk with a named cause, and noticing that one
account's usage per licence has been drifting downwards for two months.
Seniority moves on a different axis from technical depth. A strategic or
enterprise customer success manager carries a handful of large accounts with
genuine executive relationships and is expected to influence the customer's own
roadmap. A scaled or pooled one carries hundreds and works through programmes,
in-product guidance and campaigns rather than named relationships — which is a
different profession using the same vocabulary, closer to lifecycle marketing than
to account management.
Demand, adoption and how that is changing
Demand is high, and the reason is structural rather than fashionable. Subscription
and consumption pricing moved the majority of a software vendor's revenue after
the signature rather than at it, which makes retention an existential concern
instead of an administrative one. Once a business depends on customers choosing to
stay, someone has to own whether they get value, and that ownership cannot sit
inside a support queue measured on ticket closure or inside a sales team measured
on new bookings. Every company with recurring revenue eventually builds this
function, usually after its first bad renewal quarter.
Two things about the shape of that demand matter more than the level. First, the
technical end of the discipline is the resilient end. When budgets tighten, a
relationship-only role with no technical depth is the easiest role in a
go-to-market organisation to consolidate, because its activities can be
redistributed to account management and to in-product guidance. A role that
resolves integration failures, designs data feeds and writes escalations engineers
act on is much harder to remove, because the work does not disappear when the
person does. If you are choosing where to aim, aim at the technical end.
Second, the scaled or pooled model is genuinely absorbing the low end of the
market. Accounts too small to justify a named person are increasingly served by
automated lifecycle programmes, in-product onboarding and self-serve enablement,
managed by a smaller number of people who design programmes rather than run
accounts. That is a real shift and it cuts both ways: fewer named roles at the
small-account end, more demand for people who can build the programmes, and no
effect at all on the enterprise end, where a single account's renewal is large
enough to justify a person and the integration work is too bespoke to automate.
What is not happening, despite persistent claims, is the replacement of the
judgement part of the job. Usage telemetry, health scoring and automated
outreach have been available for years and they have not reduced the need for
someone to work out why a workflow was abandoned, because the reason is almost
never in the telemetry. It is in a conversation with a person who found the manual
route faster.
What makes it hard
The genuine difficulty is that you are accountable for an outcome produced inside
an organisation you have no authority over, using resources you do not control,
and you find out whether you succeeded a year later. Every part of that sentence
generates a specific hardness.
Diagnosis is the first. A flat usage line has at least four unrelated causes and
they look identical in a dashboard: instrumentation that broke, a champion who
left, the wrong workflow having been implemented, and a team that found a faster
manual route. The instinct is to run an enablement session, which is the one
intervention that addresses none of the four, and which additionally implies to the
customer that the problem is their staff's competence. Distinguishing the causes
requires asking a specific person a specific question and being willing to hear an
unflattering answer.
The second is the escalation boundary. When an integration fails, the symptom
appears in the customer's system and the cause can be on either side of a gap that
nobody has declared responsibility for — a header rewritten by a proxy in transit,
a retry that changed the HTTP method, a certificate chain that only fails from one
region, a body truncated by a size limit. Establishing which side without turning
it into an argument is a real skill, and the way it is done is by designing an
experiment the customer can run themselves, so the finding is theirs rather than
your assertion.
Loading diagram…
The ordering is the whole point of that exchange. The finding reaches the sponsor
from their own engineer, not from the vendor, which is the difference between a
resolved joint investigation and a vendor scoring a point off a customer's staff
in front of their director.
The third hardness is temporal. The decision that loses an account is usually
taken months before the signal that reveals it, and most of the metrics available
to you lag. Usage, ticket volume and plan progress all describe what has already
happened. The leading indicators are relational and awkward to quantify: who
replies, who attends, whether you are still invited into their planning, whether a
name from a competitor has begun appearing in meetings. This is the part where
experience is genuinely not substitutable, because the pattern-matching is built
from having been wrong before.
The fourth is that most of the numbers in this discipline are quietly ambiguous.
Retention can be measured in logos or in revenue and the two diverge whenever
customers differ in size. Net revenue retention includes expansion and can exceed
one hundred per cent while gross retention, which counts only losses, is poor —
which means a business can look healthy while losing a substantial share of its
revenue base and covering it with growth inside the surviving accounts. Anyone
senior in this area is expected to be able to say which figure they are quoting
and what it conceals.
Why study it
Study it if you want a role where technical ability is applied to a business
outcome rather than to a codebase, and where you can see the consequence of your
own judgement. It suits people who are good at diagnosis and comfortable with
ambiguity, and it suits engineers who have discovered they enjoy the part of the
job where a person explains a problem badly and someone has to work out what is
actually happening. It is also unusually good preparation for product management,
solutions architecture and pre-sales, because you accumulate something those roles
have to reconstruct second-hand: a large sample of how real organisations actually
fail to adopt software.
There is a specific commercial reason to look at the technical end of this
discipline if you are already an engineer. Roles that need both an integration
debugging capability and the ability to hold a difficult conversation with a
director are persistently harder to fill than either half separately, because most
candidates have one and not the other. If you can do both credibly, you are
competing in a much thinner field than you would be as a backend engineer.
Do not study it if you want to build things. You will spend a large share of your
week on other people's schedules, and the artefacts you produce are documents,
findings and decisions rather than software. Do not study it if you are looking for
a route into engineering; it is adjacent to engineering and does not become it, and
people who take the role as a stepping stone usually find the stone does not move.
And do not study it if you dislike being measured on something you cannot fully
control, because that is the permanent condition of the job — the renewal is
decided by someone else, and sometimes it is decided by a merger or a new chief
information officer with a standard for reasons that have nothing to do with how
well you worked.
Your first hour
Take a product you actually use at work and write a first-value definition for it,
which is the single most clarifying exercise in this discipline. Write three
versions, deliberately in this order: a weak one stated entirely in terms the
vendor controls, a better one stated as plumbing working reliably, and a strong one
stated as a named team completing a recurring business event and stopping something
they used to do.
Weak "The integration is live and the team is trained."
Measurable, entirely within our control, worth nothing
to the customer.
Better "The nightly feed lands without manual intervention for
five consecutive business days."
Real, but still a statement about plumbing.
Strong "The reconciliations team closes month-end from our
output instead of the two spreadsheets they keep today,
and the finance manager signs it off unchecked."
Baseline to record now, not later:
two spreadsheets, three people maintaining them,
close takes six working days, four manual corrections
in the last close.
First value = the first month-end closed from our output with
the spreadsheets no longer maintained in parallel.
Then do the second half of the hour, which is the part that teaches you something.
Take that strong definition and write down the three things outside your control
that would prevent it: whose data you need, whose approval the team requires, and
what the person doing the work today would lose by changing. Name a real person
for each where you can. What you should end up holding is a one-page document with
a definition of value, a recorded baseline, and three named dependencies you cannot
schedule — which is, in miniature, exactly what a success plan is, and considerably
more useful in an interview than a memorised definition of net revenue retention.
What this is not
It is not support with a nicer title. Support owns incidents and is measured per
interaction; this role owns an outcome across a term and can be failing while
every interaction went well.
It is not sales, and the frequent claim that it is "sales without the pressure" is
wrong in both directions. Where the role carries a renewal or expansion number the
pressure is real and commercial, and where it does not, the job is still
persuasion — of a sponsor, of a product manager, of your own leadership — just
without the leverage of a signature.
It is not customer service, and the difference is who initiates. Service responds
to what a customer asks for. This function is accountable for the things a customer
never asks for, most importantly the fact that the workflow they bought the product
for is still being done the old way.
It is not project management, although a competent onboarding looks like one from
the outside. A project plan tracks work to completion and can be entirely complete
while the customer has received nothing they care about. A success plan tracks an
outcome and therefore outlives go-live — and its whole purpose is to make visible
the state where every task is done and the result has not arrived.
Finally, it is not a soft discipline. The parts that decide whether someone is good
at it are precise: defining value in terms a customer's finance director will
accept, bisecting an integration failure with evidence, distinguishing a lagging
signal from a leading one, and saying a clear no with a date attached rather than
an undated maybe. The reason an undated maybe is worse than a no is worth holding
on to, because it generalises: a no lets a customer plan, and a maybe removes their
ability to.