AI literacy - Prompt engineering in practice: 7 patterns for your team
In the previous chapter, we saw that the AI Act requires you to document what training your team has received on AI. Now we arrive at the practical question: what exactly do I teach them?
It's not about everyone learning to adjust model temperatures or understanding backpropagation. It's about people who use AI in their daily work knowing how to communicate with it to get decent results without sounding like they're chatting with a drunk chatbot.
That's operational prompt engineering. It's not a specialism. It's a skill anyone on your team can pick up in a couple of sessions if you focus on what matters.
The seven patterns below are exactly what I teach in the training sessions I run with teams. Each one has a before and after using real cases. You'll see it's not hard. It's a question of habit.
The three foundations behind everything
Before diving into patterns, you need to understand what makes a prompt work or fail. Three things.
Context. The model is a system without long-term memory. If you want it to understand what you're asking, you need to tell it who it is in this conversation, what relevant information exists, and what situation we're in. A prompt without context is like asking someone to solve a problem without giving them the data.
Clear expectation. The model is literal. If you ask it to "improve this text", it could improve the grammar, tone, structure or length. It doesn't know which of those matters to you. If you ask it to "improve this text to be shorter whilst keeping the concrete facts", it knows what you're after.
Verification. The model hallucinates. It generates coherent text about things it doesn't know. If you ask it to generate a figure, it might sound real when it's made up. If you ask it to summarise a document, it can summarise paragraphs that aren't in the document. Anyone using AI has to validate the output.
Now, the patterns.
Pattern 1: Role
Telling the model what role to adopt changes how it structures its responses dramatically.
Before:
Write an email to a customer who's torn between our software and our main competitor's.
Expected response: yes, but generic. It'll sound corporate, lengthy, with all the features listed.
After:
You're the senior sales person at this company. You've just had a video call with this customer and they've told you they're torn between our product and [competitor]. They're particularly worried about implementation time. Write a follow-up email that's informal but professional and:
1. Acknowledges their concern.
2. Clarifies how long our implementation actually takes.
3. Invites them to a 20-minute demo with our technical team.
Maximum 150 words. Tone of someone who understands the business, not a generic salesperson.
Result: the email comes out more natural, less "according to our studies", more "I get it, here's the reality".
Why it works: when you assign a role, the model uses language patterns it's seen from that type of person. A sales person talks differently to a technical specialist. The role gives you consistency without needing to describe every detail.
Real case: a marketing team in Madrid using this pattern for CTA suggestions gets more direct responses than before they specified "you're a copywriter who knows conversions".
Pattern 2: Output format
Saying explicitly how you want the response back saves you reformatting afterwards.
Before:
Analyse this email from an unhappy customer and give me the key points.
Expected response: paragraphs, maybe numbered, possibly lengthy. You have to read everything to pull out what matters.
After:
Analyse this email from an unhappy customer.
Return your analysis in this exact format:
Main problem (one sentence):
Reported impact (what they say broke or doesn't work):
Customer tone (angry, disappointed, neutral):
Urgency (high/medium/low, and why):
Be very concise. Maximum one line per section.
Result: a structure you can copy straight into your CRM, no intermediate steps.
Why it works: the model understands explicit formats better than vague instructions. If you say "give me a summary", each model and each time gives you something different. If you say "give me three points separated by hyphens, each one under its own line", the result is predictable.
Real case: a support team in Valencia that classifies tickets with AI uses this pattern. They went from reviewing each response to extract information to copying straight across.
Pattern 3: Few-shot, concrete examples
Showing examples of what "good" looks like helps the model understand much better what you expect.
Before:
Write a short LinkedIn message to promote our webinar next Tuesday. Make it compelling.
Expected response: something that probably works, but it's not what you wanted. "Compelling" is subjective.
After:
Write a short LinkedIn message to promote our webinar next Tuesday.
Here are two examples of the tone and structure we want:
EXAMPLE 1 (works well):
"In 3 days: ChatGPT hallucinations. How they happen, how to spot them, what to do about it. Tuesday 10:30, 25 minutes no filler. Book your place: [link]"
EXAMPLE 2 (also works):
"If someone on your team has seen ChatGPT make up data and didn't know how to prevent it: Tuesday we'll explain it. Webinar 25 min, live, no recording afterwards. 10:30. [link]"
Now write one similar for OUR webinar on [topic], but with your own voice. Maximum two lines.
Result: the model understands you want short sentences, concrete actions, real numbers, not floating adjectives.
Why it works: concrete examples work better than abstract instructions. The model sees the pattern of what you did well and replicates it.
Real case: a marketing team in Madrid that generates blog titles uses this pattern. They went from 15 generated titles where they could save 2 or 3 to 13 out of 15 being publishable.
Pattern 4: Delimiters to separate context from task
Using visual markers (quotes, lines, XML tags, code blocks) so the model understands what's "context" and what's "the thing I need done".
Before:
I want you to review this paragraph from a sales proposal we wrote for a logistics client. The paragraph covers our technical capabilities. Improve it so it sounds less like engineers and more like people who understand logistics.
Paragraph:
"Our system uses route optimisation algorithms based on machine learning to guarantee maximum efficiency in assigning cargo to vehicles, minimising fuel cost and maximising space utilisation."
Result: it works, but the model could lose sight of what's "the context" and what's "what it needs to improve".
After:
CONTEXT:
You're reviewing a sales proposal for a logistics company. The client cares deeply that their suppliers understand the industry, not just the technology.
PARAGRAPH TO IMPROVE:
---
Our system uses route optimisation algorithms based on machine learning to guarantee maximum efficiency in assigning cargo to vehicles, minimising fuel cost and maximising space utilisation.
---
INSTRUCTION:
Rewrite this paragraph so it sounds like whoever's writing it understands the pressure of costs and timelines in logistics, not just technology. Keep the real benefits (less fuel, better loading), but explain them without jargon.
Result: the model clearly understands what information is background and what needs transforming.
Why it works: the model is literal in how it processes text. If you use delimiters (visual lines, tags, blocks), it understands boundaries better. It's like underlining what's important in an exam.
Real case: a sales proposal team in Barcelona using this pattern cuts their review rounds to one.
Pattern 5: Chain-of-thought reasoning step by step
Asking the model to "think aloud" before answering produces more reliable results.
Before:
What's the best strategy for our sales team to boost pipeline in Q4?
Expected response: something that sounds good, but it's generic. It could be made up. You don't see how it thought it through.
After:
What's the best strategy for our sales team to boost pipeline in Q4?
Important: before you answer, think step by step.
1. What are the three factors that constrain pipeline in Q4 in [your sector] companies?
2. Which of those three can our team directly control?
3. Of that factor, what's the leverage point (the small change that creates big impact)?
4. Now: what's the concrete strategy in three steps?
Answer by thinking aloud. Then give the final strategy in one sentence.
Result: you don't just see the answer, you see how it got there. You can validate each step. If one's wrong, you spot it.
Why it works: the model tends to "rush" toward the answer without validating intermediate steps. When you ask it to think aloud, it can catch its own errors (or at least, you see where they are).
Real case: a managing director at a marketing agency using this pattern for strategic decisions says they get better responses than when they ask "what should we do".
Pattern 6: Cross-check verification
Asking the model to review its own answer before handing it over.
Before:
Extract the main SEO keywords from this blog article on AI in SMEs.
[2,500-word article]
Expected response: a list of keywords. Some correct, some not in the text.
After:
Extract the main SEO keywords from this blog article on AI in SMEs.
[2,500-word article]
IMPORTANT: Once you've extracted the keywords, verify each one. For each keyword, answer:
- Does this word or phrase appear explicitly in the article? (yes/no)
- Is it central or mentioned in passing? (central/passing)
- Drop any keywords that aren't central.
Return only the keywords that passed this check. Next to each, in brackets, note how many times it appears.
Result: the keyword list is more reliable because the model validated each one against the actual text.
Why it works: the model tends to hallucinate. If you ask it to verify its own response, you reduce hallucinations because it has to "find proof" in the original content.
Real case: an SEO team in Madrid using this pattern found their keyword lists dropped 30% in quantity but rose 90% in accuracy.
Pattern 7: Structured iteration
Don't ask for a perfect answer on the first go. Ask for a version, then specific improvements.
Before:
Write a press release about our new Salesforce integration.
Expected response: a press release. Probably generic. If you don't like it, you ask to "make it tighter" or "it sounds corporate", and that's vague.
After:
Write a first draft of a press release about our new Salesforce integration. I'm not after perfection in this first step, I want you to capture three key points:
1. Who benefits (sales teams and CRM people who wanted automation).
2. What changes (they can now sync data without exporting manually).
3. When it's available (15 October).
Maximum 200 words. Professional but direct tone, not "we're delighted to announce".
Result: first draft that captures the essence.
Then:
This draft is good. Now give me a second version where:
- You replace "we're delighted to announce" with something more real.
- You add a number: how much time do users save per week?
- Drop the sentence that starts with "In the context of digital transformation".
Result: the model knows exactly what to change because you gave concrete instructions, not vague feedback.
Why it works: structured iteration is more efficient than asking for perfection up front. The model understands specific feedback. If you say "improve it", it doesn't know what to improve. If you say "change X to Y and drop Z", it does it well.
Real case: a copywriting team in Barcelona that used to go through three review rounds with the model now does it in two, and the quality is better.
Common mistakes when teaching this to your team
When you roll out these patterns in your company, there are common pitfalls.
Mistake 1: Assuming everyone gets it on the first go.
Some team members will say "this is too much, why write a role if I can just write directly?". Give them a before and after example from their own work. That usually settles it.
Mistake 2: Copying your prompts exactly.
A sales person copies the exact prompt you wrote for the email generator. But then they use it for a different context (an email to a lead who isn't yet a customer, not a follow-up after a demo). The result sounds out of place.
Solution: teach them the structure, not the exact recipe. The pattern is "role + specific context". They need to adapt the context to their situation.
Mistake 3: Never validating.
You ask the team to use chain-of-thought patterns. They do. Then they copy the response without checking whether the model hallucinates any numbers or facts.
Solution: include a checklist in the training: "Before copying a response where the model gives a number, name or figure, verify it's true."
Mistake 4: Confusing "improved" with "correct".
Someone uses the cross-check pattern. The model says "here are the keywords, verified". The employee believes it because it says "verified".
Solution: model validation isn't the same as human validation. The cross-check pattern reduces errors, it doesn't eliminate them.
Mistake 5: Using these patterns for things that don't need AI.
"I'm going to ask for structured prompt engineering so it writes me an email to a customer I know well and I write similar emails every week."
If you can write it in two minutes without thinking, you probably don't need AI. The patterns are for situations where the model actually saves you time or gets you unstuck.
Next steps
This chapter covers prompt engineering in practice. The patterns here don't require anyone to be technical. They work in ChatGPT, Gemini, Claude or any LLM.
The next chapter covers shadow AI and auditing. That's this: what tools are being used in your company without your formal sign-off, how to spot them, and how to make an internal AI policy actually work without strangling innovation.
If you need someone on your team to get training on these patterns and how to apply them to their specific role, you can book an hour session where we look at how they actually work, where the bottleneck is, and how the patterns solve it.