Full study guide

Create effective prompts for business tasks

A good prompt gives Claude the context, task, constraints and examples a capable new colleague would need.

Key ideas

Context first

Say who the output is for, why it is needed and what Claude should know about the situation. Generic output almost always means missing context, not a weak model.

A specific task

Use a clear verb and name the deliverable: “Draft a 150-word email inviting existing customers to the webinar” beats “Write something about the webinar”.

Constraints that matter

Length, tone, format, reading level, must-include facts and things to avoid. Concrete limits (“no more than 12 items”) work better than adjectives (“concise”).

Examples of good output

One or two approved examples transfer style and structure more reliably than any description of them.

Separate instructions from material

When you paste documents, label them clearly (headings or tags such as <policy>…</policy>) and state the task separately, so Claude doesn't mistake content for instructions.

Say what to do when information is missing

“If the documents don't cover it, say so” prevents confident guessing.

Worked example

A marketing manager needs a product launch email.

Why: The strong version adds audience, goal, facts, length, tone and a model to imitate. “Exciting” gives Claude nothing to work with.

Common traps

• Writing instructions in capitals or saying “this is very important” instead of adding information.
• Telling Claude to “be an expert” and expecting that alone to fix missing facts.
• Asking for things Claude can't guarantee, such as trademark availability or today's prices without web search.

Apply task decomposition techniques

Break large or multi-part work into reviewable steps, and agree the structure before the bulk work starts.

Key ideas

Outline, then sections, then a consistency pass

For long documents, agree an outline mapped to the requirements, draft section by section with the relevant inputs, then ask Claude to check consistency across sections.

Agree the scheme before bulk work

For analysis of many records (returns, survey comments), have Claude propose categories from a sample, agree them, then classify everything against the agreed scheme.

Chain prompts

Feed the output of one step into the next (extract facts → identify gaps → list risks). Each step is easier to check than one giant answer.

Extract, then answer

For questions about a long document, ask Claude to pull out the relevant passages first and answer only from them.

Summarise hierarchically

When there is too much material for one pass, summarise each piece separately, then combine the summaries.

Worked example

A bid manager must respond to a 40-page RFP.

Why: Each step can be reviewed and corrected before it affects the next, and every requirement is traceable to a response.

Common traps

• Splitting work into random chunks in separate chats, which loses consistency.
• Asking for the final answer before agreeing the structure or criteria it depends on.
• Letting Claude decide things that should be human decisions (strategic priorities, which vendor wins) as a “step”.

Iterate prompts to improve output quality

Refine with specific, actionable feedback in the same conversation, and say what must not change.

Key ideas

Be specific

“Cut to about 150 words, use a conversational tone, keep the three key dates” works. “Make it better” doesn't.

Protect what's right

State what to keep exactly (figures, dates, regulatory wording) so a style edit doesn't break the facts.

Stay in the conversation

Iterating in context keeps everything Claude has already learned about the task. Starting over usually reproduces the same problems.

Change one thing when diagnosing

If you don't know why output is off, adjust one element at a time so you can see what helped.

Save the winner

Once a prompt works, keep it as a template or Project instruction so you don't rediscover it every week.

Worked example

An internal announcement draft is accurate but too long and formal.

Why: It names the change, the target, what to preserve and the desired ending.

Common traps

• Resending the identical prompt in a new chat and hoping for a different result.
• Switching model tiers before fixing an unclear prompt.
• Accepting a draft that is accurate but unusable for its audience.

Adapt prompting strategy to the task type

Analysis, research, drafting and brainstorming each need a different kind of prompt.

Key ideas

Analysis

Provide the data and the question it should answer, define the criteria, ask Claude to state assumptions, show workings and separate what the data shows from hypotheses.

Research

Ask for sources and citations, use web search or research for anything current, and plan to verify what comes back.

Drafting

Audience, purpose, tone, length and an example. Say what must be included and what to avoid.

Brainstorming

Ask for many varied options across categories without filtering. Shortlist with people, then ask Claude to develop the chosen few against stated criteria.

Extraction and classification

Give a fixed schema (columns, categories), one worked example, and tell Claude to leave a field blank and flag it rather than guess.

Complex reasoning

Ask Claude to think through the problem step by step, or use extended thinking where available, before giving a conclusion.

Worked example

A team wants campaign name ideas.

Why: Brainstorming needs breadth first. Asking for “the best” collapses the option space and makes the pick arbitrary.

Common traps

• Asking for one answer when the task is creative.
• Asking for “insights” without stating the business question.
• Letting Claude guess missing values during extraction.

Evaluate output for accuracy and completeness

Check the output against the source: facts, figures, scope, qualifiers and coverage.

Key ideas

Compare with the source's structure

Use the source's headings, tabs or section list as a checklist. If a report has 12 regions, the summary should account for 12.

Watch scope and qualifiers

“Carbon neutral at head office” is not “carbon neutral across all operations”. “After the first 12 months” is not “at any time”.

Recompute numbers

Re-do arithmetic and percentages. Check that totals reconcile with their parts and that percentage points aren't confused with percent change.

Completeness depends on purpose

A policy summary that lists benefits but not exclusions, or a judgment summary without the dissent your argument relies on, is incomplete for its reader.

Check every input was used

When several files or long inputs are involved, ask Claude to list what it covered and compare.

Worked example

Claude summarises a supplier contract.

Why: Fluent summaries can silently drop clauses or conditions that change their meaning.

Common traps

• Treating detail or confident tone as evidence of accuracy.
• Accepting “rounding” that changes a figure materially.
• Assuming Claude chose the “most important” parts when it simply missed some.

Identify hallucinations, inconsistencies and bias

Know the red flags for invented content, internal contradictions and biased framing.

Key ideas

Hallucination red flags

Precise statistics with vague or no sources; quotes attributed to named people; citations to papers, cases or reports; page or section references; claims about recent events; figures for data you never provided.

Internal inconsistency

The same figure stated two ways, “three options” introduced but four described, different dates for one event. Resolve these from the source, never by averaging or picking one.

Bias in content

Stereotypes about age, gender, ethnicity, income or location; coded hiring language (“young”, “rockstar”, “native speaker”); personas built on assumptions instead of data.

Bias in selection

Summaries that include only positive findings, or omit safeguarding concerns or missed targets, are misleading even if every sentence is true.

What to do

Verify or remove unsupported claims; rewrite biased language using job-related or evidence-based criteria; restore omitted material findings.

Worked example

A blog draft says “9 out of 10 dentists recommend our toothpaste.”

Why: An unsubstantiated statistic is still unsubstantiated after you soften it.

Common traps

• Keeping a dubious citation but making the attribution vaguer (“according to research”).
• Fixing a contradiction by averaging two numbers.
• Treating internal documents as exempt from bias checks.

Fact-check and validate outputs

Validation means independent checks: primary sources, recalculation and traceable evidence.

Key ideas

Go to primary sources

Official legislation databases, regulator sites, the original study, the publisher's catalogue, the competitor's own documentation.

Triangulate key inputs

Check important assumptions against independent data, such as last year's actuals, benchmarks or expert review.

Make outputs traceable

Ask Claude to quote the supporting passage, give the clause number or list the record IDs it counted, then spot-check those.

Know what isn't verification

Asking “are you sure?”, Claude's stated confidence, two chats agreeing, or regenerating until answers match. None of these test the facts.

Current facts need live sources

Prices, rates, regulations and recent events may have changed after Claude's knowledge cutoff. Use web search or official sites.

Scale effort to stakes

Light checks for internal brainstorming; rigorous checks for anything public, contractual, financial or safety-related.

Worked example

Claude reports that 35% of 200 support tickets concern login problems.

Why: A traceable count can be checked quickly; a self-assessment can't.

Common traps

• Treating self-review as independent verification (it's a useful first pass, no more).
• Accepting a citation because the source is reputable, without finding the claim in it.
• Using a figure because it “matches what we remember”.

Decide when human review is required

The higher the stakes and the harder to reverse, the more qualified and accountable the review must be.

Key ideas

Always needs qualified review

Public statements, legal or regulatory content, financial commitments or promised outcomes, health and safety guidance, decisions or records about individuals, anything sent to courts, regulators or funders.

Light review is fine for

Internal brainstorms, agendas, reformatting, first-pass ideas that a person will develop.

Review must be real

Pasting drafts without reading them defeats the control. Spot checks, accountability and tracking error rates keep review meaningful.

Accountability stays human

The person and organisation that approve and send content are responsible for it, not Claude and not the vendor.

Drafts must not invent decisions

Watch for drafts that promise compensation, state an outcome not yet decided or make guarantees (“this will never happen again”).

Common traps

• Removing review because Claude's drafts are “usually right”.
• Asking Claude to review in place of the required approver.
• Sending first and getting approval afterwards.

Edit and adapt outputs for the intended audience

Reshape accurate output so the reader can use it, without losing what must stay exact.

Key ideas

Executives and boards

Lead with the decision needed, the impact and the risks on one page; move technical detail to an appendix.

Customers and the public

Plain language, the reader's reading level, short sentences, key dates and actions in a clear list.

Front-line and non-specialist staff

What changes for them and what to do, in their vocabulary.

Keep required content intact

Figures, dates, regulatory wording and must-include items survive every rewrite. Say so explicitly when you ask for an edit.

Accessibility

Consider translations, reading levels and formats for people who took part in research or receive the service.

Worked example

A technical outage analysis must go to the executive committee.

Why: Executives need to decide, not to audit the engineering.

Common traps

• Removing all numbers to make it “simple”.
• Adding jargon to make it look rigorous.
• Converting to bullets without changing what is emphasised.

Choose the right output format

Match the format to where the output will live: read once, kept and shared, or loaded into another system.

Key ideas

Inline reply

Quick answers read once: a definition, a single figure, a short explanation.

Artifact or document

Anything people will keep, edit, revisit or share: a policy, a calendar, a reusable calculator or tool, a prototype.

Structured data

Tables, CSV or JSON when the output goes into a spreadsheet, CRM, ERP or HR system. Match the target system's exact column names.

Separate data from explanation

Give the importable table plus a short separate note or change log, so the system gets clean data and people get the reasoning.

Common traps

• Narrative paragraphs for something that must be imported.
• Slide decks or reports for a one-line question.
• Long chat threads as the home for a shared, living document.

Select the right Claude feature for the task

Chat, Projects, artifacts, web search and research, connectors and memory each solve a different problem.

Key ideas

Chat

One-off questions and tasks where you supply everything in the conversation.

Projects

A workspace with its own instructions and knowledge files, so every chat in it starts with the same reference material. Team and Enterprise plans let you share Projects with permissions.

Artifacts

Standalone outputs (documents, tables, interactive tools, prototypes) that can be revised and shared.

Web search and research

Current information with citations: news, competitor announcements, regulatory changes, prices.

Connectors

Let Claude work with your other tools (for example Google Drive or Gmail) within the connected user's own permissions.

Memory, styles and preferences

Carry personal context and writing style across chats; users can review and change what is remembered.

Extended thinking

Gives Claude room to reason through complex problems before answering, where available.

Common traps

• Pasting the same reference files into every chat instead of using a Project.
• Expecting training knowledge to cover this week's events.
• Assuming a connector gives access to files the user can't access.

Differentiate Haiku, Sonnet and Opus

The three tiers trade capability against speed and cost.

Key ideas

Haiku

Fastest and most economical. Suits high-volume, well-defined tasks: classification, routing, tagging, short extraction, real-time suggestions that people review.

Sonnet

The balanced choice for everyday drafting, summarising and analysis where both quality and responsiveness matter.

Opus

Most capable. Suits complex, high-stakes reasoning over long or conflicting material where quality matters more than speed or cost.

Versions move on

New generations arrive regularly; choose by tier characteristics, not by assuming “newest” or “largest” is always right.

Common traps

• “Always use the most capable model to be safe.”
• “Model choice doesn't matter.”
• Switching tiers to fix a problem that is really a vague prompt or missing context.

Align model choice with cost, speed and quality

Weigh volume, latency, complexity, stakes and frequency.

Key ideas

Volume and latency

Thousands of items a day, or results needed in real time, push towards faster tiers.

Complexity and stakes

Long, nuanced material or decisions with major consequences push towards more capable tiers.

Frequency

A one-off, high-stakes synthesis can justify a higher cost per use; a daily batch multiplies every cost.

Review changes the calculus

If people review every output anyway (for example suggested replies), a faster tier often gives the best value.

Test on a sample

Compare tiers on representative examples before committing a workflow.

Common traps

• Ignoring volume when picking a tier for a batch job.
• Picking by name or the CEO's preference.

Manage context limits and memory

A conversation's context is large but finite; long chats and big uploads can crowd out earlier details.

Key ideas

What uses context

The conversation history, uploaded files and instructions in that conversation. Other chats and account details don't.

Symptoms

Contradicting earlier agreements, repeating rejected ideas, overlooking files uploaded early in a long session.

Fixes

Ask for a summary of decisions, verify it, and continue in a new chat that starts from it; move stable reference material into Project knowledge; summarise large sets of files separately, then combine; upload only what's needed.

Memory is different

Memory carries personal preferences and context across chats. If it holds something outdated, review and correct it rather than working around it.

No unlimited context

No tier reads an unlimited amount of text; switching models doesn't remove the need to manage context.

Common traps

• Deleting earlier messages one by one.
• Restarting without a summary and losing agreed decisions.
• Assuming a bigger model removes context limits.

Analyse requirements and use cases

Start from the real process and a measurable problem, then find the steps where Claude genuinely helps.

Key ideas

Clarify the problem

Turn “use AI for onboarding” into specific pain points, measures (time, error rate, backlog) and the people who will act on the output.

Map the workflow

Walk through the current steps and find text-heavy, repetitive, judgment-light work: drafting from approved material, summarising, triaging, reformatting.

Good candidates

First drafts for review, summaries for a decision-maker, categorising enquiries, pre-call briefs, FAQ drafts from policy.

Poor candidates

Final decisions about people, money or safety; approvals; anything where nobody would check the output.

Check data and risk early

What data the step involves and whether policy allows it in an approved Claude workspace.

Worked example

A director says, “We should use AI to fix our referral backlog.”

Why: Requirements come before tools, and prioritising referrals is a decision people must own.

Common traps

• Buying licences for everyone as the first step.
• Letting Claude design the strategy or policy on its own.
• Telling stakeholders AI can't help without looking at the process.

Use Claude for research, planning and process optimisation

Claude is strong at structuring the work; evidence and decisions still come from real data and people.

Key ideas

Good uses

Research plans, interview and survey questions, hypothesis trees, comparison frameworks, stakeholder maps, discussion prompts, summaries of pre-reading.

Outputs are hypotheses

Bottlenecks or options Claude identifies from a description of a process must be tested against data and with the people who run it.

Never fabricate evidence

Don't let Claude write customer quotes, survey answers, benchmark data or case-study results to fill gaps.

Decisions stay with people

Market entry, programme mergers, budgets and closures are leadership decisions informed by the work, not outputs of it.

Common traps

• Putting Claude's estimated figures straight into a business case.
• Treating a well-structured suggestion as validated.

Support solution design and iteration

Pilot small, measure against a baseline, learn, then scale.

Key ideas

Pilot first

A small group, a defined use case, a set period. Mandating tools for everyone at once hides problems until they are expensive.

Measure outcomes

Time per deliverable, error or rework rate, quality-check results, customer satisfaction, compared with a baseline.

Ignore activity metrics

Number of prompts, chats opened or drafts produced say nothing about value.

Watch downstream effects

Faster proposals with falling win rates, or more emails with rising unsubscribes, mean the design needs work before scaling.

Iterate

Feed reviewer findings back into prompts, templates and instructions, then measure again.

Common traps

• Declaring success on time saved alone.
• Waiting for a “perfect” model before starting.

Integrate Claude into existing workflows

Define where Claude's output enters the process, who checks it, who approves it, and where the facts come from.

Key ideas

Hand-off points

Where does the draft enter, who reviews it, who approves the final version, how are errors reported and fixed?

Systems of record

Stock levels, delivery dates, account data and policy text come from the authoritative system, not from Claude.

Structured hand-offs

Use output formats that match the next system to avoid manual re-keying errors.

Know your remit

APIs, automated pipelines, database writes and system integrations are technical work. Document the business need and escalate to developers, architects, IT or security.

Never share credentials

Passwords and system logins don't go into chats or Projects.

Worked example

The e-commerce team wants Claude to update product listings in the store database.

Why: System integration is outside an Associate's remit, and credentials never belong in a chat.

Common traps

• Removing the reviewer to speed things up.
• Building integrations from online tutorials.
• Letting Claude send customer messages automatically.

Communicate Claude's value and limitations

Credible messages pair concrete, measured benefits with honest limits and the controls that manage them.

Key ideas

Be concrete

Two or three use cases from the audience's real work, with measured or expected time saved.

State limitations

Claude can produce plausible but wrong details, has a knowledge cutoff, and doesn't make decisions about people. Say how review handles this.

Avoid overclaiming

No “100% accurate”, “replaces the team” or guaranteed results. Propose a pilot when the honest answer is “we don't know yet”.

Address fears directly

Be transparent about what Claude will and won't be used for, how data is handled, and where to raise concerns (for example monitoring worries).

Answer data questions from facts

When clients ask how their data is handled, answer from the actual plan terms and policies, and involve legal or data leads if unsure.

Common traps

• Technical explanations of how language models work for a business audience.
• Avoiding the question or delaying communication until after rollout.

Configure Claude Projects

A Project combines standing instructions with knowledge files so every chat starts from the same context.

Key ideas

Instructions

Standing rules for every chat: role and audience, tone, output format, scope, which sources to use, what to do when information is missing, escalation.

Knowledge

Reference material: policies, manuals, price lists, brand guidelines, templates and approved examples.

The message

Task-specific details: this customer, this week's rota, this report's funder.

One purpose per Project

Separate Projects per client or team keep confidential material apart and instructions focused.

Sharing

On Team and Enterprise plans, Projects can be shared with view or edit permissions. Decide who may change instructions.

Common traps

• Pasting a full manual into the instructions.
• Putting one-off details in instructions where they affect every chat.
• One Project shared across several clients.

Manage uploaded knowledge and connectors

Keep one authoritative, current version of each source, and connect only what policy allows.

Key ideas

Replace, don't add

When a price list or policy changes, replace the old file. Keeping both makes Claude draw on conflicting sources.

Remove drafts and notes

Discussion documents and superseded drafts introduce contradictions. Keep the approved version.

Name and date files

Clear file names with versions or dates make reviews quick.

Connectors respect permissions

A connector reaches what the connected user can access, not everything in the organisation. Data policy still applies to what is used.

Before connecting

Check policy approval and what the source contains (confidential, personal or client data). Limit access to the folders or channels that are needed.

Worked example

A Project still quotes old prices although the new price sheet was uploaded last week.

Why: The cause is conflicting sources; fix the knowledge, not the wording.

Common traps

• Expecting Claude to “learn” new figures from users' corrections.
• Connecting an entire shared drive for convenience.

Write effective system-level instructions

Short, concrete, prioritised rules with examples and a clear fallback.

Key ideas

Concrete and testable

“Keep customer replies under 150 words in plain language” rather than “be concise and helpful”.

Name the source

“Answer return questions only from the Returns Policy document.”

Fallback behaviour

“If the knowledge doesn't cover it, say so and refer to the service desk” prevents invented answers.

Scope and escalation

What Claude should not do (give legal advice, recommend products, diagnose) and where to send people instead.

Resolve conflicts

If tones or lengths differ by context, say when each applies (“board updates: concise; grant reports: full background”).

Show, don't describe

Attach an example of the required format or template; descriptions alone are often ignored.

Common traps

• “Always be perfect” or “never make mistakes”.
• Thousands of words of accumulated rules with contradictions.
• Telling Claude to fill gaps from general knowledge in regulated settings.

Keep configurations current over time

Configurations drift unless someone owns them and reviews them on a schedule.

Key ideas

Named owner

One person is responsible for each Project's instructions and knowledge.

Review cadence

Review when policies, prices or brand guidelines change, and on a regular schedule (each term, quarter or release).

Change log

Record what changed and when, so inconsistent answers can be traced.

Reuse instead of copying

A procedure used across many Projects is easier to maintain as a reusable skill or a single maintained document than as copies in each Project.

Personal memory too

If remembered preferences go stale, review and update them.

Common traps

• Letting anyone edit instructions silently.
• Rebuilding the Project from scratch every week.

Identify appropriate and inappropriate use cases

Claude assists people; it doesn't replace accountable decisions about people, and it never fabricates what is presented as real.

Key ideas

Appropriate

Drafting from approved material for review, summarising for a decision-maker, brainstorming, explaining terms in plain language, preparing training content.

Inappropriate: automated consequential decisions

Rejecting loan, job or grant applicants, banning customers, deciding exclusions, dismissals, benefits or housing priority, without human review.

Inappropriate: fabrication presented as genuine

Fake reviews, testimonials, case studies, resident or customer posts, quotes or endorsements.

Inappropriate: profiling and deception

Labelling people as “difficult” or “likely to complain” for worse treatment; misleading appeals or statements.

The test

Would a person be harmed or misled if Claude were wrong, or if the output were taken as real? Then a human must decide, or it shouldn't be done.

Common traps

• “Acceptable if names are changed” or “if labelled as an example”, when the content still implies real results.
• “Fine because it's internal.”

Apply data-sensitivity, regulatory and privacy rules

Classify the data and confirm the tool is approved for it before anything goes into Claude.

Key ideas

Two checks first

What is the data's classification? Is this Claude workspace approved for that classification?

Minimise

Remove or pseudonymise identifiers you don't need; use placeholders and complete details in approved systems.

GDPR

Personal data of people in the EU: lawful basis, data minimisation, purpose limitation; involve the privacy team or DPO.

HIPAA

US protected health information: only in environments approved for it, with the required agreements such as a business associate agreement.

PCI DSS

Payment card data stays out of tools not approved for it. Masking part of a number isn't enough.

FedRAMP

US federal government use of cloud services requires appropriate authorisation.

Other controls

Export-controlled drawings, privileged legal material, client data under contract terms, children's data, consent scope for research participants.

What doesn't fix it

Deleting the chat afterwards, using a personal account, pasting “only half”, or keeping initials with full details.

Common traps

• “It's for the customer's benefit, so it's fine.”
• Treating partial redaction as de-identification.

Follow organisational AI governance policy

Policy applies under time pressure and regardless of who asks; concerns go through the proper channel.

Key ideas

Approved tools only

If the approved workspace is down or slow, report it; don't switch to a personal or unapproved tool.

Required reviews and disclosures

Follow approval steps and disclosure requirements in policy, contracts and regulation, even for “low-risk” flash sales or urgent work.

Seniority doesn't override

A manager's request doesn't authorise breaching policy or ethics. Decline and escalate.

Report incidents

Confidential data in an unapproved tool, exposed API keys or secrets, or misuse: report through the incident or security process so it can be assessed. Don't hide it or fix it quietly.

Improve policy properly

If a control is slowing work, raise it through governance rather than working around it.

Common traps

• “Just this once” exceptions.
• Asking Claude to approve in place of the named approver.
• Deleting evidence to protect a colleague.

Reason through the ethical implications of AI use

Fairness, transparency, accountability, honesty and dignity.

Key ideas

Fairness and bias

Watch for proxies (postcode, graduation year, “culture fit”) that encode protected characteristics. Use job-related criteria and monitor outcomes.

Transparency

Tell people when they are interacting with an AI assistant and how to reach a person; label AI-generated imagery as illustrative.

Accountability

People who approve and publish remain responsible for AI-assisted work.

Honesty

Public statements, appeals and recall notices must be accurate. Don't let wording imply what isn't true.

Vulnerable groups and dignity

Assess impact before decisions affecting vulnerable people, involve people with lived experience in reviewing sensitive content, and avoid language that strips people of agency.

Common traps

• “It raises more money, so it's fine.”
• “Make the implication subtler so it's not technically false.”

Diagnose and resolve underperforming prompts

Most problems trace back to inputs: missing context, buried or conflicting instructions, or stale knowledge.

Key ideas

Generic or bland output

Missing audience, goals and specifics; no examples of the target style.

Ignores a requirement

The instruction is buried in a long prompt or conflicts with another. Make it prominent, unambiguous and show an example.

Wrong or outdated facts from a Project

Check whether the current document is in knowledge and whether an older version or contradicting file is also there.

Different answers for different people

Different prompts, files or setups (Project vs standalone chat). Standardise inputs before judging consistency.

Invented numbers

Data wasn't provided and there's no rule for missing data. Supply the data and require “data not provided” instead of estimates.

Hedging on a legitimate task

Missing context about purpose and audience (training, safety, education). Explain it plainly; never disguise the request.

Common traps

• Switching models before fixing the inputs.
• Asking the same question repeatedly and taking the most common answer.

Adjust your approach based on feedback and results

Turn feedback into concrete instructions and examples, then measure whether it worked.

Key ideas

Adjectives rarely work

“Be polite” or “use simple language” changes little. Provide example outputs and name phrases to avoid.

Balance constraints

Fixing length can remove required content. Define the must-include items alongside the limit.

Describe the reader

“An admin who isn't an engineer” gives Claude a target; “simpler” doesn't.

Measure after the change

Check reply rates, rework or quality scores to confirm the adjustment helped.

Common traps

• Repeating the same instruction in capitals.
• Overcorrecting one problem and creating another.

Optimise AI workflows for efficiency

Fix the workflow, not just the latest output.

Key ideas

Recurring fixes are a signal

If people make the same edits every week, put the fix into the template, Project instructions or a reusable skill.

Standardise inputs and outputs

Consistent data exports and fixed output templates cut reformatting and checking time.

Find where time goes

Measure which steps (cleaning data, reformatting, re-checking) take longest before changing anything.

Look downstream

If drafts are fast but approvals or legal review stall, involve those teams in designing the template.

Share what works

One maintained template or Project for a team beats five private prompts.

Worked example

Five people rewrite a similar weekly report prompt from scratch.

Why: It removes duplicated effort and makes output consistent.

Common traps

• Removing review to save time.
• Producing more drafts when the bottleneck is approvals.