Prompt Engineering for Business Teams: Marketing, Sales, Engineering, Ops

Key takeaways:

• Function-specific prompts outperform generic ones because each function has repeating artifacts — a brief, a proposal, a postmortem, an SOP — and each artifact has a known shape. Baking the shape into the prompt is what produces usable output.
• The four business functions have different AI taxes. Marketing fights generic language. Sales fights impersonal copy. Engineering fights shallow analysis. Operations fights missed edge cases. The prompt patterns differ because the failure modes differ.
• All function prompts share one scaffold: role + context + task + format + acceptance. That envelope is universal; the content inside it is function-specific.
• The fastest path to team adoption is a shared prompt library where each prompt is named by the artifact it produces ("creative brief v2," "incident postmortem v3"), not by the technique it uses.
• Governance matters less than maintenance. A library that nobody updates decays into a set of prompts that encode last year's assumptions. Assign owners per function and revisit on a predictable cadence.

Most teams adopt AI the same way: someone tries ChatGPT, shares a tip in Slack, and a month later everyone is prompting slightly differently. The outputs vary wildly. Some are great, most are generic, a few are embarrassing. The issue is not the model — it is that nobody has mapped the work to the prompt.

This guide maps the four big business functions — marketing, sales, engineering, operations — to the task archetypes each one repeats, and to the prompt patterns that produce usable output for each. It ends with the cross-function scaffold every good prompt shares, and a rollout playbook for introducing patterns without turning into a governance bureaucracy.

Why Generic Prompting Fails at Work

A "write some marketing copy" prompt gives back something that sounds like any marketing copy — hollow adjectives, a call to action, a safe closing line. It reads fine in isolation and falls apart when you put it next to work your team has already shipped. The same pattern repeats everywhere. A "help me with this discovery call" prompt produces generic discovery questions. A "review this architecture" prompt produces generic architecture commentary.

The failure is not the model. The failure is that the prompt carries almost no information about what this specific artifact looks like when it is good. Marketing briefs have audiences, insights, and deliverables. Discovery notes have buyer context, pain hypotheses, and next steps. Architecture reviews have assumptions, trade-offs, and alternatives. Omit the shape and the model fills it with whatever it has seen most.

One-shot conversational prompting also loses the compounding benefit of reuse. When everyone on the team writes ad-hoc prompts, you get ad-hoc outputs. When the team shares a prompt that has been refined across ten uses, everyone benefits from every refinement. That compounding is the real argument for function-specific patterns — not that any single prompt is magical, but that a library that gets better with use is.

There is a second failure mode worth naming: prompts that contradict themselves. "Write professional but funny copy, short but comprehensive, edgy but on-brand." The model has to pick which constraint to honor, and the result is uneven. Shared prompt templates force the team to resolve contradictions up front, which is why templated output is more consistent even when the underlying model is the same.

Here is a compact table of what generic prompting gets wrong in each function:

The fix in each case is not a better model — it is a prompt that encodes the shape of the artifact the function actually needs. That is the job of function-specific prompt patterns.

For a broader take on why shared patterns beat ad-hoc prompting, see our prompt engineering basics guide and the patterns catalog in AI prompts for marketing and AI prompts for sales.

The Four-Function Framework

Four functions cover most of the AI-usable work in a typical company. Each has a characteristic relationship to language and reasoning, which is why their prompt patterns diverge even though they share a scaffold.

• Marketing → language production at scale. The central act is producing copy — for landing pages, ads, emails, social, briefs. AI amplifies production speed; the risk is bland, undifferentiated output. The prompt's job is to encode audience, insight, and voice.
• Sales → personalized persuasion. The central act is building relationships through structured conversations — discovery, proposals, forecasting commentary. AI helps with preparation and drafting; the risk is output that sounds templated. The prompt's job is to encode buyer context and next-step logic.
• Engineering → structured analysis and documentation. The central act is reasoning about systems and writing them down — architecture reviews, postmortems, specs. AI helps with structure and coverage; the risk is confident but shallow analysis. The prompt's job is to force trade-offs, alternatives, and non-goals into view.
• Operations → process consistency. The central act is standardizing how work gets done — SOPs, vendor evaluations, automation plans. AI helps with completeness; the risk is missing edge cases and exception paths. The prompt's job is to force step-level detail and exception handling.

The four functions differ on what "good" looks like, which is why a single prompt template does not serve all of them. Here is the framework laid out directly:

Three patterns show up across all four functions regardless of content: a system-prompt layer that encodes the team's standards, a few-shot slot for a real past artifact, and an acceptance section the reviewer can check against. Those are the spine of the cross-function scaffold later in this guide.

Marketing

Marketing's core act is producing language at scale — and the function's AI tax is that most AI-generated marketing language sounds the same. The fix is not a cleverer hook; it is encoding the inputs that actually differentiate good marketing work: audience, insight, format, and a real example. The three highest-leverage marketing archetypes below show how that plays out in practice.

Creative and campaign briefs

A brief is the interface between strategy and execution. A good brief has five parts — objective, audience, insight, deliverables, and success metric — and AI fails most briefs by skipping the insight in favor of generic audience description. The fix is to prompt for the insight explicitly and to supply a past brief the team already shipped.

ROLE:
  You are a senior brand strategist writing internal creative briefs for the
  [brand] marketing team. You have read our last six briefs and understand
  our tone.

CONTEXT:
  - Campaign name: [campaign]
  - Budget: [budget]
  - Timeline: [timeline]
  - Target audience: [persona]
  - Past brief for reference (use as the format and voice template):
    ---
    [paste one real past brief]
    ---

TASK:
  Write a campaign brief for [campaign]. Cover: objective, audience,
  insight, deliverables, success metric. The insight section is the most
  important — it should be a one-sentence hypothesis about why this
  audience will care, not a restatement of the audience description.

FORMAT:
  Markdown. Five H2 sections, one per brief component. 300-500 words total.

ACCEPTANCE:
  - Insight is a testable claim, not a restatement of the persona.
  - Success metric is a number, not a sentiment.
  - Deliverables list is channel-by-channel, not a vague list.

For a deeper pattern library, see AI brief writing prompts.

Competitor analysis

Competitor analysis is where marketing teams overuse AI most — and where output quality varies most. A one-line "analyze our competitors" prompt produces a shallow feature list and a generic positioning summary. The prompt pattern that works is a three-stage chain: gather sources, build a feature matrix, draft a positioning statement — with an explicit human step between each stage to reject sources that were not verified.

The shape of a good competitor analysis prompt also has to account for the model's limits. Unless you are using a search-enabled or retrieval-grounded setup, the model cannot reliably produce current competitor details. The honest play is to feed it the sources yourself (URLs, extracted text, pricing screenshots) and constrain it to those inputs. For the full pattern with all three stages, see AI competitor analysis prompts. The related post on prompt patterns for competitor analysis covers cases where you are doing lighter-weight scans without a full source pack.

Campaign copy

Campaign copy splits into channel-specific patterns: search ads, social ads, landing pages, email sequences. Each channel has its own format, length limits, and voice conventions — and a generic "write some ad copy" prompt ignores all of them. The fix is channel-specific templates, each anchored with a past example that performed, and each forcing a testable claim rather than a generic benefit.

A practical rule: the channel determines the format, the audience determines the language, the insight determines the hook. A prompt that captures all three produces copy that a marketer can ship with light edits. A prompt that captures only the channel produces filler. For detailed channel-by-channel templates — ads, landing pages, email sequences — see AI campaign copy prompts. For the related strategy-layer prompts (content calendars, message maps), prompt patterns for content strategy covers the adjacent ground.

One subtle point: campaign copy is where few-shot examples earn their keep most. Three past ads that performed, pasted into the prompt, will steer output more than any adjective-heavy brief. The few-shot prompting glossary entry explains why; in practice, the rule is "pick varied, recent examples and put the strongest one last."

Sales

Sales works in one-to-one channels — discovery calls, proposals, forecast commentary — where the AI tax is that most AI-generated sales artifacts sound templated. The fix is encoding prospect context, objective, and next step into every prompt. The three sales archetypes below are where prompt patterns produce the biggest gains.

Discovery call preparation

Before a discovery call, a good rep has three things: a point of view about what this prospect probably cares about, five sharp questions, and a hypothesis about the next step. AI can dramatically shorten the prep time for all three — if you feed it the prospect context and ask for each piece separately.

ROLE:
  You are a senior enterprise sales rep preparing for a first discovery call
  with a new prospect. You have closed 40+ deals in [ICP segment] and know
  the common pain patterns.

CONTEXT:
  - Prospect: [company], [industry], [employee count]
  - Contact: [name], [title]
  - Source: [inbound from X / outbound intro from Y]
  - Known signals: [fundraising, hiring, recent launch, public comments, etc.]
  - Our product: [one-paragraph fit summary]

TASK:
  Produce a pre-call brief with three sections:
  1. Hypothesis — in one paragraph, what this prospect most likely cares
     about right now, given the signals.
  2. Discovery questions — five questions, each probing a specific pain
     area. No more than five. No yes/no questions.
  3. Next-step options — three ways the call could end, from weakest
     (send a follow-up email) to strongest (book a technical deep dive).

FORMAT:
  Markdown, three H2 sections, under 400 words total.

ACCEPTANCE:
  - Hypothesis is specific to this prospect, not a generic industry pain.
  - Every question opens, none closes.
  - Next-step options are sequenced by commitment level.

The pattern works because it forces separation between research, question design, and call-flow thinking — three activities that AI mashes together if you let it. For a fuller pattern library including call-summary prompts and follow-up draft prompts, see AI discovery call prompts. The companion post on prompt patterns for sales outreach covers the earlier-stage cold email and intro patterns.

Proposal writing

Proposals are where AI most often fails sales teams — the output reads like a brochure. The pattern that produces usable proposals separates the scoping from the writing: first prompt the model to produce a structured scope document (problem, goals, out-of-scope, SOW structure, pricing framing), then prompt it to draft the proposal section-by-section against that scope. Trying to do both in one prompt produces a generic proposal.

The acceptance criterion for a good proposal prompt is that every claim is traceable to something the prospect said or something you observed. "We will reduce churn by 30%" is not acceptable unless it is tied to a specific mechanism you and the buyer have discussed. AI left to itself invents numbers confidently; the prompt has to forbid it. See AI proposal writing prompts for the two-stage scope-then-write pattern and the guardrails that keep invented claims out.

Pipeline forecasting

Forecast commentary is the least-templated sales artifact and the one where AI helps most — turning a CRM export into a readable weekly narrative. The pattern has three stages: a data-input prompt that summarizes the pipeline state, a risk-scoring prompt that flags slipping deals, and a commentary-generation prompt that produces the narrative a sales leader actually reads.

The common failure is asking a single prompt to do all three; it produces a mushy summary. Separating them means each stage can be reviewed on its own. For the full three-stage pattern and the data-shape each stage expects, see AI pipeline forecasting prompts.

Engineering

Engineering's core act is structured reasoning about systems — and the function's AI tax is that most AI-generated engineering artifacts are confidently shallow. A model will happily produce an architecture review that lists pros and cons without grappling with trade-offs. The fix is prompts that force trade-offs, alternatives, and non-goals into view.

Architecture review

An architecture review is not "is this design good?" — it is "what assumptions does this make, what does it trade off, and what are two alternatives?" A prompt that encodes those three demands gets a review worth reading. A prompt that says "review this design" gets a bulleted list.

ROLE:
  You are a senior staff engineer reviewing a proposed system design. Your
  job is to stress-test assumptions and surface alternatives, not to
  approve or reject.

CONTEXT:
  Proposed design:
  ---
  [paste design doc]
  ---

  System constraints:
  - [scale: QPS, data volume, latency targets]
  - [non-functional: availability, cost, team size]
  - [existing stack the design has to fit]

TASK:
  Produce a review with four sections:
  1. Assumptions the design is making (explicit and implicit).
  2. Trade-offs the design is accepting (what is worse because of this choice).
  3. Two alternative designs that would satisfy the same constraints.
  4. Three concrete risks worth raising before implementation.

FORMAT:
  Markdown, four H2 sections. Use bullet points inside each section. Each
  alternative gets a three-sentence summary, not a full redesign.

ACCEPTANCE:
  - Every assumption is stated as a testable claim, not a vibe.
  - Every trade-off names what the design is worse at, not just what it
    is good at.
  - Alternatives are distinct approaches, not parameter tweaks of the same
    approach.
  - Risks are concrete enough to be acted on.

For detailed variations — reviews of diagrams, reviews of RFCs, reviews with forced Monte Carlo–style alternative generation — see AI architecture review prompts. If your team is also reviewing the code itself, prompt patterns for code review covers the PR-level patterns; and if you are running reviews through a coding agent rather than a chat prompt, see the complete guide to prompting AI coding agents — the scoping and acceptance discipline transfers directly.

Incident postmortem

Incident postmortems have a known shape — timeline, contributing factors, action items, lessons — and AI is good at scaffolding them from raw inputs (chat logs, incident bot output, dashboards). The pattern that produces a usable postmortem chains three prompts: timeline reconstruction, root-cause analysis (with a blameless frame baked in), and action-item extraction.

The blameless framing is a prompt-engineering detail that matters. Without it, the model drifts toward "person X should have done Y," which is culturally damaging and analytically weak. A sentence in the role layer — "you write blameless postmortems; name systems and processes, not individuals" — steers the output reliably. For the full chain and the input shapes each stage expects (Slack log format, incident bot output, etc.), see AI incident postmortem prompts.

Technical spec writing

Technical specs fail most often not because the writing is bad but because the spec skips one of four things: problem framing, approach, trade-offs, or non-goals. A prompt that forces all four into the output produces specs that reviewers can engage with. A prompt that asks for "a technical spec" produces a document that reads plausible and cannot be acted on.

The non-goals section is the most often omitted. A prompt that says "list three things this spec explicitly does not do" produces the clearest specs — it is the section that forces the author to decide the scope, which is often the hardest part. See AI technical spec prompts for the four-section template and the acceptance criteria that keep non-goals from being skipped. For the adjacent problem of keeping spec docs in sync with the code they describe, prompt patterns for technical docs covers docs-as-code patterns.

Operations

Operations is the function where AI most reliably saves time — process decomposition, SOP writing, vendor scoring, automation mapping — and the one where errors have the lowest cost at draft time and the highest cost when deployed. The AI tax is missed edge cases and unclear step ownership. The three archetypes below are where prompt patterns produce the biggest consistency gains.

SOP writing

A good SOP has four things: a crisp purpose statement, step-by-step procedure with owners, exception handling, and a revision mechanism. The prompt pattern that produces usable SOPs forces each of these into separate sections and makes exception handling a first-class block rather than an afterthought.

ROLE:
  You are an operations manager writing a standard operating procedure (SOP)
  for the [team] team. You prioritize clarity, unambiguous ownership, and
  explicit exception paths over brevity.

CONTEXT:
  - Process name: [process]
  - Trigger: [what starts the process]
  - Outcome: [what finished looks like]
  - People involved: [roles]
  - Existing tools: [systems used]
  - Known exception cases: [any already-known ways it goes wrong]

TASK:
  Produce an SOP with five sections:
  1. Purpose — one paragraph, why this SOP exists.
  2. Scope — what is in and out of scope.
  3. Procedure — numbered steps, each with an owner and a typical duration.
  4. Exception handling — for each of the known exception cases, the branch
     step and who handles it.
  5. Revision mechanism — how this SOP gets updated when it drifts from
     reality.

FORMAT:
  Markdown, five H2 sections, procedure steps as a numbered list.
  400-700 words total.

ACCEPTANCE:
  - Every procedure step names an owner (role, not person).
  - Every exception case has an explicit branch step, not a note.
  - Revision mechanism is a concrete trigger, not "periodically."

For richer patterns — decomposition prompts for turning a fuzzy process into steps, step-ordering prompts, and exception-flag prompts — see AI SOP writing prompts.

Vendor evaluation

Vendor evaluation is where AI most benefits ops teams by enforcing structured scoring. The prompt pattern uses three stages: generate scoring criteria from the problem statement, produce a weighted comparison table across vendors, and surface risk flags (data handling, pricing cliffs, lock-in).

A subtle honesty point: the model will not have reliable pricing or feature details for every vendor. The honest play is to feed it the vendor's own documentation (or your sales-cycle notes) as context, and constrain it to those inputs. Any claim outside the supplied context gets flagged as unverified. See AI vendor evaluation prompts for the three-stage pattern and the guardrails that keep invented features out of the scoring table.

Process automation

Process automation prompts help ops teams identify which workflows are worth automating, score the automation opportunity, and design the prompt chain or tool chain that implements it. The pattern that produces usable output separates identification (list candidate workflows), scoring (rank by volume × complexity × error-rate), and design (sketch the automation).

The common failure is jumping straight to the design before the scoring. Prompts that ask "design an automation for X" without first ranking X against Y and Z produce plausible-looking automations for the wrong workflows. For the full three-stage pattern and the scoring rubric, see AI process automation prompts. For the adjacent planning patterns, prompt patterns for project planning covers how the automation work slots into quarterly planning.

Cross-Function Patterns

Under the function-specific patterns sits a shared scaffold. Every good prompt across marketing, sales, engineering, and ops has the same five parts, and several well-known techniques — few-shot examples, critic-then-revise, spec-then-execute — apply across all four functions. Here are the cross-cutting patterns worth naming.

Role + context + task + format + acceptance. This five-part envelope is the spine of every function-specific prompt in this guide. Role tells the model who it is acting as. Context supplies the inputs. Task states the goal. Format defines the output shape. Acceptance defines done. Skip any of them and the model fills the gap with whatever it has seen most. The role prompting glossary entry covers the role layer in more depth; the system prompt glossary entry covers where in a multi-turn workflow the scaffold lives.

# The cross-function scaffold every good business prompt carries

ROLE:
  [Who the model is acting as — job title, seniority, relevant expertise.
   One sentence.]

CONTEXT:
  - [Inputs the model needs: documents, past artifacts, constraints.]
  - [Anchor examples: one or two past artifacts the team approved.]

TASK:
  [The specific artifact to produce. One paragraph, no ambiguity about
   what "done" looks like from the outside.]

FORMAT:
  [Markdown structure, section headings, length target, any schema.]

ACCEPTANCE:
  - [Verifiable criterion 1 — a reviewer can check yes/no.]
  - [Verifiable criterion 2.]
  - [Verifiable criterion 3.]

Fill this scaffold once per artifact your team produces at least monthly. The filled version becomes the shared prompt; the empty scaffold stays as the training doc for new teammates.

Few-shot examples for format fidelity. The single cheapest upgrade to any business prompt is pasting one or two past artifacts the team already approved. A model shown what "our brief" or "our postmortem" looks like produces output that needs less editing than a model asked to infer the shape from adjectives. The rule of thumb is three varied examples, strongest last, and refresh them when the team's standard shifts. See the few-shot prompting glossary entry for the technique.

Critic-then-revise (self-refine). A two-step prompt where the model first drafts, then critiques its own draft against a list of criteria, then revises. For business artifacts — briefs, proposals, SOPs — self-refine catches internal contradictions and missing sections that a single-pass draft misses. The cost is tokens; the payoff is fewer rewrites.

Spec-then-execute. Before asking the model to produce the artifact, ask it to produce a spec for the artifact (sections, rough length, key claims), review the spec, then run a second prompt that executes against the approved spec. This is the two-stage pattern that underlies most of the sales and engineering patterns above. It is also the same discipline at work in the complete guide to prompting AI coding agents — define done, then execute.

Context assembly (context engineering). The bundle the model sees — system prompt, past artifacts, retrieved docs, tool outputs — matters more than the phrasing of any single instruction. For a sales team running prompts over CRM exports, an ops team running prompts over vendor docs, or an engineering team running prompts over codebase snippets, assembling the right context is the work. See context engineering: the 2026 replacement for prompt engineering for the full discipline, and the context engineering glossary entry for the short form.

A rough heuristic: if your team is producing artifacts with more than two paragraphs of domain-specific input (a pitch to a real prospect, a review of a real design, a vendor comparison against real docs), context assembly matters more than clever phrasing. If the artifact is generic enough to be cold-drafted (a social post, a meeting invite), phrasing does more of the work. Most team artifacts sit on the context-heavy side of that line.

For an example of cross-function prompting that combines several of these patterns, see prompt patterns for email writing — the email-writing archetype appears in every function and is a good place to see role, context, few-shot, and acceptance all operating together.

Rolling Out Prompt Standards

A library that nobody uses is worse than no library. The rollout problem is a people problem more than a prompting problem. Here is a path that works for most teams.

Start with one artifact per function, not twenty. Pick the highest-volume recurring artifact in each function — the brief for marketing, the discovery prep for sales, the architecture review for engineering, the SOP for operations — and build one high-quality prompt for each. Four solid prompts beat twenty shallow ones. Teammates copy from what they see working.

Anchor every shared prompt with a real past artifact. A template is easier to reject than to adopt. A template that opens with "here is the exact brief we shipped for Q1 launch" feels like a continuation of the team's existing work, not a replacement of it. The AI prompts for engineers post shows this pattern in action for engineering artifacts.

Assign owners, not committees. Each function's prompt library needs one person who owns it — who approves changes, who runs the quarterly refresh, who fields "this prompt broke" complaints. Shared ownership decays into no ownership. The owner does not have to be the team lead; it has to be someone who uses the prompts daily.

Train by running, not by explaining. A one-hour session where each person runs a real task through a shared template beats a three-hour workshop on prompt engineering theory. People learn by watching their own work get better. Every team that has made prompt patterns stick did it this way — not by reading about prompting, but by prompting against real tasks.

Store where people already work. The prompt library should live wherever the team already looks for standards — a docs site, a Notion page, a prompt manager, a shared repo. Introducing a new tool just to store prompts creates a second adoption problem. Name each prompt by the artifact it produces ("creative brief v2," "incident postmortem v3"), not by the technique it uses.

Revisit on a cadence. A quarterly refresh — review each shared prompt, update the anchored example, retire what is no longer used — keeps the library matched to how the team works now. Between refreshes, fix anything that produces output someone had to heavily rewrite. This is maintenance, not governance; the lightweight version is a Slack channel where people post "this prompt stopped working" and the owner updates it.

On the tooling side, teams often ask whether a prompt manager or template builder is worth introducing. The honest answer is: it depends on scale. A ten-person team can live in a shared doc. A fifty-person team with prompts spread across four functions benefits from a purpose-built library — and for engineering teams, the same discipline that governs a prompt library governs the system prompts and spec files that feed coding agents. The complete guide to prompting AI coding agents covers that slot in detail.

At SurePrompts we build a template builder that encodes exactly this pattern — role, context, task, format, acceptance — with variable slots for the inputs each artifact needs. That is one concrete implementation of the shared-scaffold idea; others look like internal Notion libraries, GitHub repos of prompt files, or purpose-built prompt-management products. The important thing is that the team settles on one place to keep the prompts and one person to own each function's section. The specific tool matters less than the commitment to a library at all.

Further reading, by function

Each function's deep-dive cluster builds on the patterns outlined above. Use these as the next layer of detail when you are templating the corresponding artifact for your team.

Marketing

• AI brief writing prompts — the full brief template, variations for product, brand, and campaign briefs, and acceptance criteria for the insight layer.
• AI competitor analysis prompts — the three-stage source-gather, feature-matrix, positioning pattern.
• AI campaign copy prompts — channel-by-channel templates for search, social, email, and landing pages.

Sales

• AI discovery call prompts — pre-call brief, live-call notes, and post-call follow-up patterns.
• AI proposal writing prompts — the two-stage scope-then-write pattern with anti-invention guardrails.
• AI pipeline forecasting prompts — data-input, risk-scoring, and narrative-commentary prompts.

Engineering

• AI architecture review prompts — review templates for diagrams, RFCs, and design docs with forced alternatives.
• AI incident postmortem prompts — the three-stage timeline, root-cause, action-items chain with blameless framing baked in.
• AI technical spec prompts — the four-section template and the acceptance criteria that keep non-goals from being skipped.

Operations

• AI SOP writing prompts — decomposition, ordering, and exception-handling patterns.
• AI vendor evaluation prompts — scoring-criteria generation, weighted comparison, and risk-flag patterns.
• AI process automation prompts — workflow identification, opportunity scoring, and prompt-chain design.

FAQ

Do teams really need function-specific prompts, or does one good prompt work?

One general-purpose prompt produces general-purpose output. Function-specific prompts bake in the shape of the work — a creative brief has an audience, insight, and deliverables; an incident postmortem has a timeline, contributing factors, and action items. The moment you skip that structure, the model fills it with generic filler. Shared, function-specific scaffolds are faster to write from and easier for a teammate to pick up.

How do I get non-technical teammates to use AI consistently?

Give them filled-in templates, not instructions. A marketing manager does not need a prompt engineering lesson; they need a brief template where the first three fields are obvious and the fourth is a model-generated draft. The fastest path to adoption is a shared library of prompts shaped like the work, not a training deck on prompting theory.

Should each function have its own prompt library?

Yes — and they should share a common scaffold. Marketing, sales, engineering, and ops each have recurring artifacts with their own shape, so the specific prompts differ. But the envelope — role, context, task, format, acceptance — is universal. A shared scaffold with function-specific content is the sweet spot: consistent structure, relevant details.

What's the ROI of a shared prompt library?

The honest answer is: it depends on how much of the team's work repeats. If five people write one-pager briefs every week, a shared brief prompt saves real time and levels quality. If the work is genuinely different every day, a library helps less. The test is whether at least two people on the team do the same kind of artifact more than once a month — if yes, it is worth templating.

How do I write a prompt that produces output my boss will accept?

Start with an example of output your boss already accepted and feed it to the model as a few-shot example. Pair it with a clear statement of audience, tone, and what done looks like. The model is not a mind reader — it has to see the target. One real artifact at the top of the prompt is worth a paragraph of adjectives.

Do prompt patterns work across Claude, ChatGPT, and Gemini?

Mostly yes, with small mechanical adjustments. A prompt with role, context, task, format, and acceptance criteria works in all three — what differs is how you pass attachments, whether you use a system message, and how strict the JSON mode is. Start with the shared pattern, then tune model-specific features where they help.

How often should we update our prompts?

Revisit shared prompts on a predictable cadence — quarterly is a reasonable default — plus any time a model family changes significantly. In between, update any prompt that produces work someone had to heavily rewrite. The goal is not to chase every model release; it is to keep the library matched to how the team actually works now.

What prompts give the worst AI output?

Three shapes reliably produce the worst output. First, a one-line ask with no audience or format — "write our brand story." Second, a prompt that contradicts itself on tone or constraints — "professional but funny, short but comprehensive." Third, a prompt that omits acceptance criteria — the model writes whatever feels plausible, and you discover the gap only at review.

Should marketing and engineering share any prompts?

The scaffold, yes. The content, usually not. Both functions benefit from role + context + task + format + acceptance as the envelope. But a marketing brief and an engineering spec are different artifacts — trying to serve both with one prompt ends up serving neither. Share the envelope, diverge on the filling.

How do I train a team on prompting?

Skip the theory lecture. Run a one-hour session where each person brings a real task they did last week and prompts their way through it with a shared template. They learn by watching their own work get better, not by memorizing techniques. Follow up with a shared library they can copy from, and keep the training loop continuous rather than one-off.

Before Your Team Starts Using AI for Real Work

A short checklist a team lead can print and hand out:

• One shared scaffold, posted where people already work. Role, context, task, format, acceptance — the five-part envelope every prompt carries. Put it on the docs site, not in a new tool.
• One high-volume artifact per function, templated first. Brief, discovery prep, architecture review, SOP. Four solid prompts beat twenty shallow ones.
• Every shared prompt anchored with one real past artifact. Templates feel adoptable when they read as continuations of work the team already ships.
• One named owner per function's prompt library. Not a committee. Someone who uses the prompts daily and owns the quarterly refresh.
• Acceptance criteria in every prompt, written as something a reviewer can check. "Good" is not checkable; "insight is a testable claim, not a restatement of the persona" is.
• A quarterly refresh on the calendar. Between refreshes, fix anything that produced work someone had to heavily rewrite.
• Training runs on real tasks, not on theory. One hour, real work, shared template. People learn by watching their own output get better.

Generic prompts produce generic work. Function-specific patterns, built on a shared scaffold and maintained by named owners, are what turn a team's AI use from "someone has a tip" into a library that compounds over time. The specific prompts above are starting points; the discipline — map the work, bake the shape in, maintain it — is what makes them stick.