Systems Thinking Strategy
Systems Thinking Strategy
Systems Thinking Strategy for Member Services
Before we can measure, improve, or redesign anything, we need absolute clarity on purpose.
To help members get what they need, as quickly and simply as possible, so they feel genuinely supported and confident in their cover.
The fundamental question underpinning this entire strategy is deceptively simple: what is Member Services for?
Systems thinking requires us to study Member Services as a whole system rather than optimising individual parts in isolation. This means understanding demand from the member's perspective, studying the end-to-end flow of work, and designing processes that absorb variety in demand rather than forcing members into rigid pathways.
Study demand before designing supply — understand what members actually ask for and why.
Measure what matters to members, not what is convenient for the organisation.
Let the nature of the work determine the process, not organisational structure.
Put decision-making authority where the work is done.
Use complaints as the richest source of system intelligence.
Every process, metric, and decision should be tested against this purpose. If an activity does not directly serve it, we should question why it exists.
Every contact, task, and communication in Member Services falls into one of two categories: value demand or failure demand.
Demand caused by our failure to do something right — chasing, repeating, correcting.
"Where's my claim?", repeated requests for same info, complaints about delays
What we exist to do — legitimate member needs arriving for the first time.
New claim submission, policy query, address change, renewal enquiry
In many service organisations, failure demand accounts for 40–80% of all incoming work.
How many times we handle a case before resolution. Count every human interaction — call, email, internal handoff — per case.
Volume of outbound communications generated per case. Track letters, emails, calls, and portal messages per case ID.
Internal work steps required to fulfil the request. Map the workflow and count discrete actions and handoffs.
How long from first contact to resolution, from the member's perspective. Timestamp from initial request to confirmed completion.
Number of decision points, handoffs, and dependencies. Process mapping with swim lanes showing all actors involved.
How often we resolve correctly on first attempt. Track rework, re-contact within 7 days, and escalations.
Reducing failure demand is the single highest-leverage improvement available.
Complaints are not problems to be managed — they are the system telling us where it is broken.
Every complaint is a data point that reveals friction, failure demand, or a gap between what members expect and what we deliver.
Categorise every complaint by the demand type it relates to
Map each complaint back to the specific process step where failure occurred
Identify which demand types generate disproportionate complaints
Not "the agent made an error" but "the system design made the error likely"
Feed findings back into process redesign priorities
The demand types that generate the most complaints, the longest resolution times, and the highest touch-point counts are where we focus redesign effort first. This is not about blame — it is about finding where the system design creates the most friction for members.
For every demand type, the aspiration is clear.
The member states what they need once, clearly, through any channel.
One person (or automated process) handles the request without handoffs.
The resolution requires the minimum possible number of internal steps.
The member's need is fully met, confirmed, and they leave satisfied.
Not everything is one-and-done.
The "single request, single touch point, single action" model is the ideal, but some demand types are inherently multi-step. A complex claim will legitimately require clinical assessment, documentation, and adjudication.
The goal is not to artificially force everything into a single interaction, but to ensure that every touch point adds value and no touch point exists because of internal friction or poor process design. For multi-step processes, the question becomes: what is the ideal number of touch points for this demand type, and how do we make each one as smooth as possible?
The member should always know where they are in the process, what happens next, and when to expect resolution.
Traditional metrics measure efficiency from the organisation's perspective. Systems thinking requires us to measure capability from the member's perspective.
Total elapsed time from member request to confirmed resolution
ReduceNumber of interactions required to resolve
ReducePercentage resolved in a single interaction
IncreasePercentage of incoming contacts that are failure demand
ReduceComplaints as a percentage of total demand by type
ReduceQualitative satisfaction and emotional response
ImproveCapability charts, not arbitrary targets.
Metrics should be tracked on capability charts (statistical process control) rather than against arbitrary targets. This shows us the true capability of the system and whether changes we make genuinely shift performance or simply reflect normal variation.
A process that takes between 3 and 14 days is not a process with a 7-day average — it is a process with too much variation.
Beyond quantitative metrics, we need to understand how members feel about their interactions. Satisfaction scores alone are insufficient — they tell us a number but not the story.
Brief, contextual, tied to specific demand types — not generic CSAT.
Tone and language analysis on recorded calls to identify frustration signals.
Systematic coding of complaint text to identify recurring themes and emotional patterns.
External sentiment about The Exeter's service experience.
Frontline staff flagging cases where members expressed strong positive or negative feelings.
Sentiment data becomes powerful when linked back to specific demand types and process steps. If members consistently express frustration at a particular stage of the claims process, that is a system signal, not a people problem.
The goal is to build a continuous feedback loop: member sentiment informs process redesign, which improves sentiment, which we measure again.
The people closest to the work understand the work best. Improvement must be driven from the front line, not imposed from above.
Colleagues who speak to members every day see the friction, the workarounds, and the unnecessary steps that no process map will reveal. Colleague feedback must be systematised, not occasional.
A simple, low-friction mechanism for colleagues to log issues, ideas, and observations as they encounter them. This should take seconds, not minutes.
Team leads review captured feedback to identify recurring themes and quick wins that can be actioned immediately.
Aggregated colleague insights are presented alongside member sentiment and process metrics to identify systemic issues requiring redesign.
Colleagues must see that their feedback leads to change. A transparent backlog showing submitted ideas, their status, and outcomes builds trust and sustains engagement.
Colleagues must have permission to make small process changes within their area without seeking approval for every adjustment.
Provide training in basic systems thinking, process mapping, and problem-solving methods so colleagues can diagnose issues effectively.
Create an environment where identifying problems is valued, not punished. The system failed, not the person.
Applying the full systems thinking analysis to a single, high-frequency demand type.
Policy cancellation is one of the most operationally complex tasks in Member Services, touching multiple teams across two separate systems. It is also the moment when a member has already decided to leave — making it the worst possible point in the relationship to create friction.
| Metric | Current Reality | What This Tells Us |
|---|---|---|
| Touch points | Minimum 3: phone agent → admin team → Finance. Plus broker notification. | The member's single request passes through at least three separate teams. |
| Internal tasks | 4–5: cancel DD, cancel policy, write member letter, write broker letter, notify Finance. | Five discrete manual actions for a single member request. |
| Communications | 3+: manual letter to member, manual letter to broker, notification to Finance. Plus the original phone call. | Every communication is manually produced. This is why the phone agent cannot complete the process. |
| End-to-end time | Up to 5 working days SLA from the member's request. | A member who has decided to leave waits up to a week for confirmation. |
| First-contact resolution | Not possible on Highway. Phone agent cannot complete the process due to manual letters. | Zero percent of Highway cancellations are resolved at first contact. |
| System duplication | The same demand type exists as three separate task types. | Three versions of the same process means three places where it can go wrong differently. |
5-day SLA driven by admin queue, not by the complexity of the work itself.
Handoffs between teams create gaps where agreed actions are missed or delayed.
Every cancellation letter is manually written from scratch, introducing human error.
Manual letter production means inconsistent content across agents.
Delay between cancellation request and DD cancellation means payments may be taken after the member expects to have left.
The single reason a phone agent cannot resolve a Highway cancellation in one call is manual letter production. Remove the manual letters and the entire multi-team, 5-day process collapses into a single interaction.
Today, a cancellation is not one process — it is at least three, depending on which system the policy sits on and how the request arrives. The Highway phone route passes through phone agent, admin team, and Finance with a 5-day SLA. Every letter is manually written. Zero percent first-contact resolution.
The member contacts us by any channel. The agent cancels the policy, cancels the direct debit, and confirms any financial implications — all in the same interaction. Confirmation letters are auto-generated. Finance is notified automatically. The member knows immediately that their policy is cancelled, when their last payment will be, and what refund to expect.
This is not a transformation programme with a fixed timeline and a Gantt chart. Systems thinking is a way of working, not a project.
Study the system as it actually operates today. Go to where the work is done, observe real cases end-to-end, and measure what members actually experience. No redesign should begin until we have a clear, data-backed picture of the current state.
The demand types that generate the most friction — measured by complaints, touch points, end-to-end time, and failure demand — are where we focus first. This is not a matter of opinion or seniority; the data tells us where the system is failing members most.
Rather than large-scale transformation programmes, make small, targeted changes to specific demand types and measure the impact immediately. If a change reduces touch points or end-to-end time, keep it. If it does not, learn from it.
Every process change is co-designed with frontline colleagues. They understand the real constraints, the workarounds, and the unintended consequences that process designers sitting in a meeting room will not anticipate.
Capability charts replace periodic reporting. Track metrics in real time so we can see the impact of changes as they happen and distinguish genuine improvement from normal variation.
The goal is not a one-off improvement but a permanent shift in how Member Services operates. Embed the study of demand, the measurement of member experience, and the colleague feedback loop into daily operations — not as a separate initiative.
We will know this strategy is working when:
Failure demand as a proportion of total demand is measurably declining month over month.
Touch points per case are reducing toward the defined ideal for each demand type.
Complaints increasingly lead to system changes rather than individual corrective actions.
Colleagues are actively contributing ideas and seeing them implemented.
Member sentiment is improving, particularly on themes of simplicity and speed.
The organisation can articulate, with data, why each process step exists and what value it adds.
The ultimate measure of success is a member who gets what they need, simply and quickly, and feels confident that The Exeter is on their side.