How to write a partner case study customers will believe
How to write a technology partner case study: a shared customer, a workflow before and after, real permission, and a home on your site, theirs, and the marketplace.
Most partner case studies fail the only test that matters: a prospect reads the first paragraph and does not believe it. Two logos, a quote that could apply to any vendor, a result with no workflow behind it. The page exists so both companies can say they have a case study. Nobody on a buying committee uses it.
A partner case study customers will believe is a case study in the narrow sense: one shared customer, one job they already did, what it looked like before the pairing, what it looks like after, and permission to say so in public. It is not a testimonial. It is not a launch post. It is evidence that the joint story is true for someone like the reader.
This post is the writing and placement guide. How to pick the customer, how to structure the before and after, how to get permission without being extractive, and where the piece should live so it actually gets used: your site, the partner's site, and the marketplace listing if you have one. It assumes a live integration and at least one happy shared customer. If you do not have those, you are not ready to write. You are ready to go get a customer live.
The 60-second version
If you only read one section, read this one:
- A partner case study needs a named shared customer. Anonymous "a leading retailer" stories do not carry. If they will not be named, wait or pick someone else.
- The spine is the workflow before and after, not the relationship. Steps the customer ran by hand, steps they run now.
- Write from the customer's job, using the same discipline as a joint value proposition. Two product pitches stapled together is not a case study.
- Permission is a project. Ask early, show the draft, make it easy to say no to a quote and still approve the workflow facts.
- Place it in three homes: your integration or campaign page, the partner's integrations surface, and the marketplace listing. One PDF on a shared drive is not placement.
- Do not invent metrics. A clear before-and-after of the job beats a percentage nobody will defend on a sales call.
- Sales has to be able to send it. If a seller will not attach it to an email, it is too long, too vague, or too self-congratulatory.
Why a shared customer is the only case study that works
A technology partnership is a claim about a shared workflow. The only evidence that claim is true is a customer who runs both products and will say what changed.
A case study about your product alone, with the partner mentioned in passing, is not a partner case study. A case study about the partner's product, with you as a logo, is their asset. The joint piece has to show both products in the job. If you cannot name a customer who uses both, you do not have a partner story yet. You have an integration and a hope.
Named is not a nice-to-have. Prospects discount anonymous stories, and partner marketing teams rarely promote them. "A global brand" reads as "we could not get permission." If the customer will not be named, you can still write an internal win for enablement. Do not publish it as proof.
How you find the customer is usually obvious if you have been paying attention: the account that adopted first, the one that asked for the integration, the one whose champion will take a thirty-minute call. If you have no such account, the honest move is to go get one live, not to write around the gap. Sourcing proof is part of the partnership lifecycle, not a writing problem.
| Asset | What it proves | What it does not prove |
|---|---|---|
| Named partner case study | This pairing works for a real customer in a named job | That every customer will get the same result |
| Anonymous story | You can describe a workflow | That anyone will stand behind it |
| Quote-only testimonial | Someone liked you | That the pairing changed the job |
| Launch announcement | The integration exists | That anyone used it |
Use the case study as proof under a better-together story, not as a substitute for one. The story still has to be written. The case study is how you stop asking people to take the story on faith.
Structure: workflow before, workflow after
Open with the customer and the job, not with either company. Who they are in one line, what they were trying to finish, why it was painful. Then the before: the actual steps. Then the pairing, in the customer's words as much as possible. Then the after: the new steps. Then a result you can stand behind. Then a quote that comments on the job, not on how "excited" they are.
The before is the part most drafts skip. Without it, the after is a feature list. "They now sync records automatically" means nothing if the reader does not see the export, the spreadsheet, and the re-keying. Write the ugly version. That is what research on trust and credibility keeps pointing at: specific process beats polished claims.
Keep both products in the frame. If the after only describes your product, you have written a customer story with a partner cameo. Name what each product is doing in the new path, and name the handoff. The reader should be able to picture the job.
Length: enough for a seller to send, short enough that a prospect will read it. A tight page beats a six-page PDF. If you need a long version for a marketplace or a briefing, write the short page first and expand. Do not start from the long version and try to cut.
| Section | Job of the section | Common failure |
|---|---|---|
| Customer and job | Orient the reader in ten seconds | Starting with company history |
| Before | Make the pain concrete | Skipping steps, using adjectives instead of actions |
| The pairing | Show both products in the path | One product dominates |
| After | Show the new steps | Jumping straight to a metric |
| Result | One defensible outcome | Invented percentages |
| Quote | A human sentence about the job | "We're thrilled to partner" |
On metrics: use what the customer will approve and a seller will defend. Time saved on a named step, fewer handoffs, a job that used to miss a launch window and now hits it. If you do not have a number, the before-and-after of the steps is the result. Padding a vague "efficiency" claim is how you get a piece nobody believes.
Permission without killing the relationship
Ask before you write a full draft, not after. A champion who will take the call may still need legal, brand, and a manager. Treat permission as a small project with an owner and a date.
Make the first ask easy. "We want to write up how you run [job] with both products. You would be named. You would approve every sentence. You can refuse a quote and still approve the workflow." People say no to surprise PR. They often say yes to a draft they control.
Show a short draft, not a blank page. Champions are busy. A two-page draft they can redline beats an interview they have to prepare for. Record the call if they agree, and quote from their words, then let them edit. Do not clean their sentence into marketing copy they would never say.
Give them a way to shrink scope. Name and workflow, no metric. Name and metric, no photo. Quote from the champion, company name only. A smaller true piece is better than a large one that dies in legal.
Do not hold a renewal, a discount, or a feature hostage to the case study. That is how you get a yes that turns into a delayed no, and a customer who feels used. If they decline, thank them and ask whether you can use the workflow internally for enablement. Keep the public bar at true permission.
The partner has to approve too. Their brand team will care about logo, product name, and claims about their product. Send them the same draft. One version, two approvals. Two separate write-ups of the same customer is how you get conflicting numbers in the market.
Where the case study should live
Writing is half the work. Placement is the other half.
Your site. Put it on the integration or campaign page for that partner, and link it from the customer stories index if you have one. A case study that only lives in /blog/ and never on the pairing page will not get found by someone evaluating the integration. The partner page is the permanent surface; the case study is the proof attached to it.
Their site. Ask for a link from their integrations, marketplace, or customer stories surface. Make it easy: final URL, title, one-sentence blurb, screenshot. If they want to host a version, give them a copy that uses their house style, not a PDF of your blog post.
The marketplace. If the pairing is listed, the case study belongs in the listing, the supporting images, or the resource links. Listings that only describe features underperform listings that show a customer finishing a job. Follow their format. Do not paste a long article into a field that wants a paragraph.
Sales. A one-page PDF or a clean URL a seller can paste. Add it to the enablement kit. If a partner seller cannot find it in thirty seconds, it does not exist for co-sell.
| Home | Format | Owner of the ask |
|---|---|---|
| Your integration page | Full short story | You, at publish |
| Partner's integrations or stories | Link or their-hosted version | You, with a copy-paste blurb |
| Marketplace listing | Their required fields | You, at listing update |
| Enablement kit | URL plus one-pager | You, same week as publish |
Do not stop at "we published it." Check in a month whether the partner linked it and whether sellers sent it. For how this sits in a campaign, see the co-marketing playbook. A case study is a higher rung, not the first asset to ship.
Common mistakes, and the fix
Writing the story before you have a named customer. The fix: get someone live and willing, then write. An anonymous piece will not do the job you want.
Skipping the before. The fix: list the old steps in order. If you cannot, you do not understand the job yet. Interview again.
Leading with both companies' origin stories. The fix: customer and job in the first five lines. Company history does not belong here.
Inventing or stretching a metric. The fix: use a result the customer will say out loud on a call. Steps-before versus steps-after is enough.
Asking for permission after the draft is "done." The fix: ask early, send a short draft, accept a smaller scope. Late surprise is how pieces die.
Publishing only on your blog. The fix: integration page, partner surface, marketplace, enablement kit. Placement is part of done.
FAQ
What makes a partner case study different from a regular customer story? Both products have to appear in the job, and both companies have to be able to use the piece. A customer story that mentions the partner in passing is not joint proof.
Do we need a named customer? For a public partner case study, yes. Anonymous stories do not get promoted and do not survive a skeptical reader. Use unnamed write-ups internally if you must.
What if the customer will not share a metric? Write the before-and-after of the workflow. A concrete path is more believable than a vague percentage. Do not invent a number to fill a template.
How long should it be? Short enough that a prospect reads it and a seller sends it. A single page is the default. Expand only if a marketplace or briefing requires it.
Who has to approve it? The customer (champion plus whoever owns brand or legal on their side) and the partner. One draft, two external approvals, then you publish.
Where should we publish first? Your integration page, then enablement, then the partner's surface and the marketplace. The blog can syndicate. It should not be the only home.
When is it too early to write one? When no shared customer is live, happy, and willing to be named. Ship the integration, get adoption, then write.
Further reading
- The SaaS co-marketing playbook for where a case study sits on the ladder.
- Joint value propositions for the story the case study has to prove.
- Building a partner page that converts for the permanent home of the pairing.
- The full lifecycle of a SaaS tech partnership for why proof comes after adoption, not after the announcement.
- Case study, for the idea of evidence from a bounded instance rather than a slogan.
- Nielsen Norman Group on trust and credibility online.
- Harvard Business Review on the B2B elements of value, useful when you pick which outcome to feature.
The short version
A partner case study customers believe is a named shared customer, a job they already had, the steps before, the steps after, and permission to say it. Write from the workflow, keep both products in the path, and use a result a seller can defend. Ask for permission early, send a short draft, and accept a smaller true piece over a large one that never clears legal.
Publish it where evaluation happens: your integration page, the partner's surface, the marketplace, and the kit sellers actually open. A blog post nobody links is not a case study program. If you do not yet have a customer who will go on the record, go get the pairing used. Writing cannot invent proof.
If you want help turning a live pairing into proof the field will use, that is what a Partner Audit is for. We review the partnership, the customer evidence you actually have, and the story worth putting on the page.