Customer Success & Managed Improvement
Retain. Expand where
justified. Advocate
where earned.
Live platformValue that keeps being earned
After go-live the question changes from whether the platform works to whether it still earns its place. That needs governance: a clear health position, evidence about what is actually happening, priorities decided against business impact, and value confirmed rather than assumed.
80% of our business comes from existing customers and referrals.
In short
Customer success is a governance layer, not an account plan.
It exists to keep a live platform honest: what is happening, what it is costing, what deserves effort next, and what has genuinely improved.
- Go-live is the start of the value question, not the end of it.
- The business will keep changing, so the platform has to keep earning its place.
- Retention comes from dependable service and decisions worth making, not from account contact.
- Improvement needs evidence: service data, adoption, data quality, platform health and business change.
- Not every request deserves effort, and saying so openly is part of the job.
- Expansion should follow a demonstrated business problem, never a sales cycle.
- Advocacy is earned by outcomes the customer recognises, and is always the customer's choice.
Who owns what
Different jobs, different owners, different measures.
Most confusion after go-live comes from one team being asked to do all of these at once. Each has a distinct purpose.
Support
Restores service and keeps expected capability working. Measured in response, resolution and reliability.
Problem management
Removes the cause behind repeated incidents, rather than resolving the same symptom again.
Customer Success
Owns the governance layer: health, priority, value evidence and the decision about what should happen next.
Optimise
Delivers a scoped improvement intervention with a defined outcome and an end date.
Transform
Takes on change large enough to need a programme, a business case and its own governance.
Recover
Steps in where confidence in the platform or the delivery has materially broken down.
The post go-live lifecycle
A cycle, not a one-way project plan.
Each turn should start from what the business now needs, not from where the plan happened to stop. Expansion is a stage in the cycle, and holding is an equally valid outcome of it.
Stabilise
Settle the platform after go-live and close out early noise.
Operate
Keep expected capability working, day to day, with clear ownership.
Observe
Read service data, adoption, data quality, platform health and business change.
Prioritise
Decide what deserves effort, and what does not.
Invest
Agree scope, owner, cost and expected outcome before work starts.
Improve
Make the agreed change, properly tested and documented.
Adopt
Make sure people actually work the new way.
Measure
Check the change did what it was supposed to do.
Review
Start again from what the business now needs.
Expand or hold
Extend where the evidence justifies it. Hold where it does not.
The platform should evolve because the business changed. Not because the backlog became old enough.
A mature improvement model distinguishes an urgent operational issue from a recurring problem, a process improvement, a new requirement, technical debt, an adoption issue, a data issue, a licensing issue and a strategic opportunity. Each needs a different response.
Urgent operational issue
Something is broken now. Support responds.
Recurring problem
The same incident keeps returning. Problem management responds.
Process improvement
The process works, but costs more effort than it should.
New requirement
The business now needs something it did not need before.
Technical debt
The estate is becoming harder or riskier to support.
Adoption issue
The capability exists. People are not using it.
Data issue
Decisions are being made on information nobody fully trusts.
Licensing issue
Entitlement no longer reflects the work people do.
Strategic opportunity
A change that could move a business target, not just a task.
Two different conversations
Support keeps capability working. Governance keeps it relevant.
Most organisations have somewhere to raise a fault. Fewer have somewhere to raise the observation that the process itself is wrong.
Where the programme is
Where recovery takes it
A workflow has failed
The approval process itself should be redesigned
A report no longer runs
Leadership needs a better management view
A user cannot complete a transaction
The process requires unnecessary manual steps
The integration errored overnight
The handover between systems needs rethinking
Portfolio architecture
Four layers, kept separate, kept connected.
A single combined backlog sounds tidy and behaves badly. Operational urgency always outranks strategic value, so the strategic work never moves.
- Incidents, service requests and access changes
- Owned by Support, measured against the service agreement
- Moves in hours and days
- Feeds evidence upward when a pattern appears
- They answer different questions
- They move at different speeds
- They have different owners and different funding
- A single list forces urgent operational work to compete with quarterly strategy
- One backlog usually means the loudest queue wins
A portfolio should reflect business value, not organisational volume.
Now, next, later, not doing
A good roadmap includes what the organisation decided not to do.
Declining something openly, with a recorded reason and a trigger to revisit it, is more useful than leaving it on a list forever where it quietly consumes attention at every review.
Now
Operationally important. Being worked on.
Next
Agreed priority. Sequenced and owned.
Later
Useful, but not currently justified.
Not doing
Deliberately declined, with the reason and a review trigger recorded.
- Business impact
- Customer impact
- Risk and control need
- Regulatory requirement
- Effort and cost
- Dependency
- Urgency
- Strategic alignment
- Adoption impact
- Not simply who asked first, or who asked loudest
From portfolio to roadmap
The roadmap should explain why the change matters.
A roadmap is not a product wish list. Every item should carry a business reason, an owner and an expected outcome.
Business priority
The operating pressure or target the change serves.
Platform capability
What the change requires the platform to do.
Timing
When the business can absorb it, not only when we could build it.
Dependency
What has to be true first.
Budget
What it costs, and who has agreed to it.
Owner
The named person accountable for the outcome.
Expected outcome
What should be different once it is done.
Illustrative sequence
Driven by readiness and value, not technology fashion.
This is an example of shape, not a commitment. Your sequence depends on your pressures, your data and your capacity to absorb change.
Q1
Illustrative: stabilise warehouse support issues.
Q2
Illustrative: improve Power BI management reporting.
Q3
Illustrative: automate purchase approval.
Q4
Illustrative: assess a predictive warehouse model.
Value realisation
Delivered is not the same as realised.
Value realisation is a record, not a sentiment. It holds the business problem, the baseline, the owner, the measure and the honest status of each outcome.
- The business problem, in the customer's words
- The baseline position before the change
- The named business owner of the outcome
- The expected outcome and how it would be recognised
- The measure, and where the measure comes from
- The date the position was assessed
- The current status, honestly stated
Value status
Every outcome sits somewhere on this ladder.
Most improvement disappointment comes from items recorded as delivered that never reached adopted, measured or realised.
Proposed
An outcome someone believes is available.
Defined
The business problem, owner and expected outcome are agreed.
Baselined
The starting position is recorded, with a date and a source.
Delivered
The change is live and working as specified.
Adopted
People are genuinely working the new way.
Measured
The measure has been taken again against the baseline.
Realised
The customer recognises the outcome as achieved.
Not realised
The outcome did not materialise, and the reason is recorded.
Customer health
One shared view of how the relationship is actually going.
Health is read across six lenses. The purpose is early honesty, not a score to present. A lens moving the wrong way should start a conversation while the position is still easy to correct.
- Incident volume and repetition
- Time to restore, against expectation
- Open problems with no owner
- Escalation frequency
What each status means
A status is a commitment to act, not a colour on a slide.
Healthy
Service is dependable, adoption is holding and the roadmap is owned. Keep the rhythm light.
Watch
One or two lenses are drifting. Name it early, agree the evidence to gather and set a review date.
At risk
Something material is degrading value or confidence. It gets an owner, an action and a date.
Escalated
The position needs leadership on both sides, and may need a recovery conversation rather than a roadmap.
Two-way feedback
Customers need a route that is not a support ticket.
Concerns raised late are almost always concerns that had nowhere useful to go earlier.
- Structured review conversations with decisions recorded
- A named route for concerns that sits outside the ticket queue
- Direct access to a senior contact when confidence drops
- Periodic, short feedback that asks about outcomes rather than politeness
Confidence gates
Four points where continuing has to be re-earned.
A gate is a decision point, not a warning. Each one can legitimately conclude that the right answer is to wait, to reduce the scope or to do nothing.
Gate 1
Health baseline
We understand the current position before proposing anything.
Governance that starts with a proposal rather than a position tends to produce activity instead of value.
Confirmed at this gate
- Service, adoption, data, platform, value and relationship health have been reviewed
- A named business owner is engaged
- The baseline is recorded with a date and a source
- Known constraints and capacity are understood
Decision
Proceed to prioritisation · Gather further evidence first · Stabilise the service before improvement planning
Gate 2
Opportunity fit
The proposed change is the right response to the evidence.
Many observed problems are adoption, process or data matters rather than build matters. The response has to match the cause.
Confirmed at this gate
- The business problem is described by the customer, not inferred by us
- The cause has been established rather than assumed
- The right route is confirmed: support, adoption, optimise, transform or no change
- The expected outcome can be recognised if it happens
Decision
Scope the intervention · Route it to the appropriate specialist lens · Decline it, with the reason recorded
Gate 3
Investment readiness
The organisation can absorb the change, and has agreed to fund it.
Capacity to adopt is a harder constraint than capacity to build. This gate protects the operation from its own roadmap.
Confirmed at this gate
- Cost, effort and dependency are understood and approved
- Business availability for testing and adoption is confirmed
- Timing works around operational peaks
- Licensing and security consequences have been checked
Decision
Commit and sequence · Defer to a better window · Reduce the scope to what can be absorbed
Gate 4
Value confirmation
The outcome is confirmed, or the shortfall is acknowledged.
Closing work without checking the outcome is how organisations accumulate change without accumulating value.
Confirmed at this gate
- The change is live, adopted and supportable
- The measure has been retaken against the baseline
- The customer owner agrees what was achieved
- Any shortfall is recorded with the reason
Decision
Record the outcome as realised · Record it as not realised, with the learning · Feed the result into the next prioritisation
Expand where justified
Growth should follow a business problem, not a sales cycle.
Expansion is a legitimate part of the lifecycle. It is only legitimate when the current investment is already delivering and the organisation can absorb more.
- Is there a business problem the customer has described?
- Is the current platform already delivering what it promised?
- Would improving what exists solve it more cheaply?
- Is there capacity to adopt more change?
- Does the commercial case survive an honest reading?
- Would we recommend this if there were no revenue attached?
If improving what you already own would solve it, that is the recommendation we make.
Advocate where earned
References follow outcomes, not project completion.
80% of our business comes from existing customers and referrals. That only holds while the advice stays trustworthy, including when the answer is no.
Earned, not requested
A reference conversation follows an outcome the customer recognises, not the end of a project.
The customer's words
Where a customer describes the value in their own terms, we publish that. We do not write it for them.
Always optional
Declining a reference has no effect on service, priority or commercial treatment.
Referral over promotion
Most of our growth comes from people who worked with us before, which is a discipline as much as a statistic.
Shared responsibility
Governance only works when both sides own something.
A partner cannot own a business outcome alone, and a customer should not have to chase evidence about their own platform.
- Bringing the evidence, not just an agenda
- Naming risk early, including risk we created
- Recommending no change where no change is right
- Keeping the platform supportable against the current Microsoft position
- Recording decisions, owners and outcomes
The customer value review
A review should exist because there are decisions to make.
The review is where health, value and priority meet. It produces decisions with owners and dates, or it is not worth holding.
- Business changes since the last review
- Health position across the six lenses
- Service and problem themes
- Value register status, including anything not realised
- Adoption, data, licensing and security signals
- Relevant Microsoft release change
- Next priorities, and what is being declined
Service data as signal
Support history shows where the organisation repeatedly pays for friction.
Individually, each ticket looks small. Read together, they describe the parts of the operating model that are not working.
- The same issue raised repeatedly
- The same user confusion, across different people
- Recurring integration failure or data correction
- A manual workaround that has become normal
- The same report requested again and again
- Performance complaints tied to one process
Specialist lenses
A signal, a question, and where the work belongs.
Customer Success reads the signal and owns the decision. The detailed work belongs to the specialist that can answer it properly.
Signal
Capability exists but is not used
What behaviour needs to change, and who owns that outcome?
Change, Adoption & TrainingSignal
Entitlement no longer reflects the work
What does current evidence say we own, need and can defend?
Licensing & Commercial OptimisationSignal
Numbers are disputed at management level
Who owns this data, and what is it used to decide?
Data Migration & Data QualitySignal
Leaders are exporting to Excel to decide
Which decision is still unsupported by the reporting?
Power BI & Microsoft FabricSignal
Repetitive coordination consumes team time
Is this a process to automate, or a process to remove?
Power PlatformSignal
An AI idea is being considered
Are process, data, security, value and human ownership ready?
Data & AISignal
Problems are only visible once they have happened
What would leadership do differently if they saw it earlier?
Predictive Intelligence
Keep the estate supportable
Capability, customisation and control should be re-earned over time.
This is the deeper layer of the review. It matters, but it should not crowd out the business conversation, so it sits here for the people who need it.
Evidence discipline
80% of our business comes from existing customers and referrals.
Organisations continue with InteliSense because the relationship keeps producing decisions worth making. Where customers describe that in their own words, we publish it. We do not invent improvement statistics.
- The governance model and how priority is decided
- The health lenses and what each status means
- The confidence gates and what each one confirms
- The value register structure and the baseline rule
No change is a legitimate outcome of governance, and we will say so.
Where no change is the right answer, we record the reason, the date and the trigger that would cause the position to be revisited. A stable platform with an owned roadmap does not need a programme invented for it.
Self assessment
Where would a customer success conversation start for you?
Four questions, kept at organisational level. The result is a suggested starting point, and one of the possible answers is that no immediate intervention is needed.
Indicative signal
Answer the questions and we will show a likely starting point. This is a suggested next route rather than a recommendation to invest, and one of the possible answers is that no immediate intervention is needed. Please keep every answer at organisational level.
Your answers are carried through, so you will not be asked to repeat them. Final qualification is always a conversation.
Common questions
Questions leaders ask about life after go-live.
Keep moving
Has the platform stopped moving forward?
If the system is live but the improvement conversation has gone quiet, a structured review can establish the current health position, what the business now needs, and what genuinely deserves to happen next.