Build a Pain-Proof-Process Solution Page From Scratch

Marketing Academy · Field Work●Copywriting

All projects·From: B2B Copy: Pain, Proof, Process

CoreBuild the Asset· 50 minutes

Freshworks

Objective: Given a raw product brief and three customer interview quotes, write a full B2B solution page section using the Pain-Proof-Process framework: a specific pain headline, matched proof, and a process block that lowers perceived risk.

You're a copywriter for Freshworks, briefed to write a new solution page for a mid-market IT helpdesk add-on. Sales has flagged that the current page reads like a feature list and buyers bounce before requesting a demo.

Turn a raw product brief and three anonymized customer interview quotes into a Pain-Proof-Process page section: one specific pain headline, one matched proof block with a named result, and a 3-step process block with a low-risk CTA.

Before you start

What you'll need

Free path (everything below is enough to finish)

Google Docs

FreeDraft and iterate the page copy

Free, easy to share with sales for objection-handling review

The process

3 steps

Step 01 of 03

Identifying the exact, quantified pain in the buyer's own language

The lesson's Step 1 says pain must be specific to a role, quantified where possible, and written in the buyer's own words, not product language.

One interview quote reads: 'Our IT team re-opens the same 15 tickets every week because agents can't see which device the employee is on.' Turn that into a headline. Which version survives Step 1's three tests?

Google Docs— Draft the headline in a new Google Doc, one line at a time, before writing any other copy.

Procedure

Read all 3 interview quotes and underline every number and role mentioned
Draft 3 headline candidates using only the buyer's own words
Reject any headline that could describe a competitor's product unchanged
Keep the headline that names a role, a frequency, and a concrete consequence

Sample output

REJECTED: "Streamline your IT support workflow."
REJECTED: "Better visibility for helpdesk teams."
KEPT: "Your IT team re-opens the same 15 tickets a week because agents can't see which device the employee is on."

Healthy

The kept headline names a role (IT team), a frequency (a week), and a consequence (reopened tickets) pulled straight from the interview transcript.

Unhealthy

A headline like 'Streamline your IT support workflow' survives unedited because it never gets tested against a real customer quote.

What this means

A pain headline that could sit unchanged on a competitor's page has failed Step 1, no matter how polished it sounds.

So what do I do about it?

Symptom	Action	Effort
Headline drafts keep sounding like every other SaaS homepage	Re-read the raw interview transcript and lift a direct quote instead of paraphrasing	5 min

YouYou can do this yourself, no engineering access required.

Step 02 of 03

Matching proof directly to the pain named in the headline

Step 2 says proof must directly answer the pain named in the headline; a mismatched testimonial (great product, wrong problem) undermines trust.

You have two customer quotes available: one about faster onboarding, one about ticket re-opens dropping after device visibility was added. Which one goes directly under the pain headline?

Google Docs— Paste both candidate quotes into the doc under the headline and compare them against the pain statement.

Procedure

Re-read the pain headline drafted in Step 1
Place the ticket re-open quote directly beneath it
Move the onboarding quote to a different section addressing a different pain
Add the customer's name, title, and company to the kept quote

Sample output

"Reopened tickets dropped from 15 a week to 2 within a month of turning on device visibility."
— Priya Menon, IT Operations Lead, a 400-seat mid-market logistics firm

Healthy

The proof block answers the exact pain named above it, with a named person, title, and a before/after number.

Unhealthy

The onboarding-speed quote gets placed under the ticket-reopen headline because it was the strongest quote available, not the most relevant one.

What this means

Strong proof in the wrong place reads as filler; buyers notice the mismatch even if they can't name it.

So what do I do about it?

Symptom	Action	Effort
A page has great testimonials but demo requests stay flat	Check whether each testimonial sits under the pain it actually solves	5 min

YouYou can do this yourself, no engineering access required.

Step 03 of 03

Writing a process block that reduces risk aversion

Step 3 frames a 'how it works' section as the antidote to risk aversion, the dominant emotion in B2B buying; each step needs a concrete deliverable.

Sales says the biggest objection at this stage is 'this will take weeks of our IT team's time to set up.' Write a 3-step process block that answers that objection directly.

Google Docs— Add a numbered process block beneath the proof block, then close with one CTA.

Procedure

List every setup task the vendor's own team handles, versus what the buyer's team must do
Write 3 numbered steps, each with a day count and a concrete deliverable
Write one CTA that asks for time, not budget or a signature

Sample output

1. Kickoff call (Day 1): We import your existing device inventory in 30 minutes.
2. Configuration (Days 2-3): Our team maps devices to employees. No IT engineering hours required.
3. Go live (Day 4): Your team sees the device-visibility dashboard live.

CTA: See a 15-minute demo

Healthy

Each step has a day count, a named owner, and a deliverable; the CTA asks for a short block of time, not a purchase.

Unhealthy

The process block lists internal engineering milestones instead of buyer-facing deliverables, or the CTA says 'Start your trial' to a first-time visitor.

What this means

A process block that never mentions who does the work leaves the 'weeks of IT time' objection unanswered.

So what do I do about it?

Symptom	Action	Effort
Prospects stall right after reading the 'how it works' section	Check whether every step names who does the work and how long it takes	5 min

YouYou can do this yourself, no engineering access required.

Final deliverable

A complete Pain-Proof-Process page section: one pain headline, one matched proof block with named source, a 3-step process block, and one low-risk CTA.

See a reference example

Sample output

Wise, IT helpdesk add-on solution page (excerpt)

PAIN
"Your finance team re-approves the same 8 international payments every week because your payment platform can't flag duplicate vendor IDs."

PROOF
"Duplicate-approval requests dropped from 8 a week to 1 within three weeks of enabling vendor ID matching."
— Tomas Berg, Finance Operations Manager

PROCESS
1. Kickoff call (Day 1): We import your vendor list in 20 minutes.
2. Matching setup (Days 2-3): Our team configures ID matching. No engineering hours required on your side.
3. Go live (Day 4): Duplicate flags appear in your existing approval queue.

CTA: See a 15-minute demo

Success criteria

You're done when you can:

Pain headline is specific, quantified, and pulled from the buyer's own words, not paraphrased
Proof block sits directly under the pain it answers and includes a named source with a before/after number
Process block names who does the work and how long each step takes
CTA asks for a low-commitment next step (time), not a purchase