Two customers on the same plan describe your company differently.
One gets a structured onboarding, a quarterly review with an agenda, and a reply within the hour. The other gets a friendly CSM who is brilliant on the phone and silent for five weeks. Same product, same price, same promise on the website.
Nobody is doing anything wrong. That is what makes it hard to fix.
The failure is not that your CSMs behave differently. It is that the difference tracks the CSM rather than the account. A customer paying $8,000 and a customer paying $180,000 should absolutely get different treatment. Two customers paying the same amount should not, and when they do, the variable is which name landed in the owner field.
This is a five-point audit you can run on your own CRM this week. Each point produces a number rather than an impression, because "we're a bit inconsistent" is not something a team can act on.
What does inconsistent customer experience across CSMs actually mean?
Short answer: it means the service a customer receives is predicted better by who owns the account than by what the account is worth, what it needs, or what you promised it. Audit it by measuring five things across your whole book: how accounts start, how often they are touched, what happens when the same trigger fires, whether the account is legible to anyone else, and what gets escalated.
Two clarifications before the audit, because both get this wrong.
Consistency is not uniformity. The goal is not every customer getting the same thing. It is every customer getting the thing their tier was designed to get. A team where all 300 accounts receive identical treatment has a different and usually worse problem.
Variance is not incompetence. Most of it comes from the absence of a decision, not from a bad one. Nobody wrote down what a tier-two account is owed, so eight CSMs each decided, reasonably, and now you have eight answers.
Why the experience varies in the first place
Four causes, and only one of them is about the individual.
Nothing was ever defined. The most common. There is no written statement of what a given tier receives, so each CSM builds their own standard from their last job and their current workload. The variance is not deviation from the rule; there is no rule.
It was defined once, in a document nobody opens. A playbook exists, was announced, and is not run. That is a specific and well-studied failure with its own causes, and we cover it separately in why CSMs ignore the playbook you built. If your audit points here, read that rather than rewriting the playbook again.
Capacity differs and nobody adjusted for it. A CSM with 40 accounts and a CSM with 95 will deliver different experiences no matter how good the process is. If your audit finds variance that correlates with book size, you have a coverage problem wearing a consistency costume, and the fix is in accounts per CSM, not in training.
Tenure. A CSM four months in has not yet built the instincts a CSM four years in uses without noticing. This is normal and temporary, and it is only a problem if nobody is measuring it or if ramp is informal enough that each new hire learns a slightly different version of the job.
Which of the four you have determines whether this is a documentation problem, an adoption problem, a staffing problem or a training problem. The audit exists to tell you which, because the four fixes have nothing in common.
Point 1: Does every account start the same way?
The start is where variance compounds, because everything afterwards inherits it.
What to measure. Take the last 20 accounts that went live. For each one, record whether the sales-to-CS handoff happened as a documented event, whether success criteria were written down before kickoff, and how many days passed between the contract signing and the first CSM contact.
What you are looking for. The spread, not the average. If days-to-first-contact runs from 1 to 23, the average of 9 tells you nothing useful and hides both the fast ones and the accounts that sat untouched for three weeks.
| FINDING | WHAT IT MEANS |
|---|---|
| Handoff happened for some accounts and not others | The process is optional in practice, whatever the diagram says |
| Success criteria written for the large accounts only | You have an implicit tier that nobody has published |
| Days-to-first-contact spread wider than 10 | Capacity or priority, not process |
| Everything consistent, outcomes still vary | Your problem is downstream. Go to point 3 |
If this point fails, the fix is a defined transfer rather than more encouragement. The sales-to-CS handoff checklist is the artefact, and the first email after handoff is the moment customers compare notes on without telling you.
Point 2: Does contact frequency track the tier or the CSM?
This is the single most revealing number in the audit, and it takes an afternoon.
What to measure. For every account, count customer-facing touches in the last 90 days. Then group twice: once by account tier, once by owning CSM. Compare the spread within each grouping.
What good looks like. Variance should be wide between tiers and narrow within them. A tier-one account should get noticeably more than a tier-three account. Two tier-two accounts owned by different CSMs should get roughly the same.
What you will probably find. The spread by CSM is wider than the spread by tier. That single comparison converts a vague complaint into a finding a leadership team can act on, because it says the owner predicts the service better than the contract does.
Two honest caveats on this measurement.
Touch count is a quantity, not a quality. A CSM with fewer, better conversations may be outperforming one sending weekly check-ins nobody reads. Treat a low count as a question rather than a verdict, and pair it with an outcome before concluding anything. Our page on activity metrics for CSMs covers why activity counts mislead when used alone.
And some variance is correct. An account in an escalation should be getting more contact than a stable one at the same tier. You are looking for variance with no account-side explanation.
If this point fails on capacity, the answer is coverage. If it fails on habit, it is the weekly operating rhythm that needs defining, not the CSM that needs telling.
Point 3: When the same thing happens, do you do the same thing?
The variance test. This is the part of the audit nobody runs, and it is the one that produces the most uncomfortable number.
How to run it. Pick one trigger that fires often and matters: usage dropping below a threshold, a support escalation, a champion going quiet, a renewal 90 days out. Find every account where that trigger fired in the last quarter. For each one, write down what actually happened next.
Then count the distinct responses.
Reading the result.
| DISTINCT RESPONSES TO ONE TRIGGER | WHAT IT TELLS YOU |
|---|---|
| One or two | A play exists and is run |
| Three or four | A play exists and is interpreted |
| Five or more | No play exists, whatever the document says |
| Several accounts where nothing happened | The trigger is not reaching anyone, which is a routing problem rather than a behaviour one |
The reason this test works is that it removes opinion. Nobody has to agree about whether the team is consistent. You have a count, from your own records, of how many different things happened in identical circumstances.
The result most teams get is the fourth row, and they are not expecting it. A meaningful share of triggers produce no recorded response at all, which looks like inconsistency and is actually a plumbing failure: the signal fired somewhere nobody was looking.
If you find five or more responses, do not write a new play. Read why CSMs ignore the playbook you built first, because a rewrite that does not address why the last one went unrun produces a sixth response rather than fewer.
Point 4: Could another CSM take this account tomorrow?
Consistency and continuity are the same problem viewed from different ends. An account that only its owner understands is already delivering an inconsistent experience; you just cannot see it until that person leaves.
What to measure. Pick five accounts at random, ideally spread across CSMs. For each, without asking the owner, try to answer four questions from your systems alone:
- What did this customer buy the product to achieve?
- Who is the economic buyer, and who is the day-to-day owner?
- What is the biggest open issue?
- What was agreed at the last review?
Scoring. Count how many of the twenty answers you can find. Anything below fifteen means the account lives in somebody's head, and the customer experience is therefore a function of that person's memory and availability.
This is the point that converts a soft worry into a staffing risk. The cost arrives on the day somebody resigns, and by then it is not an audit finding, it is a handover crisis. The recovery version of this is covered in inheriting accounts from a CSM who left.
One thing not to do with this finding. The instinct is to mandate more logging, and it usually fails because it adds work without changing what the work is for. Define the four fields that must be current on every account and let everything else stay optional. A short mandatory record gets kept. A long one gets fabricated the day before a review.
Point 5: Does the same situation get escalated by everyone?
Escalation thresholds are where individual judgment is most visible and least examined.
What to measure. Over the last quarter, list everything that was escalated, by whom, and what triggered it. Then look for the inverse: situations that plainly warranted escalation and were handled quietly instead.
What you are looking for. Whether the threshold is a property of the situation or of the person. If one CSM escalates three times a quarter and another has never escalated in a year, the difference is rarely that one has easier accounts.
Both directions are a problem. A CSM who escalates nothing is absorbing risk that leadership cannot see, and the first time you hear about that account will be the renewal. A CSM who escalates everything is converting their judgment into somebody else's workload.
The fix is a written threshold rather than a cultural one: what must be raised, to whom, within what time. Our escalation process guide has the matrix. The audit finding you want is simply whether the threshold currently exists outside people's heads.
Scoring the audit
Five points, each producing a number rather than an impression.
| POINT | THE MEASUREMENT | WHERE IT COMES FROM |
|---|---|---|
| 1. Start | Days to first contact, handoff completion, criteria written | CRM close date against first logged activity |
| 2. Cadence | 90-day touch count grouped by tier and by CSM | Calendar and email logging, or CS platform activity |
| 3. Response | Distinct responses to one repeated trigger | Product usage or support data, read against activity logs |
| 4. Legibility | 20 questions answered from systems across 5 accounts | Whatever you already have, which is the point |
| 5. Escalation | Escalations per CSM, plus the ones that did not happen | Escalation log, plus churned and contracted accounts |
If a measurement is impossible rather than merely annoying, that is the finding. A team that cannot count touches per account in 90 days does not have a consistency problem it can audit yet. It has a logging problem, and that is the first fix.
Do not fix all five. The usual result is that one point fails badly and the others are fine, and the badly failing one is causing most of what customers notice. Fix that, re-measure in a quarter, and resist the urge to launch a consistency programme, which is how a specific problem becomes a six-month initiative nobody finishes.
What to do with the result
The four causes from earlier map onto the fixes, and the audit tells you which one you are in.
| IF THE AUDIT SAYS | THE CAUSE IS | THE FIX IS |
|---|---|---|
| Nothing is defined for a tier | No decision was made | Write the tier definition, below |
| It is defined and unrun | Adoption | Redesign the play, do not reissue it |
| Variance correlates with book size | Capacity | Rebalance coverage before changing process |
| Variance correlates with tenure | Ramp | Formalise ramp, measure the gap closing |
What goes on the tier definition page
This is the artefact the audit produces when point 1 or point 2 fails, and it is the thing most teams gesture at without writing. One page per tier, six lines each, published where CSMs work rather than in a strategy deck.
| LINE | WHAT IT STATES | WHY THIS ONE |
|---|---|---|
| Who qualifies | The threshold that puts an account in this tier | Without it, tier is assigned by feel and the audit cannot group |
| The minimum contact | How often, and in what form | This is the floor point 2 measures against |
| What always happens | The events every account in this tier gets, such as a kickoff, a review, a renewal conversation at a set point | Turns "proactive" into something checkable |
| What never happens | What this tier does not receive | Protects the tier above it and stops quiet over-servicing |
| Who decides exceptions | A named role, not "ask your manager" | Undefined exception rights are where variance restarts |
| What is recorded | The fields that must be current, from point 4 | A record requirement nobody stated is one nobody keeps |
Write the floor, not the ceiling. A tier definition that describes the ideal account experience gets ignored the first busy week. One that describes the minimum gets met, and good CSMs exceed it without being told to.
One failure mode to avoid. Do not write these in a workshop with the whole team. You will produce the aspirational version. Write them from what your best-run accounts actually receive today, which is both achievable and already proven inside your own book.
A note on quality reviews
Some teams answer this problem with call reviews or a QA scorecard, borrowed from support. It can work, and it is a much heavier instrument than what is on this page.
The distinction worth holding: this audit measures whether the process varies by owner. A QA review measures whether the execution is good. They answer different questions, and running the second before the first means grading people against a standard nobody has written down.
If the audit says nothing is defined, defining it beats reviewing calls against it.
The honest caveat on all of this. Reducing variance has a cost, and past a point it buys nothing. A team where every CSM does exactly the same thing in every situation has removed the judgment you hired them for, and will handle the unusual account badly. The target is a floor, not a mould: a defined minimum every customer in a tier receives, with latitude above it.
If the audit makes you want to script the calls, you have gone too far.
Where GainTrace fits
We sell customer success software, so treat this with the appropriate suspicion.
Points 2, 3 and 4 of this audit are questions about whether your records can answer a question about your book. If touches, triggers and account context sit in four systems, running this audit is a week of exports before you learn anything, which is why most teams never run it twice.
GainTrace connects CRM, billing, product and support data so that the same five measurements are a view rather than a project, and so the trigger in point 3 fires in one place with the response recorded next to it. The pricing is published, including a free tier, so you can check the model without a sales call.
What it will not do is decide what a tier-two account is owed. That is a management decision, and no platform has an opinion about it. The audit above works on a spreadsheet and four CSV exports, and it is worth running that way before it is worth buying anything.
The point of the audit is to find out which problem you have
Most teams who suspect they are inconsistent respond by writing something: a new playbook, a new template, a new set of standards. That works if the cause was that nothing was ever defined, and fails in the three cases where something was defined and did not survive contact with the week.
The five measurements above take an afternoon each and will tell you which of those you are in.
You are not looking for a team that behaves identically. You are looking for a customer whose experience can be predicted from their contract rather than from their owner.
Frequently asked questions
- How do I measure consistency across my CS team?
- Measure spread rather than averages, across five things: days to first contact for new accounts, 90-day touch counts grouped by tier and by CSM, the number of distinct responses to one repeated trigger, how many standard questions about an account can be answered from your systems, and escalations per CSM. The useful comparison in each case is whether the variance tracks the account or the owner.
- Should every customer get the same experience?
- No, and designing for that creates a different problem. Customers on different tiers should receive measurably different service, because that is what tiering is for. The failure is variance within a tier, where two customers paying the same amount get different treatment because different people own them.
- Is some variance between CSMs healthy?
- Yes. Judgment, relationship style and pace of response to an unusual situation are the things you hired people for, and a team that has eliminated them will handle the unexpected account badly. Define a floor for each tier and leave latitude above it. The target is a predictable minimum, not identical behaviour.
- How do I know if the problem is the process or the people?
- Run point 3. If the same trigger produces five or more different responses, no usable process exists regardless of what is documented, and that is a design problem. If it produces one or two responses with a few accounts where nothing happened, the process works and the gap is routing or capacity. Blaming individuals before running this test is the most common misdiagnosis in CS operations.
- What if we have a playbook and people still do not follow it?
- That is a distinct and well-documented failure with its own causes, usually too many plays, triggers based on the calendar rather than the account, or no decision rights attached. Rewriting the same playbook louder does not fix it.
- How often should we run this audit?
- Once, properly, then again a quarter after you have fixed the point that failed. Running all five every month turns a diagnostic into a reporting burden, and the measurements do not move fast enough to justify it. The exception is after a reorganisation, a significant hire, or a change to the coverage model, where the audit tells you quickly whether the change held.
- Does inconsistency actually cost revenue?
- It plausibly does, through renewals and references, but be careful with the claim. We have not measured a figure for it and neither has anybody whose methodology you can read. What you can establish internally is whether your own contraction and churn correlate with the CSM who owned the account, which is a question your own data can answer and a far stronger argument than a borrowed statistic.
- What should a CS tier definition actually contain?
- Six lines per tier: who qualifies, the minimum contact, what always happens, what never happens, who decides exceptions, and what must be recorded. Write it from what your best-run accounts already receive rather than from an ideal, because the version produced in a workshop is usually aspirational and gets abandoned in the first busy week. The floor is the useful part; good CSMs will exceed it without instruction.
- Should we run call reviews or a QA scorecard instead?
- They answer a different question. This audit measures whether the process varies by owner; a QA review measures whether execution is good. Running the second before the first grades people against a standard nobody wrote down. If the audit finds nothing is defined, define it before you review against it.
- Two CSMs gave a customer different answers. Is that a consistency problem?
- Possibly not. A one-off contradiction is usually a knowledge problem, solved by a shared source of truth rather than by process change. It becomes a consistency problem when the same question reliably produces different answers depending on who is asked, which is point 3 of the audit applied to information rather than action.
- How does CSM tenure affect consistency?
- A new CSM has not yet built the pattern recognition an experienced one uses without noticing, so some variance by tenure is expected and temporary. It becomes a structural problem when ramp is informal, because each new hire then learns a slightly different version of the job from whoever was free that week.
