Case study request form: get customer stories for LinkedIn

A case study request form works when it asks a customer for five things in one sitting: the problem they had, the result they got, a quote, who you may name, and where you may publish. Collect those with explicit permission and a story can be drafted and approved in one pass, with no email thread to chase.

Use the case study request template

Why chasing by email stalls

The usual flow goes like this. You ask a happy customer if they would "be up for a case study." They say yes. You send five questions in an email, they answer two, and the rest sits in their inbox for a month. When you finally draft something, legal or their marketing lead wants to see it, and nobody remembers what permission was actually given.

Three things break in that flow. The ask is open ended, so the customer has to decide waht to write. The answers arrive as a thread you have to reassemble. And permissin lives in a vague "sure, go ahead" that doesn't say whether you can use the logo, the person's name, or the numbers.

A form fixes all three. Each question is small and specific, the answers land in one record, and the permission is a set of checked boxes with a date on them.

The minimum fields

You can ask for more, but every exxtra question lowers the odds the customer finishes. This is the set we would start from for a LinkedIn story.

Ten questions or fewer is a good target. The one most teams skip is "what did you try first." It is the question that makes the story usful to a buyer who is still comparing options.

Permission wording that survives review

Put permission on its own page at the end, after the customer has already told the story. By then they know what they are agreeing to publish. Here is wording you can adapt:

I give [Your Company] permission to publish the information I provided in this form, limited to the items I checked above and the channels I selected. [Your Company] will send me a draft before anything is published, and nothing goes live until I approve it in writing. I can withdraw this permission at any time by emailing [address], and [Your Company] will remove the story from channels it controls.

Three details matter here. The permission is limited to the checked items, so a customer who ticks "company name" but not "logo" is not agreeing to the logo. The approval promise is staated in the form itself, which is usually what makes a nervous customer say yes. And the withdrawal route is a real email address.

Make the permission checkboxes required and keep the signature on the same page. This is not legal advice. If your customers are regulated businesses or sit in the EU or UK, have counsel read the wording once, then reuse it.

Setting it up, step by step

1. Start from a template. Open the case study request template and cut it down to the fields above. Delete anything a customer would need to look up.
2. Add hidden fields. Create hidden fields for account owner and deal ID, and pass them in the link you send. The customer sees a form that already knows who they are. The hidden fields help article covers the setup.
3. Write questions as prompts. "What was happening before you started with us?" gets a paragraph. "Describe your challenges" gets a sentence of corporate filler.
4. Add the permission page. Use a New page block, then the checkboxes, the wording above, and a Signature block. Mark them required.
5. Turn on partial submissions. If a customer answers six questions and gets pulled into a meeting, you still have six answers and know exactly where they stopped.
6. Set the thank-you page. Say what happens next: "You will get a draft within a week. Nothing is published until you approve it." Turn on the confirmation email to the respondent so they have a copy of what thry agreed to.
7. Publish on your own subdomain. Something like stories.yourbusiness.com looks more like part of your company than a third-party form link. See custom domains for the CNAME and TXT records.
8. Connect a webhook. Send each submission to wherever your drafting happens, covered below.

We build Qwenvo, the form builder we use for this, and it is completely free. Webhooks, the API, partial submissions, a custom domain, switching off the badge, teammates and custom CSS are all included. Several of those sit on paid plans elsewhere. For example, Tally charges for partial submissions and custom domains on Pro, and Fillout puts custom domains and partial submissions on Business.

One honest caveat: Qwenvo is hosted in the United States, while Tally is hosted in Europe. If a customer's procurement team insists on EU hosting for anything they fill in, that may decide the tool for you.

Build your case study form free

Where the form sits in the weekly content flow

In the Founder Content Engine, a 30-minute founder call each week becomes LinkedIn posts, a newsletter, short clips and cross-posted social content, wiith an approval step before anything goes out. Most of that material is opinion and experience, which is good for reach. It is weaker at the thing a buyer chcks last: proof that someone else got a result.

The case study request form is the intake for that proof. On client projects we treat it as a second input beside the call. The founder or account owner sends the link after a milestone, the answers arrive as one structured record, and the drafting step starts from the customer's own words instead of from memory. The same approval step applies, with one extra gate: the customer approves the draft too.

That structure is why the form asks for a quote and for approval preference up front. Both save a round trip later.

Routing the answers

A webhook sends each submission to a URL as soon as it lands. Whatever receives it (Zapier, Make, n8n, or your own endpoint) should end up with a record shaped something like this:

{
  "customer_name": "Priya Raman",
  "job_title": "Head of Operations",
  "company": "Example Logistics",
  "problem": "Quotes took two days because ops re-keyed every request.",
  "decision": "Tried a shared inbox first; chose us for the routing rules.",
  "result": "Same-day quotes for most requests.",
  "quote": "We stopped dreading Monday mornings.",
  "may_publish": ["name", "job_title", "company_name"],
  "channels": ["linkedin", "newsletter"],
  "approval": "draft_first",
  "signed_at": "2026-11-06",
  "account_owner": "sam",
  "deal_id": "D-2041"
}

The values are made up; the shape is the point. Your receiving step maps the form's answers into these fields, and the draftong step reads may_publish before it uses a logo or a number. If a field is missing from may_publish, it does not appear in the draft.

Qwenvo's AI triage can also help on the inbound side. Each submission gets a category, priority and a short summary, and routing rules can email up to five addresses or post to a Slack incoming webhook. We would use that to flag a submission where the customer hedged on permission, so a person reads it before anything is drafted.

What to measure

Track three numbers. How many requests you send, how many customers finish, and how many drafts get approved without a rewrite. The partial submisssions view shows where people stop, and the drop-off analytics show which question loses them. If the "what changed" question is where they leave, make it optional or rephrase it. Customers are often cautious about numbers.

Questions teams ask

Do I need legal review of the permission wording?

If you publish customer stories at any scale, have counsel read it once. The wording above is a starting point, not legal advice. Customers in regulated industries may also have their own rules about being named, so the draft approval step matters more than the checkbox.

What if the customer won't share numbers?

Let them describe the change in words. "Quotes used to take two days and now go out the same day" is still a reslt. Keep the numbers question optional and place it after the plain description.

Can the customer edit the draft?

Yes, and the form should promise it. Choosing "show me the draft first" in the approval field tells your team to send the written draft before anything goes live. Treat their edits as final, even if the original sounded better to you.

Who should send the link?

The person with the relationship, usually the account owner or the founder, because a request from a name they recognize gets answered. Pass that person's name in a hidden field so the confirmation email and any follow-up come from someone the customer knows.

Next step

Open the case study request template, trim it to the ten fields above, paste in the permission wording with your company name, and send the link to one customer you already know is happy. Check how long it takes them to finish, and fix the question where they slow down before you send it to anyone else.