AI prompts for office administrators and executive assistants

Write a professional email to a [SUPPLIER / IMPORTER / DISTRIBUTOR / CUSTOMER].

RELATIONSHIP: [new / long-standing / strained]
PURPOSE: [e.g. request a quotation, confirm an order, chase a delayed shipment, dispute an invoice, negotiate price, request samples]
KEY FACTS: [ORDER NUMBERS, PRODUCT CODES, QUANTITIES, DATES, AMOUNTS, INCOTERMS if relevant]
WHAT I NEED BACK AND BY WHEN: [ACTION AND DEADLINE]
THEIR LANGUAGE LEVEL: [native English / English as second language]

Write:
1. A subject line with the reference number and topic
2. The email: purpose in the first sentence, the facts in a short list, the exact request and deadline, a polite close
3. A shorter follow-up for if there is no reply in [DAYS] days
4. If the reader uses English as a second language: simple sentences, no idioms, numbers written clearly (e.g. 12 October 2026, not 12/10)

Keep the tone professional and firm where needed. Do not invent any figures or dates I did not give.

Help me manage my manager's calendar requests.

MY MANAGER'S PRIORITIES THIS WEEK: [PRIORITIES]
CURRENT CALENDAR (paste or describe): [MEETINGS, TIMES, TIME ZONES]
NEW REQUESTS: [LIST: who, what, how long, how urgent]
RULES MY MANAGER PREFERS: [e.g. no meetings before 10am, focus time on Friday, 15 min gaps]

Do this:
1. Identify conflicts and overloaded days
2. Suggest a plan: what to accept, move, shorten, delegate or decline, with a one-line reason each
3. Write the messages: reschedule requests, polite declines, and confirmations - short and professional
4. Write a 5-line daily briefing for my manager for tomorrow
5. Flag anything that needs my manager's decision rather than mine

Keep time zones explicit in every proposed time.

Turn these meeting notes into a structured summary.

MEETING: [MEETING NAME]
DATE: [DATE]
ATTENDEES: [NAMES AND ROLES]

NOTES/TRANSCRIPT:
"""
[PASTE]
"""

Produce exactly these sections:

1. DECISIONS MADE - only things actually decided. For each: the decision, who made it, and what it supersedes if anything. If nothing was decided, write 'No decisions were made.' Do not pad this section.

2. ACTION ITEMS - a table: Action | Owner (a named person) | Due date | Blocked by. If no owner was named, write OWNER UNASSIGNED in capitals. If no date was given, write DATE UNASSIGNED.

3. OPEN QUESTIONS - things raised and not resolved, with who raised them.

4. DISCUSSED, NO ACTION - topics that came up and went nowhere. One line each.

Rules:
- Never invent an owner or a date. Unassigned is a finding, not a gap to fill.
- Do not editorialise or summarise tone.
- If someone disagreed and was overruled, record it in Decisions.

Draft follow-up messages for overdue action items.

OVERDUE ITEMS:
[PASTE LIST: action, owner, original due date, days overdue]

MY RELATIONSHIP TO THESE PEOPLE: [peer / their manager / their internal client / external]
CHANNEL: [email / Slack / Teams]
HOW URGENT IT ACTUALLY IS: [blocking others / important not urgent / nice to have]

For each person write one message that:
- Opens with the specific item, not a pleasantry
- States what it is blocking, factually, without guilt-tripping
- Offers a concrete out: a new date, a smaller version of the task, or reassignment
- Ends with a question that can be answered in one line
- Is under 80 words

Match the register to the relationship and channel. Do not use 'just circling back', 'gentle reminder', 'friendly nudge', 'as per my last message', or any exclamation marks.

If an item is genuinely nice-to-have and weeks overdue, say so and recommend dropping it instead of chasing it.

You are a process documentation specialist. Turn the messy description below into a formal Standard Operating Procedure.

PROCESS NAME: [PROCESS NAME]
DEPARTMENT: [DEPARTMENT]
WHO PERFORMS IT: [ROLE OR ROLES]
HOW OFTEN: [FREQUENCY]

MESSY DESCRIPTION:
"""
[PASTE THE INFORMAL DESCRIPTION]
"""

Produce the SOP with these sections in order:
1. Purpose - one sentence on why this process exists
2. Scope - what is and is not covered
3. Roles and responsibilities - table of role vs responsibility
4. Prerequisites - access, tools, approvals needed before starting
5. Procedure - numbered steps. One action per step. Start each step with a verb.
6. Decision points - any step where the path branches, written as IF/THEN
7. Common failure points - what usually goes wrong and how to recover
8. Revision history - a table with a single first row dated today

Rules:
- Where the description is ambiguous, do NOT invent detail. Insert [CLARIFY: your question] instead.
- Keep each step under 25 words.
- Do not use the words 'simply', 'just', or 'obviously'.

Build a structured onboarding checklist.

ROLE: [JOB TITLE]
REPORTS TO: [MANAGER ROLE]
KEY RESPONSIBILITIES: [PASTE FROM JOB DESCRIPTION]
SYSTEMS THEY WILL USE: [LIST TOOLS/SOFTWARE]
EXISTING DOCUMENTATION: [LIST SOP NAMES, OR 'none']

Produce a checklist across four phases: Before day one, Week one, Weeks 2-4, Days 31-90.

For each phase give a table: Task | Owner (new hire / manager / IT / other) | Done when (an observable, checkable condition) | Depends on.

Rules:
- 'Done when' must be observable. 'Understands the CRM' is wrong; 'Has independently logged one new lead in the CRM' is right.
- Every system in the list needs an access-request task in 'Before day one', owned by someone other than the new hire.
- Include at least two tasks where the new hire produces something reviewable, not just consumes information.
- Flag with [DOC GAP] any task that needs documentation you said does not exist.

Write a weekly update.

AUDIENCE: [WHO READS IT AND WHAT THEY DECIDE]
PERIOD: [DATES]
MY RAW NOTES: [PASTE EVERYTHING FROM THE WEEK]
KEY NUMBERS: [METRICS AND VALUES, WITH LAST WEEK'S IF YOU HAVE THEM]
WHAT I NEED FROM THE READER: [DECISION / AWARENESS / HELP]

Structure:

**Headline** - one sentence, the single most important thing that changed this week. If nothing changed, say that.

**Numbers** - a compact table: Metric | This week | Last week | Change | Comment (only where the change needs explaining).

**Shipped** - what actually completed. Not what was worked on.

**Risks** - only things that are newly risky or have got worse. Each with: what it threatens, and what would resolve it.

**Decisions needed** - a numbered list. Each with: the question, the options, my recommendation, and the deadline. If none, write 'None this week.'

**Next week** - three lines maximum.

Rules:
- Under 400 words total
- No progress-as-narrative. 'Continued working on X' is banned.
- Never carry a risk forward unchanged without noting how many weeks it has been open
- If a number moved and I have not explained why, write [UNEXPLAINED] next to it rather than guessing

Write a document request message to my clients for [TAX RETURN / YEAR-END / AUDIT] season.

MY PRACTICE: [DESCRIBE]
CLIENT TYPE: [individuals / sole traders / small companies]
DOCUMENTS I NEED: [LIST]
DEADLINE: [DATE]
HOW TO SEND THEM: [portal / email / WhatsApp / in person]
CONSEQUENCE OF MISSING THE DEADLINE: [e.g. late filing risk, extra fee]

Produce:
1. THE MAIN MESSAGE - short intro, a checklist grouped by category, the deadline in bold, how to send, and who to contact
2. A SHORT VERSION for WhatsApp or SMS (under 60 words)
3. REMINDER 1 (two weeks before) and REMINDER 2 (three days before), each shorter and firmer
4. A "WHAT IF I DON'T HAVE IT" section explaining what to do if a document is missing

Tone: friendly and organised, never scolding. Plain words, no jargon.

Compare these supplier quotes properly.

WHAT WE ARE BUYING: [DESCRIPTION]
QUOTES:
"""
[PASTE EACH QUOTE, SEPARATED BY ---]
"""
OUR REQUIREMENTS: [WHAT WE ACTUALLY NEED]
EXPECTED USAGE/VOLUME: [DETAIL]
HOW LONG WE EXPECT TO USE IT: [TIMEFRAME]

Produce:

1. NORMALISATION TABLE - restate every quote on the same basis: same period, same unit, same inclusions. State every adjustment you made.

2. TOTAL COST OF OWNERSHIP over my stated timeframe - including setup, onboarding, training, per-unit or per-seat growth, support tiers, overage charges, renewal uplifts, and exit/migration costs. Mark anything not stated in a quote as [NOT STATED - ASK].

3. WHAT EACH ONE EXCLUDES - the gaps between each quote and my requirements list.

4. NOT COMPARABLE - things that differ in kind rather than price: support hours, SLAs, contract length, termination rights, data ownership, where the data is held.

5. THE QUESTIONS TO ASK EACH SUPPLIER before deciding - specific to what each quote left vague.

6. RANKING - on total cost, and separately on fit to requirements. Say plainly if the cheapest does not meet the requirements.

Rules:
- Never compare headline prices without normalising first.
- Renewal uplift and exit cost are the two most commonly omitted figures. Always flag them if not stated.
- Do not recommend a supplier on price alone.

Help me write to an organisation.

WHO TO: [THE ORGANISATION AND DEPARTMENT, if you know]
WHAT I NEED: [THE OUTCOME YOU WANT]
THE SITUATION: [WHAT HAS HAPPENED, WITH DATES]
WHAT I HAVE ALREADY DONE: [PREVIOUS CONTACT AND RESPONSES]
WHAT I HAVE: [REFERENCE NUMBERS, ACCOUNT DETAILS, EVIDENCE]
DEADLINE: [IF THERE IS ONE]
TONE NEEDED: [routine request / firm / formal complaint]

Produce:

1. THE STRUCTURE - in this order, because organisations process letters rather than read them:
   - Reference numbers and account details at the very top, before anything else
   - What you want, in the first sentence
   - The relevant facts, briefly, in date order
   - What you have already done and what response you received
   - The specific action requested and by when
   - What happens if it is not resolved

2. THE OPENING SENTENCE - stating the outcome required. Letters that explain the situation for three paragraphs before making a request get skimmed and misrouted.

3. THE FACTS - my account, stripped to what is relevant and put in date order. Remove everything that does not bear on the request; length reduces the chance of being read.

4. THE SPECIFIC REQUEST - what exactly you want them to do, with a date. 'Please look into this' invites nothing; 'please refund £X by 30 October' can be actioned or refused.

5. THE ESCALATION LINE - what you will do if this is not resolved: escalate internally, go to an ombudsman or regulator, or take another route. Stated factually, once, without threat. Say what the realistic route actually is for this kind of organisation, because naming a real one carries weight and naming an implausible one does not.

6. THE TONE - matched to what I said I need. Firm is not rude, and anger reduces the chance of a good outcome because it makes the recipient defensive and the letter easy to dismiss.

7. WHAT NOT TO INCLUDE - the history of how this has made you feel, previous unrelated grievances, and sarcasm. All understandable and all counterproductive.

8. THE EVIDENCE - what to attach or reference, and the note to keep originals and send copies.

9. THE RECORD - what to keep: a copy, the date sent, how it was sent, and any reference given. If this escalates, the trail is what matters.

10. THE ROUTE - the most effective way to send it for this kind of organisation, and whether there is a better department or a formal complaints process to use instead.

11. THE FOLLOW-UP - when to chase if there is no response, and what to say.

Rewrite this email.

EMAIL:
"""
[PASTE]
"""

WHO IT IS TO: [RELATIONSHIP]
WHAT I NEED FROM THEM: [THE ACTION OR RESPONSE]
HOW BUSY THEY ARE: [very / normal / they have time]
CHANNEL NORMS: [formal workplace / casual team / external client]

Produce:

1. THE POINT - state what this email is actually asking for, in one sentence. If I have written 400 words and the ask is unclear, that is the finding.

2. WHAT THEY NEED VS WHAT I WROTE - the information required to act, versus the context I included because I wanted them to understand. Most email bloat is the writer justifying themselves.

3. THE REWRITE - with:
   - The ask or the key information in the first two lines
   - Any deadline stated as a date, not 'soon' or 'when you get a chance'
   - Context after the ask, not before, and only what is needed
   - Multiple asks numbered, never buried in prose. If there are more than three, say so - it should be a document or a meeting.
   - Under 150 words unless the content genuinely requires more

4. THE SUBJECT LINE - specific, and indicating whether action is needed. 'Approval needed: Q4 budget by Friday' beats 'Q4 budget'.

5. THE SKIM TEST - if they read only the subject and the first two lines, do they know what to do? Answer yes or no. If no, fix it.

6. WHAT I CUT AND WHERE IT SHOULD GO - context worth keeping but not here: a linked document, a follow-up, or a conversation.

7. SHOULD THIS BE AN EMAIL - if it is a decision needing discussion, or has more than three asks, say so.

Rules:
- No 'just', no 'sorry to bother you', no 'quick question' followed by a complex one
- Never make someone read to the end to find out what you want

Extract data from this document.

DOCUMENT:
"""
[PASTE]
"""

DOCUMENT TYPE: [CONTRACT / INVOICE / REPORT / FORM / STATEMENT]
WHAT I NEED: [THE FIELDS]
OUTPUT FORMAT: [table / CSV / JSON]
WHAT THIS FEEDS INTO: [WHERE THE DATA GOES]

Extraction rules:
- Extract only what is stated. Never infer a value and present it as extracted.
- Preserve exact wording, numbers and units. Do not convert, round or normalise.
- Where a field appears more than once with different values, report both and flag the conflict.
- Where a value is ambiguous, extract it with a note explaining the ambiguity.
- Where a field is genuinely absent, write NOT STATED. Do not leave it blank, which is indistinguishable from an oversight.

Output:

1. THE EXTRACTED DATA in my requested format.

2. THE SOURCE QUOTE for each field - the phrase it came from, so I can verify without rereading the document. For anything financial, legal or date-related, this is mandatory.

3. EXTRACTION NOTES - anything that was not a clean extraction: ambiguous, conditional, conflicting, or stated in an unusual place.

4. THE CONDITIONAL VALUES - fields whose value depends on a condition stated elsewhere in the document. These are the most commonly mis-extracted, because the headline figure is not the operative one. Flag every instance.

5. NOT FOUND - fields I asked for that the document does not contain, and whether the document indicates they exist elsewhere.

6. CONFIDENCE - which fields were reliably extractable and which required judgement.

7. WHAT ELSE IS IN HERE that I did not ask for but that bears on the fields I did - a deadline attached to a figure, an exception to a term, a cross-reference to another document.

Accuracy over completeness. A NOT STATED is better than a plausible guess, particularly for anything that will be acted on.