A team that has been using Copilot or ChatGPT for six months has built up a working set of prompts. They live in chat histories, in saved messages, in the heads of the two power users, on the back of one person's notebook. The prompts work, but the value of them is locked inside individuals. New joiners do not get them. Adjacent teams do not see them. When the power user goes on holiday or moves on, the prompts go too.
A prompt library fixes that. It is unglamorous work and it is the single highest-leverage piece of infrastructure for an AI rollout past the pilot phase. Here is the shape that lands.
What a prompt library actually is
Three things, in that order:
- A list of prompts the business has tested and decided to keep. Each one tied to a specific workflow, written down in the form the user actually pastes in.
- A short description of when to use each one. Not "this prompt is for emails", which is not specific enough. "Drafting a follow-up email after a discovery call, when the call notes are pasted in above."
- A worked example of input and output. Real input, real output, ideally with the names changed. Without the example, the user has to guess what the prompt expects.
That is the unit, and multiplied by the workflows the business runs, it becomes a library.
Where it lives
Two principles: it lives where the team already works, and it is searchable.
For an M365 business, that is usually a SharePoint site, with one page per workflow category and the prompts as expandable sections inside the page. For a Google Workspace business, a Drive folder with one Doc per category. For businesses that have Notion or Confluence, those work fine; the test is whether the team can find a specific prompt in under thirty seconds.
What does not work: a chat in Slack or Teams ("just check the pinned posts"), a OneNote notebook nobody opens, an Airtable that requires another login. Friction kills adoption. If the user has to think for more than ten seconds about where the prompt library is, they will not check before writing the prompt themselves, and the library stops being the source of truth.
How it is structured
By workflow, not by role. The library is for "drafting a customer follow-up" or "summarising a long document" or "extracting line items from an invoice", not for "the sales team prompts" or "the finance team prompts". The same prompt may be useful across roles.
Inside each workflow page, three to five prompts maximum. More than that and the user picks the wrong one. Better to have one strong prompt per pattern than four similar ones.
Each prompt page has:
- The prompt itself, in a code block so it copies cleanly.
- The one-sentence "when to use this".
- The worked example, input and output.
- Who owns it (a named person, not a team).
- The last review date.
The owner and the date are the part most libraries skip. Without them, prompts go stale and nobody catches it.
Who owns the library
One named person, usually the IT lead or whoever ran the rollout, with deputies for each main team. The owner's job is to add new prompts when the team finds them, retire prompts that stop working, and run the quarterly review.
The deputies' job is lighter. They are the "ask me which prompt to use" person inside their team, and they flag candidate prompts to the owner. Three to five deputies for an SME of 25 to 50 people is the right shape.
What does not work: making the library a community wiki anyone can edit. Quality drops, duplicates appear, and the trust the team has in the library disappears within a quarter. The model that works is a small group of editors with a clear pipeline for contributions from everyone else.
How prompts get in
A pipeline, not a free-for-all. The shape:
- A team member finds a prompt that works. They use it for a week to make sure the value is real.
- They submit it to their deputy. A simple form or a Slack message, with the prompt, the workflow, and the worked example.
- The deputy reviews and forwards to the owner. The review is light; the owner adds the prompt, sets the owner field, and announces it.
- The team is notified. A monthly "new prompts this month" digest, three to five items, with a link to each.
The submission-to-publication time should be under a week for the pipeline to feel responsive. Longer than that and people stop submitting.
The quarterly review
The review is the discipline that keeps the library trustworthy. Once a quarter, the owner and the deputies go through every prompt and answer three questions:
- Has the model output changed materially since this prompt was added? (Model updates can break a working prompt.)
- Is the workflow still real, or has the team stopped doing it?
- Are there two prompts doing similar jobs that should be merged?
The review usually retires a quarter of the library and adds new ones to balance. A library that is the same size and the same prompts after a year is a library nobody is using.
What success looks like
Six months in, the library is the answer to "how do I use Copilot for X" for most of the business. New joiners get pointed at it on day three of induction and have working prompts inside a week. The two power users who built most of the initial set are still contributing, but they are no longer the bottleneck. The team's collective prompt skill is rising, not concentrated.
The licence cost is the same as it always was. The value is twice what it was at the post-pilot stall, because the prompts are now team knowledge rather than individual knowledge.
Where this lands with us
The library is one of the deliverables of our AI Enablement engagements. We seed it during the pilot with the prompts the pilot users discover, hand it over with the structure and owner in place, and check in at the quarterly reviews if the client wants us to. After the first review, most clients run it themselves.
The library is the smallest piece of infrastructure with the biggest effect on whether a rollout produces compound value or peaks at month three and tails off.
Working on the prompt-library piece of an AI rollout and want a template to start from? Drop us a note at info@jmopartners.co.uk.
JMO|Partners · Enterprise IT, sized for SMEs.