The Case Study Approval Process: How to Get Sign-Off Without Chasing

The short answer: approval is where B2B case studies die, and it usually takes one to three weeks. The delay is almost never disagreement. It is that the draft sits in an inbox, gets forwarded internally without you knowing, and nobody in the chain is sure whose turn it is. The fix is to make approving easier than replying: send the finished story on a link the reviewer can open without an account, give her a way to change it herself, and show her where every number came from.

Why does case study approval take so long?

Ask a marketing team where their case studies get stuck and almost nobody says writing. They say approval. The draft goes out on a Tuesday, the customer says "looks great, just need to run it past a couple of people," and six weeks later it is still not live.

Three things are happening at once, and none of them is disagreement.

Every row on the right is a process failure rather than a relationship problem, which is why nudging harder rarely works and changing the mechanism usually does.

The first is that approval is asynchronous and unowned. Once you send a draft by email, you lose visibility. The customer forwards it to her manager, who forwards it to communications, who has a question about the logo. Nobody tells you any of this. From your side it looks like silence, so you send a polite nudge, which lands in the same inbox as the thing that is already stuck.

The second is that you are asking for more work than you think. "Can you review this?" sounds small. What it actually means is: read 800 words carefully, decide whether every claim is defensible, check whether your company is comfortable being named next to a competitor's logo, confirm the numbers are ones you are allowed to share, and take personal responsibility for all of it. That is not a five-minute task, so it goes to the bottom of the pile.

The third is that reviewers cannot verify anything. A number in a draft is just an assertion. If your customer's head of communications reads "reduced onboarding time by 78%" and has no way to check where that came from, the safe answer is always to delay and ask. Every unverifiable claim adds a round trip.

What does the case study approval process actually involve?

There are five steps, and most teams only plan for two.

1. Confirm the facts with the person you interviewed. She is the only one who can tell you whether you understood her correctly. Do this before anyone else sees it.

2. Get the quote approved as written. Quotes are the single most-edited element in any case study, because people are more careful about words attributed to them than about narrative describing them. Expect changes here and do not treat them as a setback.

3. Clear the company name and logo. This is a different decision from whether the story is accurate, and it is often made by a different person. A customer can be delighted with the story and still not be allowed to let you use the logo.

4. Survive internal review. In enterprises and regulated industries this means legal or communications. They are checking claims, competitor mentions, and whether anything in the story reveals something the company does not disclose publicly.

5. Record the approval. Keep the exact final text and the written confirmation. If the story changes later, you need to know what was actually agreed to.

Who needs to approve a B2B case study?

Assume at least two people, and design for a third you have never met.

The practical consequence: whatever you send has to survive being forwarded to someone who was not on the call, has no context, and did not agree to anything. If your approval mechanism is a Word document attached to a thread of twelve replies, that person cannot act on it. They can only add another reply.

How do you make approval faster?

Make approving easier than replying. That single principle covers almost everything that works.

Send a link, not an attachment. An attachment forces the reviewer to download, open, and then compose an email describing what she wants changed. A link that renders the finished story means she reads it in the same place she responds.

Do not require an account. The moment a reviewer has to create a login to approve something, you have added a reason to do it later. This matters most for the third reviewer, the one who was forwarded the link and has no relationship with you at all.

Give her more than yes or no. A binary approve-or-reject button forces anyone with a small objection into the slowest possible path, which is writing an email explaining it. Three outcomes work far better: approve, request a specific change with a note, or edit the text directly. Letting a reviewer fix a sentence herself removes the translation step where a marketer reads a comment, guesses what was meant, and gets it wrong.

Show where every number came from. This is the one most teams miss. If a metric card opens the passage of the interview it was taken from, a reviewer can check the claim against the customer's own words rather than taking it on trust. Unverifiable numbers are the most common reason a legal reviewer sends a draft back.

Keep an honest change history. When someone edits a figure, the record should say so and keep the original passage. A number that has been changed should never silently keep the authority of a number that came straight from the recording.

Approval by email versus approval built into the product

Two fixes experienced marketers arrive at independently

Ask practitioners how they solved this and two answers come back repeatedly, from people who have clearly learned them the hard way rather than read them anywhere.

Bring the customer something nearly finished rather than a request for help. Asking a customer to help you build a case study sounds collaborative and lands as work. Handing them a draft that is almost done and asking them to correct it lands as a favour that takes ten minutes. The response rate difference is large, and the reasoning is obvious once stated: you have moved the effort from them to you, and the effort was always going to be cheaper on your side.

The implication most teams miss is that this changes what you need from the interview. If the customer's job is to correct a draft rather than supply the raw material, the draft has to exist before you ask, which means the interview has to happen earlier and be structured enough to write from.

Attach a source to every number so legal has less to ask about. The second recurring answer comes from people who have been through enterprise review. What holds a draft up is rarely the narrative. It is the figures and the wording, and it is worse when every case study arrives as a brand new document that has to be assessed from scratch. If each number carries a visible source, the reviewer's default question is answered before they ask it.

Both of these are workarounds for the same structural problem, and both describe, almost exactly, what a well-built approval step should just do: reduce the customer's job to reviewing rather than producing, and make every claim checkable at the point of review rather than defensible on request.

What if the customer goes silent?

Silence almost always means stuck, not no.

Send one follow-up after two or three days, and make it smaller than the original ask. Instead of "any thoughts on the draft?", ask a single question with a yes-or-no answer: "Happy for us to publish as-is, or is there anything you want changed?" A yes-or-no question can be answered from a phone in ten seconds. A review request cannot.

If that gets nothing, offer to reduce what you are asking for. Publishing anonymously, or with the company described rather than named, removes the entire internal-approval problem in one move. A story about "a 200-person logistics company" that you can actually publish beats a named story that never ships.

If two follow-ups get nothing, stop. Keep the relationship. Publishing without genuine sign-off turns a happy customer into an unhappy one at exactly the moment you were trying to celebrate them, and it is not worth one page on your website.

Do you need a case study release form?

Usually not, and teams often over-engineer this.

For most B2B software case studies, what companies actually rely on is explicit written approval of the final draft, kept on file. A separate signed release becomes worth the friction in three situations: you are naming a company in a regulated industry, you plan to use the logo in paid advertising rather than just on your site, or the customer's procurement process expects one as a matter of policy.

Whatever route you take, the thing that matters is that the approval is specific. "Sounds good" in reply to a calendar invite is not approval of an 800-word document. Get sign-off on the exact final text, and keep a record of what was approved and when.

This is not legal advice. If you are in a regulated industry, ask your own counsel.

What good approval looks like

The test is simple. Can the person who was forwarded your story, who has never met you, act on it in under five minutes on a phone?

If the answer is yes, approval stops being the step that kills your case studies. If the answer is no, everything else you do to speed up case study production just moves the bottleneck one step later.

StoryVoice builds this step into the product rather than leaving it to email. The finished story goes to the customer on a link that needs no login and no account. She can approve it, request a specific change in her own words, or edit the story herself. Every metric card opens the passage of the recorded interview it was read from, so she and anyone she forwards it to can check a number instead of trusting it. The change history names real people rather than saying "you", so she and the marketer read the same account of who changed what. And if the request goes quiet, the marketer gets nudged after two days rather than finding out three weeks later.

Send your first case study for approval free — no credit card required. Or read how to get customers to say yes in the first place, which is the step before this one.

Approval timelines and reviewer roles in this article reflect common B2B software practice rather than a published survey; where we could not verify a number, we have not invented one. Product behaviour described for StoryVoice is current as of 2026-08-16.