Feature, advantage, proof: building a phone pitch that holds
Feature, advantage, proof. The sequence that turns a product sheet into an argument someone will listen to, and the construction error that reduces it to a catalogue in disguise.
"Our platform includes a voicemail detection engine." That sentence is true, precise, and has never once moved a call forward. It describes the product to someone who is quietly asking what any of it changes for them.
Feature, advantage, proof fixes exactly that fault. It forces you to move from what the product is to what it changes, and then to hand over something the buyer can check without taking your word for it.
Most UK sales teams already know a close relative of this framework: FAB, for features, advantages and benefits. The first two steps are the same. The third is where the two part company, and the difference is not cosmetic.
Feature, advantage, proof
| Step | Question it answers | Who is speaking |
|---|---|---|
| Feature | What is it? | The product |
| Advantage | What does that change for me? | The buyer |
| Proof | Why would I believe you? | A third party, a figure, a demonstration |
Read the third row again and compare it with FAB. A benefit is still you talking. It is the advantage restated in warmer language, usually with an emotional layer added: less stress for the team, more confidence in the numbers, peace of mind. Nothing in it can be checked, because nothing in it left your side of the conversation.
A proof, by construction, comes from somewhere else. A figure with a source, a customer who agreed to be named, a screen you can share, a document that exists whether or not the call goes well. That is why the third step is harder to fill in, and why an argument that survives it is worth more than three that do not.
In short
An argument without proof is a promise. An argument without an advantage is a user manual. Both are spotted in under ten seconds on the phone, and neither earns a second question.
The feature, and why it never lands on its own
A feature is factual and impossible to verify from the outside. It reassures the person saying it, because it is the part they control completely. That is precisely why new sales hires retreat into it: no one can contradict a feature, so nothing can go wrong. Nothing can go right either.
The test is simple. If your buyer could reasonably answer "so what?" without being difficult, you never left the feature. Say it out loud in the car before the call and listen for it.
There is one situation where the feature earns its place first: a technical buyer who has asked for it. An IT lead assessing a phone system wants to hear how voicemail detection works before they will accept anything you claim it does. With everyone else, the feature is an answer waiting for a question nobody asked.
The advantage, seen from their side
The advantage translates the feature into the buyer's working day. That means you have to know what their working day looks like, which is why an argument always comes after discovery and never before it. Arguing first is guessing dressed up as confidence.
The same feature produces different advantages depending on who is listening. Voicemail detection saves a rep their morning, gives a sales manager activity figures that mean something, and lowers the cost per conversation for the person signing the invoice. Three advantages, one feature, and only one of them is worth saying to the person actually on the line.
Feature only
"Our engine detects voicemail using machine learning."
Advantage stated
"Your reps only ever pick up the calls where a human answered. They stop spending the morning listening to answerphone greetings waiting for the beep."
Notice what changed: the subject of the sentence. The feature makes the product the subject, the advantage makes the buyer's team the subject. If your product is still the grammatical subject, you have not crossed over yet.
Proof, the only part that is not negotiable
This is the step most pitches quietly skip, and the only one that separates an assertion from an argument. Four kinds of proof hold up on a phone call, where the buyer can see nothing and is deciding in real time whether you are worth another five minutes.
- A dated figure you can attribute. "95% accuracy on voicemail detection" beats "very reliable", but only if you can say where the number comes from when they ask. And they will ask.
- A named customer. Only with their agreement, and ideally in the buyer's own sector. A reference from an unrelated industry invites the objection that their business is different.
- An immediate demonstration. The strongest form on the phone: offer to show it now, on their own list, rather than describing it. It converts a claim into an appointment.
- A document they can read. The data processing agreement, the public pricing page, the technical documentation. Anything that still exists after the call has ended and does not depend on your memory of it.
Weak proof
"Our customers are very happy" is not proof, it is an opinion about people who are not in the room. An unverifiable figure is no better. Proof that collapses at the first follow-up question does more damage than offering no proof at all, because it tells the buyer something about how you handle every other claim.
This is where the comparison with FAB stops being an academic point. A benefit costs nothing to produce, so every competitor on the buyer's shortlist has one, and they all sound alike. A proof costs something: you have to have measured the figure, asked the customer, built the demo, published the document. That cost is the whole point. It is what the buyer is implicitly pricing when they decide whether to keep listening.
The construction error that empties the framework
The error is running several complete arguments back to back without pausing. Three of them in a row produce exactly the effect the framework was meant to avoid: a catalogue, better written.
One argument at a time, then a question. The question does two jobs. It checks that the advantage actually landed, and it stops you spending your best material on a subject the buyer does not care about. You cannot tell the difference between polite silence and genuine interest unless you ask.
The list
"And then there's the transcription, and the automatic summary, and the CRM integration, and the sequences..."
One argument, one question
"...so they only take the calls that connect. Do you know roughly how many connected calls one of your reps gets through in a day at the moment?"
If the question comes back flat, that is information, not failure. It means the advantage you chose is not the one that matters to this buyer, and the right move is to go back to a discovery question rather than reach for a second argument. Reps who push on regardless usually end the call having said everything and learned nothing.
Three complete arguments
The dialler rings up to four numbers at once and only puts you through to the one that connects.
Your reps go from twenty-five calls an hour to a hundred and fifty, without talking any faster.
I can show you live on your own list. Twenty minutes is enough.
Every call is recorded, transcribed and summarised automatically.
You know what was said without listening back, and when a rep leaves, the history of their accounts stays with you.
It is in the entry plan at €75 per licence per month, with no paid add-on. The pricing page is public, you can check it while we are talking.
The data and the call recordings are hosted in France, with a French cloud provider.
Your compliance team gets a named hosting location rather than a region, and a written framework covering any transfer, instead of having to ask us later.
The data processing agreement is public. You can read it in full before you sign anything, sub-processors and transfer terms included.
On that third argument, stay exactly as precise as the contract is. Saying where the hosting sits is a fact you can stand behind. Promising that nothing ever leaves a given territory is a commitment the agreement does not make, and a procurement team will find that out before signature rather than after.
Combining feature, advantage, proof with SONCAS
The two frameworks do not compete, they nest. SONCAS decides which advantage to lead with, based on what drives this particular buyer. Feature, advantage, proof decides how that advantage is built once you have chosen it.
| Buying motive | Advantage to lead with | Proof that works best |
|---|---|---|
| Security | Nothing to unwind if it does not work out | A readable contract, no minimum term |
| Money | Cost per conversation cut sharply | The calculation redone with their own volumes |
| Convenience | No project to run, it works in the browser | A live demonstration on an active account |
| Novelty | A capability their competitors do not have | A trial on a single licence before any rollout |
The right-hand column is the one worth preparing in advance. Most reps can improvise an advantage under pressure. Almost nobody improvises a proof, which is why the proof is the thing to write down before the call rather than during it.
Adapting the framework to the phone
Feature, advantage, proof was built for face to face selling, where you have time and something visual to point at. On the phone you have neither, and three adjustments follow from that.
- Start with the advantage. The feature only comes out if they ask for it. You have fifteen seconds, not three minutes, and the feature spends all of them.
- One proof, not two. Two proofs in a row sound like a closing argument in court, and suggest you are already defending against a doubt the buyer had not yet had.
- Finish on a question. Without one the argument hangs in the air and you are the one who has to pick the conversation back up, which puts you straight back into monologue.
For the structure of the call as a whole, see the CROC method. To get your best arguments onto a single sheet you can actually use while dialling, the one-page call plan has a block set aside for exactly this.
Frequently asked questions
What does feature, advantage, proof mean?
Three steps in a fixed order. The feature describes the product, the advantage says what it changes for the buyer, and the proof makes that advantage checkable. Drop the third step and you are left with a promise.
How is this different from FAB?
FAB stands for features, advantages and benefits, and its third step restates the second in warmer words. Replacing the benefit with a proof is more demanding: it forces you to produce something the buyer can verify, which is exactly what makes an argument credible on a call where they cannot see anything.
Do you have to say all three parts every time?
On the phone the advantage and the proof are usually enough. The feature is worth stating only if the buyer asks for it, or if they are technical and expect it.
What counts as acceptable proof?
A dated figure you can attribute, a named customer who has agreed to be named, a live demonstration, a document the buyer can read for themselves. A salesperson asserting something is not proof, however confidently it is said.
Does the framework work for a service offer?
Yes. The feature becomes a delivery arrangement: who sits on the team, the response time, the format of what you hand over. The proof still has to be there, and it is usually a reference or a document.
Where does the framework fit in the call?
After discovery, never before it. An advantage is only an advantage in relation to a problem the buyer has already described. Argue too early and you are guessing at what matters to them.