# Prompt Engineering Basics for Business Users: Role, Context and Format

> Learn the building blocks of a good business prompt, including goal, role, context, source material, examples and output format, with templates for ChatGPT, Claude and Copilot.

Source: https://www.epifive.com/blog/prompt-engineering-basics-business-users · Published 2026-10-25 · EpiFive

## Key takeaways

- A prompt works best when it states a clear goal, the context behind it, the source material to use and the format you expect.
- Separating instructions from reference material, using headings or XML-style tags, helps models avoid mixing them up.
- Three to five varied examples are one of the most reliable ways to control format, tone and structure.
- Prompts are drafts, so refine them with follow-up messages and always review the output before using it.

A good business prompt states what you want done, why, what information to use and what the result should look like. Models respond far better to that than to a one-line request, and you do not need technical skill to write one. This article breaks the prompt into building blocks, shows how each is described in vendor documentation, and gives templates you can adapt for ChatGPT, Claude and Microsoft Copilot.

## Who this is for and what you will have

This is for managers, analysts, administrators and support staff who use AI assistants for drafting, summarising, analysis and planning, and who want predictable results. By the end you will have a prompt template with five parts, a before-and-after example, a method for using examples and structured output, and a short list of fixes for common failures.

## The building blocks of a prompt

Different vendors use different names, but the guidance overlaps. Microsoft's guidance for Copilot says a strong prompt can include up to four parts: a goal, context, source and expectations. It adds that the goal is the only required part: "all that's required is a clear goal". Anthropic's guidance for Claude covers being clear and direct, adding context, using examples, structuring with XML tags and giving the model a role. OpenAI's guidance describes developer messages that often contain, in order, identity, instructions, examples and context.

Combined into one working structure:

| Part | Purpose | Example |
| --- | --- | --- |
| Goal | The task, stated plainly | "Draft a reply declining the quote" |
| Role | The perspective the model should take | "You are a procurement analyst" |
| Context | Why you need it and who is involved | "The supplier raised prices 12% and we have two alternatives" |
| Source | The information to use | An attached contract, a pasted email thread |
| Format | What the output should look like | "Three short paragraphs, polite and firm, under 150 words" |

You do not need all five every time. Add parts when the first answer is too generic.

## Role: set the perspective, not the facts

Anthropic lists giving Claude a role among its general techniques, and OpenAI's guidance describes an identity or role section at the start of a developer message. A role steers vocabulary, depth and tone: "You are an HR policy advisor writing for non-specialist managers" produces different text from "You are a lawyer".

Keep roles realistic and tied to the audience. A role does not make the model more accurate on facts it does not have, so do not treat it as a substitute for source material. If accuracy matters, supply the documents and ask the model to rely on them. For more on verification, see [AI hallucinations at work: a verification checklist](https://www.epifive.com/blog/ai-hallucinations-verification-checklist-business).

## Context: say why and for whom

Anthropic recommends adding context to improve performance, because a model that knows the purpose can make better choices about what to include. Useful context answers four questions:

1. What is the situation?
2. Who will read the result?
3. What constraints apply, such as length, tone, budget, deadlines or policy?
4. What does a good result enable?

Compare these two prompts.

```text
Write an email about the delayed delivery.
```

```text
Goal: Write an email to a customer about a delayed delivery.
Role: You are a customer service lead.
Context: The order was due on 3 November and will now arrive between 10 and 12 November because of a warehouse stock issue. The customer has ordered from us before and is not yet upset. We want to keep the order, not offer a refund unless asked.
Format: Plain text, under 120 words, apologetic but not grovelling, with the new delivery window in the first sentence.
```

The second prompt gives the model the dates, the relationship, the policy and the format. It will still need a human read, but it is far closer to usable.

## Source: attach the information instead of describing it

If the answer depends on a specific document, provide the document. Microsoft's Copilot guidance lists "source" as its own prompt part, for example an attached file, a web page, or work emails, chats and files, depending on your account. OpenAI's guidance likewise notes that you can add relevant data to the prompt, as long as you stay within the model's context window.

Two habits help:

- **Mark where the source begins and ends.** OpenAI notes that Markdown headers and XML tags help separate sections of a prompt and mark where reference data starts and ends. Anthropic similarly recommends wrapping each type of content in its own tag, such as `<instructions>`, `<context>` and `<input>`, when a prompt mixes instructions, context, examples and variable inputs.
- **Put long documents before the question.** Anthropic advises placing long-form documents and inputs near the top of the prompt, above the query, instructions and examples, and wrapping multiple documents in `<document>` tags with source metadata.

An example with tags:

```text
<instructions>
Summarise the meeting notes for a manager who was not there.
List decisions, owners and deadlines. Say "not stated" if a field is missing.
</instructions>

<notes>
{{PASTE MEETING NOTES}}
</notes>
```

Be careful about what you paste. Use only tools your organisation approves for the type of data involved, and remove personal or confidential details that the task does not need.

## Format: describe the output you want

Models fill in a format when you name it. Ask for the structure you will actually use:

- A table with named columns, such as "Risk, Likelihood, Owner, Next step".
- A numbered list of at most five items.
- A short email with a subject line.
- A fixed template you supply.

Anthropic's guidance on controlling response format recommends telling the model what to do rather than only what to avoid, and notes that XML format indicators can mark the structure of the output. A positive instruction such as "write in plain paragraphs with no bullet points" is usually clearer than "do not use bullet points".

When you need the same layout every time, give a template:

```text
Return the answer in exactly this layout:

Summary: <one sentence>
Key risks: <up to three bullets>
Recommended action: <one sentence>
```

## Examples: the most reliable way to control style

Anthropic describes examples as "one of the most reliable ways to steer Claude's output format, tone, and structure", and recommends including 3 to 5 examples for best results. OpenAI's guidance on few-shot learning makes the same point: a few varied input and output examples can steer a model without fine-tuning.

Practical rules:

1. Use realistic examples from your own work, with sensitive details removed.
2. Make them varied, so the model learns the pattern rather than copying one case.
3. Label them clearly, for example `<example>` tags, and say they illustrate the style.
4. Include at least one awkward case, such as a missing field or an unusually short input.

```text
Classify each support ticket as Billing, Technical or Other. Reply with the label only.

<example>
Ticket: "I was charged twice this month."
Label: Billing
</example>
<example>
Ticket: "The app crashes when I upload a PDF."
Label: Technical
</example>
<example>
Ticket: "Do you have an office in Pune?"
Label: Other
</example>

Ticket: "{{NEW TICKET TEXT}}"
Label:
```

## Iterate: treat the first answer as a draft

Microsoft's Copilot guidance says to expect a back-and-forth conversation and to refine with follow-up prompts. Useful follow-ups are specific:

- "Shorten to 100 words and keep the delivery dates."
- "Make the tone more formal."
- "Remove anything that is not in the attached notes."
- "List the assumptions you made."

Keep a library of prompts that worked, with the date and the tool they were tested on. OpenAI's guidance advises pinning production applications to specific model snapshots, keeping prompts in application code and testing changes with evaluations, which is the same discipline applied at team scale: when a prompt matters, test it on a handful of real inputs before sharing it.

## Common problems and fixes

| Problem | Likely cause | Fix |
| --- | --- | --- |
| Generic, bland answer | Missing context or audience | Add who it is for and the situation |
| Wrong length or layout | Format not specified | State length, structure or give a template |
| Invented details | No source supplied | Attach the document and tell the model to use only it |
| Inconsistent output across runs | No examples, loose instructions | Add 3 to 5 examples and a fixed format |
| Instructions ignored | Long, tangled prompt | Separate instructions, context and input with tags or headings |
| Tone off | No audience or role | Name the reader and the desired tone |

Different models respond differently. OpenAI notes that reasoning models handle high-level goals well while faster GPT models need more explicit instructions, so the same prompt may need adjusting when you switch tools.

## Checklist

- State the goal in one clear sentence.
- Add a role if tone or perspective matters.
- Explain the context, the reader and the constraints.
- Attach the source and mark it clearly.
- Describe the output format, or supply a template.
- Include 3 to 5 varied examples for repeatable tasks.
- Refine with follow-up prompts and review the final output yourself.
- Check anything factual against a primary source.

## References

- Anthropic, Prompt engineering overview: https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/overview
- Anthropic, Prompting best practices: https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/claude-prompting-best-practices
- OpenAI, Prompt engineering guide: https://developers.openai.com/api/docs/guides/prompt-engineering
- Microsoft Support, Learn about Copilot prompts: https://support.microsoft.com/en-us/topic/learn-about-copilot-prompts-f6c3b467-f07c-4db1-ae54-ffac96184dd5

## Frequently asked questions

### What are the parts of a good prompt?

Microsoft describes four parts for Copilot prompts, which are goal, context, source and expectations, with the goal being the only required part. Claude and OpenAI guidance adds roles, examples and clear separation of instructions from reference material.

### Do I need to give the AI a role?

A role is optional but often useful. Anthropic lists role prompting as a technique, and OpenAI describes an "identity" section in developer messages. A role sets perspective and tone, but it does not replace clear instructions and source material.

### How many examples should I include in a prompt?

Anthropic recommends including 3 to 5 examples for best results when you want a consistent format, tone or structure. Make the examples varied and relevant, and tell the model they are examples rather than content to copy.

### Why does the same prompt give different answers each time?

Language models produce text probabilistically, and Microsoft notes that running the same prompt again may produce different wording. Specific instructions, a defined output format and examples make results more consistent, but you should still review each output.

