Prompts are the new standard operating procedures.

Any prompt that runs part of your business is a standard operating procedure, and it deserves the same controls: a named owner, a version number, an approval before it changes, a test it has to pass and a date when someone looks at it again. Most companies give their prompts none of these. The result is policy that changes without anyone deciding to change it.

You do not need a prompt management platform for this. A shared register and some discipline will do. What has to change is the habit of treating the text that instructs an AI model as a setting, when it behaves like a document.

Where your prompts live now

Make a list before you make a policy. In a company that has used AI for a year, the prompts doing real work are usually scattered across places like these:

• the instructions box in your helpdesk’s chatbot or AI assistant settings;
• a step in a Zapier or Make automation that scores leads or drafts replies;
• a custom GPT, a Claude project or a Gemini Gem that one person built and ten people now use;
• a pinned Slack message titled “the good prompt for case studies”;
• a string in your codebase, written by an engineer who has since moved teams.

Each of those is a procedure. It tells a worker how to handle a class of situations. If the worker were a person, the instructions would sit in your operations manual with a version number on the first page. Because the worker is a model, they sit in a text box, and the text box has no history.

Every edit is a policy change

Here is a hypothetical that will feel familiar. A support lead notices that upset customers cancel more often. She opens the chatbot settings and adds one line: “If the customer is upset, offer a 10% credit on their next invoice.” It takes a minute, and nobody reviews it, because it does not look like a decision.

But the company now has a discretionary credit policy, applied by software to anyone who sounds annoyed, including the customers who learn that sounding annoyed works. Finance finds out at the end of the quarter.

Customers and courts read what a bot says as what the company says. In February 2024 a Canadian tribunal held Air Canada to a refund promise its website chatbot had made up, and rejected the airline’s argument that it was not responsible for the bot’s answers (Moffatt v. Air Canada, 2024 BCCRT 149). If the bot’s words bind you, then the system prompt that shapes those words is a policy document, whatever tool it happens to live in.

Why Git is the wrong home for most business prompts

Search for advice on managing prompts and most of what ranks says prompts are code: keep them in Git, give them semantic versions, deploy them through a pipeline. A lot of that advice comes from companies that sell prompt management software. For prompts built into a product, it is right. Engineers should version the prompts their code depends on, next to the code.

But most prompts that run a business are written and changed by people who never open a terminal: support leads, marketers, operations managers. Ask them to open pull requests and they will keep editing the text box. And the review these prompts need is rarely a code review. It is a review of policy, tone and risk. Should the bot offer that credit? May it mention a competitor? What does it say when someone asks to delete their data?

Quality teams solved this long ago with document control. ISO 9001, the quality management standard, expects controlled documents to be available where the work happens and their changes to be controlled, with version control given as the example (an explainer of clause 7.5.3). You do not need the certificate. Borrow the habit.

The prompt record

Give every prompt that touches a customer, money or a decision about a person a short header. Keep it at the top of the prompt’s home, or in a register next to it. Here is one, filled in for a made-up billing assistant:

Prompt:       Support assistant, billing questions
Purpose:      Answer billing questions from the help center; hand off the rest
Owner:        Head of Support
Approver:     Finance lead, for anything about credits, refunds or prices
Version:      3.2, in effect from October 20, 2026
Runs on:      Chat widget on the billing page, Claude Haiku 5.5
Inputs:       {{customer_message}}, {{plan_name}}, {{help_articles}}
Test suite:   42 cases; 3.2 passed 41 (one known issue, logged)
Changes:      3.2  Removed the 10% credit line (not approved by Finance)
              3.1  Hand off when a customer mentions a chargeback
Next review:  January 15, 2027, or sooner if the refund policy changes

Eleven lines. Each answers a question you will otherwise ask in a hurry, usually after a customer has posted a screenshot: who decided this, when did it change, what did it say before, and does it still work?

Owners, not authors

The owner is the person accountable for what the prompt does in the world, not whoever typed it. Put ownership where the consequences land:

• Support prompts belong to the head of support.
• Anything written in the brand’s voice belongs to whoever owns the brand.
• Lead scoring and routing belong to sales or revenue operations.
• The plumbing (which model, which key, where it runs, what it costs) belongs to engineering.

Then name approvers for the clauses that carry risk. Finance signs off anything that mentions money. Legal reads anything that makes a commitment. Most edits need neither, and the record says which is which, so nobody has to guess.

The most dangerous prompt in your company is the one nobody owns, because it still runs every day.

Review means running the tests

A procedure for people is reviewed by reading it. A prompt cannot be reviewed that way, because a change that reads well can behave badly. One added sentence about warmth can make a bot stop quoting order numbers, and nothing in the diff will tell you.

So the review step is a test run. Keep a set of real inputs for each prompt, somewhere between 10 and 40 test cases, with checks for what a good answer must do. Run the current and the proposed version on all of them before the new one goes live. The report you want fits in a sentence: version 3.2 fixed two cases and broke none. If it broke one, the owner decides whether that regression is acceptable and writes down why.

Our tools do this in a browser tab. Version Compare shows what changed between two versions, word by word, and what the change does to length and token cost. Prompt Tester runs both versions on your test cases and lists the cases each change fixed or broke. The My Prompts keeps every version you save, with history and rollback. It lives in your browser, so treat it as your working copy and export it to wherever your team keeps controlled documents.

Review dates, because the ground moves

A procedure for people goes stale when the business changes. A prompt also goes stale when things you do not control change underneath it.

• The model retires. Anthropic’s deprecation schedule has Claude Sonnet 4.5 reaching end of life on November 30, 2026. A prompt tuned on it has to be retested on whatever replaces it.
• The price moves. Google’s Gemini API pricing lists Gemini 4 Argon at an introductory price until November 30, 2026, and Gemini 3.8 Flash at double its current price from January 1, 2027. The cheapest model that passed your tests this quarter may not be next quarter.
• Your own policy moves. The refund window drops from 30 days to 14, the help center is updated, and the prompt still contains an example answer that says 30.

Put a review date on every record: quarterly for anything customer-facing, and at once when a policy it mentions changes. A review that finds nothing to fix still gets a new date, so the next person knows someone looked.

Start with three prompts

Start small and finish it.

1. List every prompt that talks to customers, touches money or makes a decision about a person (a lead score, a ticket priority, a screening question). Write down where each one lives.
2. Pick the three with the worst plausible failure. The customer-facing bot is almost always one of them.
3. Give each an owner and a record. Paste the current text in as version 1.0, mess and all.
4. Collect ten real inputs for each, including two awkward ones, and note what a good answer must do. Run them once to get a baseline.
5. From then on, a change means a new version, a test run and a line in the change log. Put the next review date in a calendar.

After a month, those three records will tell you something the text boxes never did: how often your procedures change, and who changes them.

Keep reading

• Your chatbot’s system prompt is a contractScope, refusals and escalation, written as clauses you can test.Blog
• How to test a prompt before you ship itBuild the test suite that every new version has to pass.Guide, ends in the Prompt Tester
• How to choose an LLM: the cheapest model that passesSet the bar, test across price tiers, then price at your volume.Blog