A persuasive sales story is not a rehearsed customer-success anecdote inserted into every meeting. It is a carefully selected narrative that helps a particular buyer recognise their current problem, understand the consequences of inaction, see themselves in a better future, trust that the proposed path is credible, and feel comfortable making the next commitment.

This means the seller should normally conduct discovery before telling the main story.

SPIN Selling, developed from extensive analysis of major sales conversations, structures discovery around Situation, Problem, Implication and Need-payoff questions. Its purpose is to help buyers recognise and articulate the value of solving their problems rather than having the seller push a predetermined solution.

The Challenger approach adds another important element: sometimes the customer understands the symptoms but has misunderstood the underlying problem. The seller must then teach, tailor and constructively guide the customer towards a different way of thinking.

For complex opportunities, MEDDPICC helps connect the story to measurable value, organisational pain, decision criteria, the economic buyer, internal champions and the customer’s purchasing process.

The case studies below combine these methodologies with audience-centred storytelling.

---

A practical sales-story framework

Before examining the cases, use the following structure.

The 7C sales story​

1. Character​

Introduce someone similar to the buyer:

• a customer-service director;
• a chief financial officer;
• a chief information security officer;
• an operations manager;
• a data and AI leader.

The closer the character’s responsibilities, pressures and environment are to the listener’s, the easier it becomes for the listener to identify with the story. Research on narrative persuasion suggests that perceived similarity can support identification and transportation into the narrative.

2. Context​

Describe the organisation, circumstances and strategic objective.

3. Conflict​

Explain what prevented the organisation from achieving its objective.

4. Consequence​

Show what the problem was costing in:

• money;
• time;
• risk;
• customer experience;
• employee effort;
• missed growth;
• executive confidence.

5. Change​

Describe the decision, intervention or new way of working.

6. Confirmation​

Provide evidence:

• baseline and outcome metrics;
• implementation details;
• governance controls;
• customer references;
• pilot results;
• assumptions and limitations.

7. Close​

Connect the story to the current buyer and propose a reasonable next step.

The story should not conclude with:

“Would you like to buy our platform?”

It should usually conclude with something such as:

“Would it be useful to test whether the same pattern exists in your operation through a two-week discovery and baseline exercise?”

---

Case Study 1: Selling a customer-service AI solution to a bank

The situation​

A retail bank receives approximately 1.8 million customer-service enquiries annually.

The bank’s head of customer operations wants to introduce generative AI. Her initial request is:

“We need a chatbot that can reduce contact-centre demand.”

Several vendors immediately begin demonstrating:

• natural-language interfaces;
• large language models;
• virtual agents;
• retrieval-augmented generation;
• multilingual functionality;
• agent-assist features.

An AI solution engineer takes a different approach. Instead of beginning with the product, the seller tries to understand the operational and commercial story.

Key stakeholders​

The opportunity includes:

• Head of Customer Operations;
• Chief Information Officer;
• Chief Risk Officer;
• Data Protection Officer;
• Head of Contact Centre;
• Procurement;
• Finance Director;
• frontline service agents.

Each person needs to hear a different version of the same fundamental story.

---

Stage 1: Discovery using SPIN questions​

Situation questions​

The seller asks:

“How are customer enquiries currently divided between phone, chat, email and self-service?”

“Which enquiry types account for the greatest service volume?”

“How many knowledge systems does an agent normally use?”

“What proportion of enquiries require access to personal account information?”

“Which performance indicators matter most to the executive team?”

These questions establish the operating environment.

The seller learns that:

• 38% of contacts concern repeatable informational questions;
• agents search across five knowledge repositories;
• average handling time is approximately eight minutes;
• new agents require 12 weeks to reach expected productivity;
• customer satisfaction declines significantly when customers must repeat information;
• the bank previously tested a basic chatbot, but compliance concerns stopped the pilot.

Problem questions​

The seller continues:

“Where do agents lose the most time during a conversation?”

“How often do different agents provide different answers to the same question?”

“What prevented the previous chatbot pilot from progressing?”

“What happens when policy documentation changes?”

“Can compliance teams reconstruct why a particular automated answer was produced?”

The bank reveals that the primary problem is not merely contact volume.

The deeper problems are:

• fragmented knowledge;
• inconsistent policy interpretation;
• weak answer traceability;
• slow content updates;
• fear of automated regulatory mistakes.

Implication questions​

The seller asks:

“When agents spend additional time searching, what does that do to call queues and staffing costs?”

“If automated answers cannot be traced to an approved source, what would that mean during a compliance review?”

“If the organisation launches another chatbot that customers cannot trust, what effect would that have on future AI adoption?”

“How much management time is spent investigating inconsistent answers?”

The customer begins connecting the operational symptoms to wider consequences.

Need-payoff questions​

The seller asks:

“If every suggested answer were linked to an approved source, would that make compliance more comfortable with a controlled pilot?”

“If agents could find the correct policy in seconds rather than searching five systems, what would that mean for handling time?”

“Would starting with employee assistance rather than fully autonomous customer service reduce the implementation risk?”

“If the pilot measured quality, compliance and efficiency together, would that create a stronger business case?”

The customer is now describing the desired solution in its own language.

That is critical: the buyer is not merely agreeing with the seller. The buyer is helping build the business case.

---

Stage 2: The Challenger reframe​

The original customer request was:

“Help us introduce a chatbot.”

The seller reframes the problem:

“The greatest opportunity may not be replacing customer conversations. It may be creating a controlled knowledge and decision-support layer that makes every service channel more accurate, consistent and auditable.”

This reframe changes the discussion from:

• chatbot versus no chatbot;

to:

• trustworthy knowledge infrastructure;
• agent productivity;
• controlled automation;
• auditable customer service;
• staged adoption.

The seller is teaching the bank to think differently rather than simply responding to the original request.

---

Stage 3: The story told to the customer​

The seller says:

“Let me describe a situation from another regulated service environment.

The organisation initially approached the project as a chatbot initiative. Contact volumes were increasing, service costs were rising and leadership wanted customers to resolve more questions independently.

During discovery, however, the team found that the largest constraint was not the conversational interface. Employees themselves could not reliably find the current approved answer.

One service adviser described searching several systems while a customer waited on the phone. She would find a policy document, but she could not always tell whether it was the latest version. Experienced agents relied on memory, while newer employees escalated even straightforward questions.

The organisation had previously tested automation, but the risk team stopped it because the system could generate fluent answers without making the source and reasoning sufficiently visible.

Instead of beginning with an autonomous chatbot, the organisation created an employee-assist pilot. The solution retrieved information only from approved sources, displayed citations, captured the retrieved passages, logged the model and prompt versions and required employee confirmation for higher-risk responses.

The first goal was not headcount reduction. The first goal was proving that the organisation could make service answers faster, more consistent and more traceable.

Once the team had quality and risk evidence, it progressively exposed lower-risk journeys to customer self-service. High-risk activities remained with authorised employees.

The important lesson was that the conversational interface was the final layer. The real transformation was creating trusted knowledge, governance and measurement underneath it.

From what you have described, your situation may contain the same pattern. Before selecting a chatbot, we should determine whether fragmented knowledge and weak traceability are the real constraints.”

---

Why this story is persuasive​

It mirrors the customer​

The protagonist is another regulated organisation with:

• compliance pressure;
• fragmented knowledge;
• a failed pilot;
• concerns about generative AI;
• operational cost pressure.

It validates the customer’s fear​

The seller does not say:

“Your compliance concerns are unnecessary.”

The story says:

“Another responsible organisation had the same concern and changed the implementation approach.”

This makes the buyer feel understood rather than challenged personally.

It introduces a lower-risk path​

The story offers progression:

1. agent assistance;
2. measurable pilot;
3. restricted knowledge sources;
4. human confirmation;
5. controlled self-service;
6. greater automation after evidence.

It avoids unsupported promises​

The seller does not claim:

“AI will reduce your costs by 40%.”

Instead, the seller proposes measuring:

• answer quality;
• handling time;
• employee adoption;
• escalation;
• hallucination rate;
• source coverage;
• customer satisfaction;
• compliance exceptions.

---

Tailoring the story by stakeholder​

For the Head of Customer Operations​

Emphasise:

• average handling time;
• first-contact resolution;
• service consistency;
• agent productivity;
• queue reduction.

For the Chief Risk Officer​

Emphasise:

• approved knowledge sources;
• traceability;
• human oversight;
• testing;
• model limitations;
• incident management.

For the CIO​

Emphasise:

• system integration;
• architecture;
• identity and access management;
• scalability;
• monitoring;
• vendor portability.

For the CFO​

Emphasise:

• cost per contact;
• implementation cost;
• time to value;
• financial assumptions;
• staged investment;
• downside protection.

MEDDPICC emphasises that technical, economic and relationship criteria can differ between stakeholders. A technical evaluator and an economic buyer will not judge the same story in the same way.

---

Objection: “We tried a chatbot before and it failed.”​

A weak response would be:

“Our chatbot is much more advanced.”

A stronger story-based response would be:

“That experience is exactly why we would not recommend beginning with another broad chatbot launch. In the example I described, the previous failure revealed that the organisation lacked controlled knowledge, evaluation and traceability. The second initiative succeeded because it treated those as prerequisites rather than optional technical features.

The relevant question is therefore not whether your previous chatbot failed. It is whether the underlying causes of that failure can now be isolated and tested.”

The seller then asks:

“What were the three main reasons the previous pilot was stopped?”

This returns the conversation to discovery.

---

Objection: “The business case is not strong enough.”​

The seller responds:

“That is a reasonable concern. We should not construct the business case around a generic automation percentage.

We can begin with four measurable value drivers:

1. time agents spend searching;
2. avoidable repeat contacts;
3. training time for new employees;
4. quality and compliance investigation effort.

If those baselines do not show sufficient value, we should not recommend a large implementation.”

This is persuasive because the seller is willing to test whether the opportunity is genuinely valuable.

---

The close​

The seller does not ask for a full platform commitment.

The seller proposes:

“The next logical step would be a two-week discovery and measurement exercise. We would select three high-volume journeys, establish the operational and risk baseline, review the knowledge sources and determine whether an agent-assist pilot has a defensible business case. Would that be proportionate to the decision you need to make?”

This is an example of ethical commitment and consistency. Cialdini’s framework describes how small, voluntary commitments can support subsequent consistent action, provided the technique is applied authentically rather than deceptively.

---

Case Study 2: Selling predictive-maintenance AI to a manufacturer

The situation​

A food manufacturing company operates six factories. It experiences unexpected equipment failures, but the operations director believes downtime is simply an unavoidable part of manufacturing.

An AI vendor is offering predictive-maintenance capabilities using:

• sensor data;
• anomaly detection;
• machine-learning models;
• maintenance recommendations;
• alert prioritisation.

The initial sales pitch is unsuccessful.

---

The unsuccessful product-led pitch​

The salesperson says:

“Our platform has advanced anomaly detection, real-time dashboards, automated alerts, machine-learning pipelines and integrations with leading industrial systems.”

The operations director replies:

“We already have dashboards. Our maintenance engineers understand the machinery better than an algorithm.”

The pitch fails because it challenges the expertise and identity of the customer.

The operations team interprets the message as:

“Your engineers are not competent, and our software is smarter than they are.”

---

The discovery​

The new seller asks:

“Tell me about the most recent significant production interruption.”

The director explains that a packaging line failed before a major customer order was due.

The seller asks:

“When did the organisation first have evidence that something was changing?”

The maintenance manager explains that vibration and temperature readings had become irregular approximately 36 hours earlier, but the data was distributed across different systems.

The seller asks:

“Did anyone technically have access to that information?”

The response is:

“Yes, but no one was watching all those measurements together.”

The seller asks:

“What did that particular interruption affect?”

The customer identifies:

• 11 hours of downtime;
• overtime costs;
• wasted materials;
• expedited shipping;
• management escalation;
• risk to the customer relationship.

The seller now has the basis for a story.

---

The reframe​

The seller says:

“Predictive maintenance is not primarily about allowing an algorithm to overrule experienced engineers. It is about giving those engineers enough warning to apply their expertise before the operating window closes.”

This is a powerful reframe.

It protects the status and authority of the engineering team.

The AI is positioned as:

• an early-warning system;
• a pattern-detection assistant;
• a prioritisation mechanism;
• a tool controlled by experienced people.

---

The sales story​

“A manufacturer in a comparable environment had a similar concern. Its engineering leaders did not want a model making maintenance decisions without understanding the physical equipment.

The project team therefore began with a narrow question: could the system detect combinations of signals that experienced engineers would want to investigate?

It started with one production line and one failure category. Historical maintenance logs were combined with vibration, temperature and pressure data. The model did not automatically stop equipment or issue work orders. It generated an investigation alert and showed which signals had changed.

During the pilot, the model flagged an unusual combination of increasing temperature and changing vibration. Neither measurement was individually beyond the existing alarm threshold. Together, however, they resembled a pattern present before previous bearing failures.

The maintenance engineer reviewed the alert, inspected the equipment and decided to replace the component during a planned maintenance window.

The value was not that the model knew more about the machine than the engineer. The value was that it continuously watched thousands of measurements and gave the engineer time to act.

That changed the organisation’s view of the technology. It stopped being an AI replacement project and became an engineering decision-support capability.”

---

Building the business case​

The seller and customer calculate the opportunity using transparent assumptions.

Current-state assumptions​

• 20 material unplanned interruptions annually;
• average operational impact of $75,000 per interruption;
• total estimated annual impact: $1.5 million.

Proposed pilot assumptions​

• implementation and pilot cost: $180,000;
• one line and two failure categories;
• no assumption that every failure can be predicted;
• target of preventing or materially reducing four interruptions annually.

Illustrative value​

If four interruptions were prevented:

• estimated avoided impact: $300,000;
• pilot cost: $180,000;
• estimated first-stage gross benefit: $120,000.

This is not presented as a guarantee.

The seller says:

“These numbers are an investment hypothesis. The pilot must determine detection precision, warning time and operational adoption before we extrapolate across six factories.”

That statement improves credibility.

---

Objection: “Our data quality is poor.”​

A manipulative seller might minimise the issue:

“Our AI can work with any data.”

A credible seller says:

“Poor data may prevent this use case from working. The first stage should therefore test data availability and signal quality before we commit to building the complete solution.”

The seller then tells a short failure story:

“In one assessment, an organisation assumed it had two years of usable sensor data. The review found that maintenance events were recorded inconsistently and time stamps were not aligned. The team stopped the model build and first improved event logging. That delayed the AI work, but it prevented investment in a model that could not be validated.”

Failure stories are useful because they show that the seller:

• understands delivery risk;
• is not hiding limitations;
• will protect the customer from premature investment.

---

Objection: “Our engineers will not trust it.”​

The response:

“Trust should not be treated as a communications problem after deployment. Engineers should participate in designing the alerts, reviewing false positives and defining the conditions under which action is appropriate.

The first success measure should therefore not only be model accuracy. It should include whether engineers consider the alerts understandable and operationally useful.”

The solution now includes:

• engineer workshops;
• feedback capture;
• explainable signals;
• alert thresholds;
• manual approval;
• false-positive review;
• adoption measurement.

---

The close​

“Rather than proposing an enterprise rollout, I recommend selecting one critical production line and reviewing the last 12 months of failures. If the required data exists, we can define one failure mode and test whether the available signals would have provided useful warning. Shall we arrange a technical-value workshop with maintenance, operations and data representatives?”

---

Case Study 3: Selling cybersecurity through a credible risk story

The situation​

A growing professional-services company is considering an identity-security platform.

The Chief Information Security Officer understands the risk, but the CFO believes the programme is too expensive.

The seller must avoid two common mistakes:

1. frightening the customer with exaggerated breach scenarios;
2. overwhelming the CFO with technical features.

---

The weak fear-based pitch​

“Cyberattacks are increasing. Every company is at risk. A breach could cost millions and destroy your reputation.”

The CFO responds:

“Every security vendor tells us that. Give me a reason why this investment should take priority over our other projects.”

Generic fear is not persuasive because:

• it is not specific to the customer;
• the probability is unclear;
• the figures may be exaggerated;
• the seller appears self-interested;
• the customer cannot see how the product changes the risk.

---

Discovery​

The seller asks the CISO:

“Which identity-related incidents or near misses have required the most investigation?”

The CISO describes an incident involving a former contractor whose access remained active after the engagement ended.

The seller asks:

“How was the access discovered?”

The CISO replies:

“During a quarterly review.”

The seller asks:

“How long had the account remained active?”

The answer is 43 days.

The seller asks the CFO:

“Which aspect concerns you more: the probability of a serious event, the cost of the programme or uncertainty about whether the control will work?”

The CFO says:

“I do not know whether this is a $500,000 problem or a $5 million sales presentation.”

This is valuable. The real obstacle is not indifference to security. It is low confidence in the business case.

---

The story​

“A services organisation with a similar contractor model believed its main identity risk came from sophisticated external attacks.

During a controls review, it found that the more immediate exposure came from routine operational changes: people changing projects, contractors completing assignments and employees temporarily receiving privileged access.

No single team was acting irresponsibly. Human resources, project management, IT and security each completed their own process. The risk appeared in the gaps between those processes.

The company initially considered buying a broad security platform. Instead, it selected three measurable control failures:

• accounts remaining active after departure;
• excessive privileged access;
• delayed removal of temporary permissions.

It established a baseline and implemented automated identity checks around those specific events. High-risk exceptions were sent to accountable owners rather than being buried in general security dashboards.

The programme was approved because the business case was not presented as ‘prevent every cyberattack.’ It was presented as reducing known, measurable control weaknesses and improving the evidence available to management and auditors.”

---

Persuasion technique: specificity over catastrophe​

The story does not claim that a catastrophic breach will definitely happen.

It moves through:

1. a recognisable operating model;
2. a specific control failure;
3. organisational causes;
4. measurable exposure;
5. a targeted response;
6. evidence and accountability.

Cialdini’s authority and social-proof principles can support persuasion when the seller provides credible expertise and relevant examples. However, social proof should be specific: evidence from similar organisations facing similar decisions is usually more useful than saying, “Many companies use us.”

---

Tailoring for the CFO​

The CFO version of the story concentrates on:

• known control failures;
• number of inactive accounts;
• labour required for manual reviews;
• audit remediation effort;
• implementation cost;
• staged investment;
• control effectiveness.

The seller says:

“We should not ask you to fund this based solely on an unquantified catastrophic scenario. We should demonstrate that the organisation currently spends money operating manual controls that still leave measurable exceptions.”

---

Tailoring for the CISO​

The CISO version concentrates on:

• privileged access;
• identity lifecycle;
• integration;
• policy enforcement;
• detection;
• incident investigation;
• audit trail;
• control coverage.

---

Objection: “We have never had a major breach.”​

The seller answers:

“That is positive, and the purpose of this assessment is not to imply that a major breach is inevitable. The question is whether the current controls operate at the level management intends.

The former-contractor account gives us a useful example. It does not prove that a breach will happen, but it does demonstrate that access can remain active longer than policy permits.

Would it be reasonable to measure the frequency and duration of those exceptions before deciding whether a platform investment is justified?”

This is persuasive because it avoids arguing with the customer.

---

Objection: “The platform is too expensive.”​

The seller responds:

“Compared with what alternative?

If the alternative is accepting the current control level, we should document that risk explicitly. If the alternative is adding more manual review, we should calculate its cost and likely coverage. If another platform can deliver the required controls more economically, that should also be considered.

The decision should be based on control outcomes, not attachment to our product.”

This communicates confidence without pressure.

---

The close​

“Let us run a control-baseline exercise covering joiners, movers, leavers and privileged access. We can quantify exception volume, remediation time and control ownership. That will give finance and security a shared basis for deciding whether technology investment is justified.”

---

Case Study 4: Selling an AI governance programme to an executive board

The situation​

A multinational organisation has more than 80 AI experiments across different business units.

The board asks:

“Do we need an AI governance programme, or will governance slow innovation?”

The consulting team risks responding with a long presentation about:

• the EU AI Act;
• data protection;
• model risk;
• ethics;
• responsible AI frameworks;
• documentation;
• technical standards.

Although those subjects matter, a regulation-heavy presentation may cause executives to see governance as a compliance cost.

The seller needs to create a strategic story.

---

Discovery​

The AI solution engineer asks:

“How many AI use cases are currently in production?”

No one has a complete answer.

“Who can stop a use case from progressing?”

Different departments provide different answers.

“Which use cases interact directly with customers or employees?”

The organisation identifies several:

• recruitment screening;
• customer-service automation;
• fraud investigation;
• marketing personalisation;
• employee productivity tools.

“Can you identify the owner, model, data sources, evaluation results and approval status for each solution?”

The answer is no.

“What would happen if the board asked for this information following an incident?”

The Chief Risk Officer says:

“It would take weeks to reconstruct.”

The true problem is now visible.

The organisation does not merely lack policies. It lacks an enterprise mechanism for knowing:

• which AI systems exist;
• who owns them;
• which are high risk;
• what evidence supports deployment;
• how incidents will be handled.

---

The reframe​

“AI governance is not a committee that reviews every experiment. It is a decision system that allows low-risk innovation to move quickly while directing scrutiny towards the uses capable of causing significant harm.”

This changes governance from:

• control versus innovation;

to:

• proportionate control;
• decision velocity;
• accountability;
• portfolio visibility;
• reusable assurance.

---

The board-level story​

“A multinational organisation reached a point where AI adoption was growing faster than its ability to oversee it.

Business teams were solving legitimate problems. Marketing was testing personalisation, HR was exploring employee tools, operations was introducing predictive models and customer service was experimenting with generative AI.

Each project looked manageable in isolation. At portfolio level, however, no executive could answer five basic questions:

1. What AI systems do we operate?
2. Who is accountable for each one?
3. Which decisions do they influence?
4. What evidence supports their use?
5. What happens when they fail?

Leadership initially considered creating a central committee that would approve every AI activity. Business teams resisted because they believed it would slow delivery.

The organisation instead introduced a risk-tiered model.

Low-risk productivity experiments followed a lightweight self-assessment and approved technical controls. Customer-facing, employee-impacting or regulated uses required deeper review, testing and accountable executive approval.

The organisation built a common AI register, reusable assessment templates, standard security patterns, evaluation requirements and escalation routes.

Governance did not remove all risk, and it did not guarantee every model would work. It gave management visibility, accountability and a repeatable way to make decisions.

The greatest benefit was not simply regulatory preparation. Teams stopped rebuilding assurance from the beginning for every project. Approved patterns allowed suitable use cases to move faster.”

---

The evidence architecture​

The seller proposes that each use case should have evidence across six areas:

1. Purpose​

• intended use;
• users;
• affected parties;
• prohibited uses;
• business owner.

2. Data​

• source;
• lawful basis;
• quality;
• sensitivity;
• retention;
• lineage.

3. Model and system​

• model selection;
• version;
• architecture;
• external dependencies;
• limitations.

4. Evaluation​

• performance;
• bias or differential impact;
• robustness;
• hallucination;
• security testing;
• human review.

5. Operations​

• monitoring;
• incidents;
• change control;
• fallback arrangements;
• supplier management.

6. Accountability​

• risk classification;
• approvals;
• responsible executive;
• review schedule;
• retirement process.

---

Stakeholder-specific versions​

For the CEO​

“This gives you confidence that AI growth is intentional and accountable.”

For the Chief Risk Officer​

“This creates consistent classification, evidence, escalation and oversight.”

For the CIO​

“This reduces unapproved tools, fragmented architecture and uncontrolled model access.”

For the business-unit leader​

“This provides a defined path to production rather than uncertain case-by-case approval.”

For the CFO​

“This reduces duplicated assurance work and allows investment to be prioritised across the portfolio.”

Duarte’s sales-presentation approach recommends beginning with what the buyer needs to believe rather than with everything the organisation wants to say. The narrative should be designed around the decision-maker’s required shift in understanding.

---

Objection: “Governance will slow us down.”​

The response:

“Poorly designed governance probably will.

The objective should not be to give every experiment the same level of review. A low-risk internal summarisation tool should not follow the same process as an AI system influencing recruitment or customer eligibility.

The design principle is proportionality: increase evidence and approval requirements as potential impact increases.”

The seller then tells a contrast story:

“Without standard governance, every project spends weeks identifying stakeholders, negotiating requirements and recreating documentation. With reusable patterns, low-risk projects can progress through a known path while the risk team concentrates on consequential uses.”

---

Objection: “We can wait until the regulation is clearer.”​

The seller answers:

“Some legal requirements may continue to evolve, but the management questions already exist:

• What systems do we operate?
• Who owns them?
• What decisions do they influence?
• How were they tested?
• How would we respond to an incident?

Building those capabilities is useful even if individual regulatory interpretations change.”

---

The close​

“Rather than beginning with a large governance transformation, I recommend a four-week portfolio diagnostic. We would identify current use cases, classify a representative sample, map the existing decision process and design the minimum viable governance model. The output would allow the board to decide whether a broader programme is necessary.”

---

Case Study 5: Overcoming a previous failed transformation

The situation​

A retailer is considering a cloud data platform. Three years earlier, it spent heavily on a transformation programme that exceeded budget and failed to achieve business adoption.

The new Chief Data Officer wants to restart the work, but the CFO and operating leaders are highly sceptical.

The salesperson should not present the previous failure as irrational resistance.

The failed programme has created legitimate organisational memory.

---

Discovery​

The seller asks:

“What did the previous programme promise?”

The customer says:

• a single customer view;
• self-service analytics;
• reduced reporting effort;
• machine-learning capability.

“Which promises were technically delivered?”

The company created a data lake and migrated several datasets.

“Which business outcomes were realised?”

Very few.

“Why did users continue relying on spreadsheets?”

The answers include:

• unclear data ownership;
• poor trust in metrics;
• slow onboarding of new use cases;
• technical teams building without sufficient business participation;
• no agreed adoption measures.

The seller identifies that the failure was not simply technological.

---

The story​

“Another organisation entered a second data-transformation programme after a disappointing first attempt.

The leadership team initially assumed the old technology had been the problem. During discovery, it found that the platform had technically delivered much of its specification.

What it had not delivered was organisational confidence.

Business teams could access data, but they did not agree on definitions. Finance, sales and operations calculated customer value differently. No single owner was accountable for resolving those differences.

The second programme therefore did not begin with another enterprise migration. It selected one commercial decision: improving the accuracy and speed of product-availability reporting.

A cross-functional team agreed the definitions, identified authoritative data sources and assigned owners for quality exceptions. The technology team then built only what was required to support that decision.

Adoption was measured through actual usage and reduction in manual reconciliation—not simply through the number of datasets migrated.

Once the organisation had a trusted product and a repeatable delivery model, it expanded to additional domains.

The difference was not a more fashionable platform. The difference was connecting architecture, ownership, user workflow and measurable business value.”

---

Why this story works​

It acknowledges that:

• the previous investment was real;
• the scepticism is rational;
• technology alone did not solve the problem;
• the new programme must behave differently;
• success should be earned through a narrow proof point.

The seller does not say:

“This time will be different because our technology is better.”

The seller demonstrates precisely what must be different:

• decision-led scope;
• business ownership;
• shared definitions;
• adoption metrics;
• incremental investment;
• governance;
• transparent benefits.

---

Objection: “We cannot afford another failed programme.”​

The seller responds:

“You should not approve another enterprise programme based on ambition alone.

We recommend structuring the first investment so that it can succeed or fail cheaply. Select one decision, one accountable business owner, a measurable baseline and a defined implementation boundary.

If the team cannot demonstrate data trust, adoption and operational value in that scope, the organisation should not expand the programme.”

This is persuasive because it reduces the perceived irreversibility of the decision.

---

Objection: “Why should we believe your projections?”​

The seller says:

“You should treat our projections as hypotheses until your data validates them.

We can separate the business case into:

• customer-provided baseline figures;
• externally supported assumptions;
• our implementation estimates;
• sensitivity ranges;
• benefits proven during the pilot.

That allows you to see which parts are facts and which parts remain uncertain.”

---

The close​

“Would the executive team support a six-week value-design phase focused on one commercial decision, provided that expansion requires evidence of adoption and measurable impact?”

---

Case Study 6: The real Jobs to Be Done condominium example

The original sales problem​

A condominium developer was trying to sell new homes, particularly to people seeking to downsize.

The organisation invested in:

• attractive finishes;
• architectural improvements;
• marketing;
• sales activity;
• features suggested through customer research.

However, sales remained disappointing.

The company was asking a conventional question:

“What features do buyers want in a condominium?”

Jobs to Be Done research instead investigated the circumstances and stories surrounding the decision to move.

The researchers repeatedly heard buyers discuss their dining-room tables. The table was not simply furniture. It represented family memories and created a practical and emotional barrier to moving. Buyers were also overwhelmed by sorting possessions and managing a significant life transition.

---

The hidden job​

The apparent job was:

“Buy a smaller home.”

The deeper job was closer to:

“Help me move into the next stage of my life without feeling that I am abandoning my family, memories and identity.”

That insight changed the value proposition.

The developer was not only competing with other properties.

It was competing with:

• emotional attachment;
• fear of regret;
• the effort of moving;
• uncertainty;
• disruption;
• the safety of remaining in the existing home.

The company responded by helping buyers manage the transition, including addressing storage and moving-related barriers. The Christensen Institute uses this example to demonstrate that purchase decisions are shaped by functional, emotional and social circumstances rather than product attributes alone.

---

The feature-led sales story​

A conventional salesperson might say:

“The condominium has modern appliances, attractive windows, two bedrooms, secure parking and high-quality finishes.”

These features may be relevant, but they do not address why the buyer is unable to act.

---

The Jobs to Be Done sales story​

A better story might be:

“Many of the people who eventually moved here had been thinking about downsizing for years.

They liked the idea of having less maintenance and living somewhere more manageable. But the difficult part was not selecting a new property. It was deciding what would happen to the life they had built in their existing home.

For several buyers, the dining table became the symbol of that decision. It was where birthdays, holidays and family meals had taken place. Finding a new home was easy compared with deciding what to keep, what to move and what leaving the old home meant.

We therefore designed the transition around more than the property itself. We help buyers understand how their important possessions will fit and how the moving process can be managed gradually.

The goal is not simply to place you in a smaller home. It is to help you move forward without feeling that you have discarded the things that matter.”

This story addresses the emotional and practical forces preventing the decision.

---

Application to B2B technology sales​

Business purchases also have functional, emotional and social jobs.

A Chief Information Officer may say:

“I need a new data platform.”

The deeper jobs may include:

• “Help me reduce the operational burden of legacy systems.”
• “Help me show the board that technology investment creates business value.”
• “Help me avoid another failed transformation.”
• “Help me establish credibility as a strategic leader.”
• “Help my team work without constant firefighting.”

An AI director may say:

“We need an enterprise AI platform.”

The deeper jobs may include:

• “Help me convert scattered experiments into a credible enterprise capability.”
• “Help me demonstrate progress before executive sponsorship disappears.”
• “Help me control risk without becoming known as the person blocking innovation.”
• “Help me create an operating model that survives beyond individual pilots.”

The best sales story therefore addresses not only the product requirement, but the progress the buyer is trying to achieve in their particular circumstances.

---

Case Study 7: Creating an internal champion for an enterprise AI deal

The situation​

An AI solution engineer has developed strong support from the bank’s Head of Customer Operations.

However, the contact says:

“I like the proposal, but I need to take it to risk, technology and finance.”

This is a dangerous stage.

The seller may believe the meeting was successful, but the proposal must now be sold internally without the seller being present.

MEDDPICC defines a genuine champion as someone with influence, a vested interest in the solution and the willingness to sell internally.

The salesperson must give the champion a story that can travel.

---

The overly complicated internal story​

The salesperson provides a 60-slide presentation containing:

• architecture;
• product screenshots;
• company history;
• model comparisons;
• integration diagrams;
• features;
• service packages.

The champion struggles to explain the decision to executives.

---

The portable story​

The seller and champion build a concise narrative:

Current state​

“Customer-service agents search across five knowledge systems, producing slow and inconsistent answers.”

Business consequence​

“The problem increases handling time, training effort, repeat contacts and compliance-investigation work.”

Strategic insight​

“A customer-facing chatbot will not solve the problem unless the underlying knowledge is controlled and traceable.”

Proposed action​

“Start with an employee-assist pilot covering three high-volume, low-risk journeys.”

Controls​

“Use approved sources, visible citations, logging, human approval and formal evaluation.”

Evidence required​

“Measure answer quality, time saved, employee adoption, risk exceptions and cost per resolved enquiry.”

Investment boundary​

“Do not expand until agreed quality, risk and value thresholds are reached.”

Decision requested​

“Approve a limited pilot and nominate representatives from operations, risk, technology and finance.”

This story can be retold in two minutes.

---

Preparing the champion​

The seller asks:

“Who is most likely to oppose this proposal?”

“What will the CFO ask first?”

“Which risk concern could stop the project?”

“What evidence does technology architecture need?”

“How are pilot investments normally approved?”

“Who can authorise access to the required data?”

These questions reveal the decision process and paper process rather than assuming that customer enthusiasm equals deal progress.

---

The champion rehearsal​

The salesperson role-plays the CFO:

“Why should we spend money on this when we already have a chatbot?”

The champion practises:

“The existing chatbot addresses only a narrow customer interface. This pilot targets the fragmented knowledge that increases service effort across channels. The investment is staged, and expansion depends on independently agreed measures.”

The salesperson role-plays the risk leader:

“What happens if the model produces an incorrect answer?”

The champion practises:

“The pilot uses only approved source material, displays citations, logs responses and keeps employees responsible for final high-risk answers. Incorrect outputs are included in formal evaluation and incident review.”

A strong salesperson does not merely persuade the contact. They enable the contact to persuade the rest of the organisation.

---

What all the case studies have in common

1. Discovery came before storytelling​

The story was chosen after the seller understood:

• the problem;
• the implications;
• the stakeholders;
• previous failures;
• desired outcomes;
• decision barriers.

2. The story introduced an insight​

It did not merely say:

“Another customer used our solution.”

It showed the customer:

• that their original problem definition might be incomplete;
• why the status quo was costly;
• how a different approach could reduce risk;
• what an achievable first step looked like.

3. The customer remained the hero​

The technology did not rescue an incompetent organisation.

Customer leaders:

• recognised the problem;
• made a difficult decision;
• involved their teams;
• managed risk;
• learned from evidence;
• achieved progress.

4. Evidence followed emotion​

A person or moment made the problem real.

Then the seller added:

• operational data;
• financial measures;
• implementation controls;
• evaluation criteria;
• limitations.

5. The stories were tailored​

The same underlying case was expressed differently for:

• finance;
• operations;
• risk;
• technology;
• procurement;
• executive leadership.

6. Each story contained tension​

Good sales stories include a meaningful choice:

• continue with fragmented knowledge or establish trusted service infrastructure;
• accept reactive maintenance or create earlier warning;
• rely on manual controls or measure and automate specific identity risks;
• allow uncontrolled AI growth or establish proportionate governance;
• repeat a large transformation or prove value incrementally.

7. The close was proportionate​

The close was not always a contract.

It was often:

• a discovery workshop;
• a baseline assessment;
• a pilot;
• technical validation;
• stakeholder alignment;
• data review;
• mutual action plan.

---

A reusable template for your own sales case study

Case-study preparation sheet​

Customer profile​

• Industry:
• Organisation size:
• Relevant business unit:
• Decision-maker:
• Other stakeholders:
• Strategic priority:

Starting situation​

• What was happening?
• What had already been attempted?
• What did the customer initially believe the problem was?
• Why had the problem not been solved?

Human moment​

• Who personally experienced the problem?
• What specific event demonstrated it?
• What did the person see, hear or have to do?

Business problem​

• Operational impact:
• Financial impact:
• Risk impact:
• Customer impact:
• Employee impact:
• Strategic impact:

Reframe​

Complete the sentence:

“The customer initially believed the problem was ________, but discovered the deeper issue was ________.”

Intervention​

• What changed?
• Why was this approach selected?
• What was deliberately excluded?
• How was risk controlled?
• How were users involved?

Evidence​

• Baseline:
• Outcome:
• Measurement period:
• Assumptions:
• Limitations:
• Lessons learned:

Relevance to the new buyer​

Complete the sentence:

“Your situation may be similar because ________, although we would need to validate ________.”

Next step​

• What is the smallest useful commitment?
• Who needs to participate?
• What question will the next step answer?
• What decision follows it?

---

A two-minute storytelling script

Use this format during an executive conversation:

“We worked with an organisation facing a similar challenge.

They were trying to [strategic objective], but [specific obstacle] was preventing progress.

The problem became visible when [human moment or operational event].

Initially, they assumed [original interpretation]. During discovery, however, they found that [deeper insight or reframe].

That was creating [financial, operational and risk implications].

Instead of [obvious or risky approach], they began with [controlled intervention].

They measured [relevant metrics] and controlled risk through [key safeguards].

The result was [verified outcome, or honest description of learning].

The important lesson was [transferable insight].

Your situation appears similar in [specific respects], although we should validate [important difference or uncertainty].

A sensible next step would be [proportionate commitment]. Would that help you make the decision?”

---

Final principle

A great sales story should never remove the buyer’s freedom to decide.

It should improve the quality of the decision by making the following clearer:

• the current situation;
• the cost of remaining unchanged;
• the progress the buyer is trying to make;
• the choices available;
• the evidence supporting the recommendation;
• the risks and limitations;
• the next practical action.

The goal is not to make the customer feel that saying yes is unavoidable.

The goal is to make the customer feel:

“This person understands our situation, has helped organisations like ours, is honest about the risks and has shown us a credible way forward.”