Every organization has this problem: the person who knows how to do something leaves, and nobody can replicate their work. Not because the work is hard, but because the knowledge of how to do it well — the specific phrasing for customer emails, the criteria for qualifying leads, the questions to ask during vendor evaluation — lived in that person’s head.
SOPs are the traditional solution. Write down the process. Put it in a wiki. Hope someone reads it.
SOPs are better than nothing, but they have a fundamental limitation: they describe work without doing it. A person still reads the SOP, interprets it, and produces output. The output quality depends on the reader’s skill, attention, and judgment.
Recipes encode how, not just what
A recipe is an executable SOP. It doesn’t describe how to research a prospect — it actually researches the prospect, following the exact approach encoded in the prompt template.
Consider a sales team’s prospect research process. The traditional SOP might say:
- Look up the company on LinkedIn and Crunchbase
- Note recent funding rounds and key executives
- Check for recent news or product launches
- Identify potential pain points based on company size and industry
- Summarize findings in the standard format
A recipe encodes the same knowledge differently:
Prompt template:
Research the following company and produce a comprehensive prospect brief.
Company: {{company_name}} Website: {{website_url}}
Include: company overview, founding date, employee count, recent funding, key executives (name, title, LinkedIn), tech stack, recent news and product launches, industry trends affecting them, and potential pain points based on their company stage and market position.
Focus on actionable intelligence that a sales rep can reference in outreach.
Output schema:
company_overview (string), key_executives (array), recent_funding (object), tech_stack (array), recent_news (array), pain_points (array), outreach_angles (array)
The difference: when the person who wrote this SOP leaves, their replacement reads the document and produces something. When the person who created this recipe leaves, the recipe keeps producing the same quality output. The knowledge is encoded in the instructions and the schema, not in a person’s interpretation of a checklist.
Institutional knowledge compounds
Over time, recipes accumulate the team’s expertise. The prospect research recipe gets refined: someone notices that including “competitive landscape” in the output improves outreach quality, so they add it to the schema. Someone else discovers that asking for “buying signals” produces more actionable output, so they update the prompt.
Each improvement is permanent. It applies to every future run. The recipe gets better as the team uses it, and those improvements never walk out the door.
Compare this to a traditional SOP. When someone discovers a better approach, they might update the wiki page. Or they might just start doing it the new way and forget to update the docs. Over time, the SOP diverges from actual practice, and nobody trusts the documentation.
Schemas enforce consistency
A recipe’s output schema is something SOPs can’t replicate. When the schema says the output must include risk_level (enum: high, medium, low), every run produces that classification. When the schema says action_items is an array of objects with description, owner, and deadline, every run produces structured action items.
This consistency means:
- New team members produce output indistinguishable from veterans
- Results can be aggregated and compared across runs
- Downstream workflows can reliably consume the output
- Quality metrics are measurable
A traditional SOP might say “classify the risk level as high, medium, or low.” A recipe guarantees it.
Building a recipe library
The most effective teams treat their recipe library as institutional knowledge infrastructure:
- Core processes get recipes. If you do it more than once a week, it should be a recipe.
- Recipes get version-controlled. The prompt template and schema evolve as the team learns what works.
- New hires start with existing recipes. Instead of reading a wiki and guessing, they run the recipe and see what good output looks like.
- Departing employees’ recipes stay. Their knowledge persists in the template, not in their notes.
From individual recipes to team workflows
Individual recipes capture task-level knowledge. Workflows capture process-level knowledge — the sequence of tasks, the decision points, the approval gates, the conditions that route work differently.
A workflow for the hiring process encodes not just how to write a job description (that’s a recipe) but the entire flow: job description → resume screening → interview prep → debrief → offer or rejection. The workflow captures the order, the branching logic, and the handoff points.
When the hiring manager leaves, the process doesn’t reset to zero. The workflow keeps running with the same quality and consistency. The new manager reviews outputs and makes decisions, but the process itself is preserved.
Getting started
You don’t need to convert every SOP into a recipe on day one. Start with the tasks your team does most frequently and where consistency matters most. For most teams, that’s:
- The task that new hires struggle with the most
- The task that produces the most variable output across team members
- The task that takes the longest but follows a predictable pattern
Create a recipe for each one. Run it a few times. Refine the prompt and schema based on the output quality. Within a week, you’ve captured institutional knowledge that would have taken months to document traditionally — and unlike documentation, the recipe actually does the work.