Case Study Variable Builder
Documents variables in case study prompt templates — client, industry, challenge, solution, results, metrics, and quote.
Overview
Case study templates are often written once and reused across dozens of client engagements. Two problems accumulate over time. The first is naming drift: {{keyMetrics}}, {{metrics}}, and {{results}} end up in different template copies even though they should not always mean the same thing — results might be a narrative paragraph, metrics a list of numbers, and key metrics a short executive summary. The second is format ambiguity: {{results}} alone doesn't tell the next writer whether to fill in bullet points, percentage figures, or a short prose paragraph. Documenting both the variable names and their expected format, before the template is handed to a team or agency, prevents inconsistent output across the portfolio.
Workflow
-
Open in Prompt Variable Builder
Load the template. The tool detects all ten variables including clientName, industry, challenge, solution, results, and keyMetrics.
-
Check for similar variable names
If your existing template uses {{keyMetrics}}, {{metrics}}, or {{results}} in different combinations, the similarity check will flag them. Decide whether they should be separate variables with distinct meanings, or consolidated into one — and document the difference in the description field before the template is shared.
-
Add format descriptions for ambiguous fields
Results and keyMetrics are the fields where format ambiguity causes the most inconsistency. In the description field, specify what each variable expects: whether results should be a bullet list of outcomes, a short prose paragraph, or a narrative summary. When a writer is assigned a batch of ten case studies, this documentation tells them exactly how to fill in each field without asking.
-
Export and assign
Use the Markdown doc as the writer reference for the entire batch. Use CSV to assign each variable to a specific team member or production stage.
Why This Works
- {{keyMetrics}}, {{metrics}}, and {{results}} are the naming combination most likely to appear across different versions of the same case study template — when they mean different things, documenting the distinction prevents a writer from filling in the wrong format
- When a writer is assigned a batch of case studies, the variable documentation tells them whether {{results}} expects bullet points, metric values, or a prose paragraph — without requiring a separate briefing conversation
- Client quote and speaker attribution are frequently split into separate variables in different template versions — naming them explicitly (clientQuote and quoteSpeaker) prevents the two pieces of information from being combined into one field
Best for
- Case study templates reused across multiple clients in the same industry or service line
- Agencies or consultancies where different team members write different sections of the same case study
- Content teams producing case studies at volume where format consistency across results and metrics fields matters
Not for
- One-off case studies written from scratch without a standard template
- Case studies so specific to a single client that the template structure changes entirely for each
Use cases
- Auditing a case study template for naming drift before a batch of client engagements — catching {{keyMetrics}}, {{metrics}}, and {{results}} used interchangeably across different template versions
- Documenting the format expectations for results and metrics before the template is handed to a freelancer — specifying whether bullet points, prose paragraphs, or percentage figures are expected
- Generating a CSV variable list to assign writing responsibilities to different team members for a batch of case studies
- Exporting a JSON schema for a case study generation pipeline that feeds into a CMS