European Sales Leadership

Get the official MillerKnoll PowerPoint template from OMNI or your team’s brand folder (ask your admin if you are not sure where it lives). Open it in PowerPoint desktop — the web version has fewer Copilot layout options. Immediately Save As with the client name — e.g. Contoso — QBR Jun 2026.pptx. Never edit the master template file itself.

Optional but helpful: if you have an approved deck for a similar meeting (QBR, new business, workplace refresh), open it side by side and note which section order and layout names your team expects. You are not copying client content — you are giving Copilot a structural pattern to follow.

Start a new Copilot conversation in this deck before you ask for content. The goal is to make Copilot list the slide layouts it can use and agree to stay inside them.

This file uses the official MillerKnoll corporate PowerPoint template. Before adding or changing slides, list every slide layout available in this file (layout names only). Confirm you will use only those layouts, fonts, and theme colors — not generic designs or new visual styles. Do not add slides yet.

This file uses the official MillerKnoll corporate PowerPoint template. Before adding or changing slides, list every slide layout available in this file (layout names only). Confirm you will use only those layouts, fonts, and theme colors — not generic designs or new visual styles. Do not add slides yet.

Stop and check: compare Copilot’s layout list to what you see when you click Home → New Slide. If the names do not match, re-run this prompt or name the layouts you want in the next step.

If your brief lives in Word, Teams, or a prior deck, reference it with @ in the Copilot pane so Copilot can read it. Useful attachments: a one-page client brief, meeting notes, an approved MillerKnoll corporate overview, or a redacted example deck (structure only). Do not attach confidential client decks you are not allowed to use with Copilot.

I will reference @Contoso brief.docx for facts about this client and meeting. Use it for content only — still use slide layouts from this PowerPoint file, not layouts from the attached deck.

I will reference @Contoso brief.docx for facts about this client and meeting. Use it for content only — still use slide layouts from this PowerPoint file, not layouts from the attached deck.

Replace Contoso brief.docx with your real file name. In the Copilot pane, type @ and pick the file from the list.

Copy the prompt in the box below, fill in every [bracket], and paste it into Copilot in PowerPoint. The section order mirrors approved MillerKnoll client decks. Copilot should propose a slide list first, then build one section at a time so you can correct course early.

I'm building a client presentation in this PowerPoint file, which uses the official MillerKnoll template. Use only slide layouts that already exist in this file.

CLIENT BRIEF
- Client: [name]
- Sector: [sector]
- Meeting purpose: [e.g. QBR, new business pitch, workplace refresh]
- Audience in the room: [roles and seniority]
- Key message they should leave with: [one sentence]
- What changed since last meeting: [paste updates, or "n/a — first meeting"]
- Proof points we can cite: [case studies, references, metrics — real only; leave blank if none]

DECK REQUIREMENTS
- Target length: [e.g. 12 slides plus appendix placeholders]
- Section flow (use MK layout names from this file where they fit):
1. Title / meeting purpose
2. Agenda
3. Client context and objectives (from brief only)
4. MillerKnoll relevance and portfolio fit
5. Proposed approach or recommendations
6. Proof points (only from brief or files I referenced)
7. Next steps and owners
8. Appendix placeholders for data still needed

RULES
- Write [Needs input] anywhere the brief does not supply facts — do not invent client details, pricing, timelines, or product specs
- Tone: professional, concise, client-appropriate — confident but not promotional
- Add speaker notes on every slide
- Use 3–5 bullets per content slide; no walls of text

WORKFLOW
1. Propose the full slide list with layout name for each slide
2. Wait for my approval before creating slides
3. After approval, build section 1–2 only, then stop for my review
4. Continue one section at a time after I confirm each batch

Stop and check: read the proposed slide list before you approve. Reject any slide Copilot assigns to a layout that does not exist, and rename sections that do not fit your meeting type.

After the first pass, stay in the same Copilot thread so it keeps the template context. Use these prompts to tighten the deck without restarting.

Here’s what changed since our last client visit: [paste updates]. Which slides need updating and what should the new bullets say? Use existing layouts only.
Flag every bullet that is not supported by my brief or the files I referenced. Mark unsupported claims as [Verify] in place.
Rewrite slides 3–5 for a dealer principal audience instead of an end client. Keep the same layouts.
Add appendix slides for data we still need from the team. Title each placeholder with what to collect and who owns it.
Reduce slides 4–7 to three bullets each and move detail to speaker notes.

• Here’s what changed since our last client visit: [paste updates]. Which slides need updating and what should the new bullets say? Use existing layouts only.

• Flag every bullet that is not supported by my brief or the files I referenced. Mark unsupported claims as [Verify] in place.

• Rewrite slides 3–5 for a dealer principal audience instead of an end client. Keep the same layouts.

• Add appendix slides for data we still need from the team. Title each placeholder with what to collect and who owns it.

• Reduce slides 4–7 to three bullets each and move detail to speaker notes.

Walk the deck yourself — Copilot will not catch every issue. Quick checklist:

• Every slide uses an MK layout (no rogue fonts, colors, or full-bleed designs that are not in the template)
• No invented pricing, timelines, product specs, or case studies
• [Needs input] and [Verify] markers are resolved or removed
• Speaker notes match what you would actually say in the room
• File is saved under the client name, not the master template

Get the source file into Excel and leave it alone. Keep raw data on its own sheet and never analyze on top of it — all analysis goes in new sheets so you can always retrace your steps. Formatting the range as a Table helps Copilot read it. Start by asking Copilot what it sees, so you both agree on what is in front of you.

Analyze this workbook. Tell me what columns exist, how many rows there are, the time period covered, and what each column appears to represent. Do not change anything yet.

Analyze this workbook. Tell me what columns exist, how many rows there are, the time period covered, and what each column appears to represent. Do not change anything yet.

Stop and check: you are only confirming what Copilot sees here. Do not let it modify the workbook yet, and check its read of the columns against what you know is actually in the file.

The quality of every later step depends on this one. Copilot works best with one row per observation, clear descriptive headers, consistent date formats, numbers stored as numbers, no merged cells inside the data, and no blank rows breaking the range. Do it in two passes: first have Copilot find the problems, then have it apply the fixes to a new sheet — never the source.

Check this data for quality issues: missing values, duplicate columns, inconsistent date formats, text inside numeric columns, merged cells, and blank rows. List what you find and where. Do not modify the source sheet — just report.

Now fix the issues you found and write the cleaned version to a new sheet called Clean Data. Leave the raw data sheet untouched. List every change you made so I can review it.

Check this data for quality issues: missing values, duplicate columns, inconsistent date formats, text inside numeric columns, merged cells, and blank rows. List what you find and where. Do not modify the source sheet — just report.

Now fix the issues you found and write the cleaned version to a new sheet called Clean Data. Leave the raw data sheet untouched. List every change you made so I can review it.

Stop and check: review the Clean Data sheet against the original before you trust it. Auto-cleaning can silently drop rows or reformat values, and a single text entry in a number column quietly breaks every calculation downstream.

This is where most of the quality comes from. The same column can be read three different ways, and only your context tells Copilot which is right. Before any analysis, give it a short description that covers:

• Purpose — what the dataset is for and the decision it supports
• Target — the one number you are trying to understand or predict
• What the columns mean — especially codes, abbreviations, and units
• Source — where each part of the data came from
• Time period and row meaning — the date range covered and what one row represents (e.g. one month of revenue)
• Known relationships — anything you already expect, such as a signal that leads sales by a few months
• Limitations — gaps, methodology changes, or columns you do not fully trust

Context changes the answer. You do not need to understand the math — Copilot calculates correlations; you judge whether the result makes business sense. Watch how the same finding reads with and without context:

Let Copilot draft it with you. You are still in the same chat from Steps 1 and 2, so Copilot already has a read on what your columns mean and has seen the data issues. Build on that — have it turn its guess into a first-pass description and ask you only what it cannot infer, then refine the draft into the summary you keep.

Based on what you already know about this workbook from the analysis so far, draft a first-pass description of this dataset: its purpose, the main number I care about, what each column means, where the data likely comes from, the time period, and any relationships you can infer. Mark anything you are unsure about, and ask me up to 8 short questions to fill the gaps. Then combine your read and my answers into a 5 to 6 sentence description I can save.

Based on what you already know about this workbook from the analysis so far, draft a first-pass description of this dataset: its purpose, the main number I care about, what each column means, where the data likely comes from, the time period, and any relationships you can infer. Mark anything you are unsure about, and ask me up to 8 short questions to fill the gaps. Then combine your read and my answers into a 5 to 6 sentence description I can save.

Once the description is right, have Copilot write the whole brief to a new sheet in one pass — the dataset description, a column-by-column rundown, a guide to the workbook’s sheets, and the analysis rules together. Copy the prompt in the box below when you are ready:

Save the finished brief to a new sheet called Copilot Brief. Include, in order: a short plain-language description of the dataset; a one-line description of every column; a rundown of the sheets in this workbook and what each is for; and the analysis rules listed below — written in exactly as given.

The sheet rundown it should capture:

• Raw data sheet — the original source; read-only, used only when you ask.
• Clean Data — the cleaned copy from Step 2; the default for all analysis.
• Copilot Brief — this sheet; the context and the rules.

The analysis rules it should capture:

• Treat the raw data sheet as read-only — never modify it; do all work on copies.
• For each correlation, give plausible reasons and at least one alternative explanation; never claim one thing causes another.
• Flag any correlation under 0.4 as weak and note how little it explains; do not base a recommendation on weak correlations alone.
• Before correlating, report how many rows each column actually has, and exclude or flag any column with significant gaps.
• Check whether a relationship could just be seasonality or a shared time trend before calling it meaningful.
• Only use values that are actually in the data; if a number is not present, say it is not available rather than estimating.

Save the finished brief to a new sheet called Copilot Brief. Include, in order:
1. A short plain-language description of the dataset.
2. A one-line description of every column.
3. A rundown of the sheets in this workbook and what each is for: the raw data sheet is the read-only original, used only when I ask; the Clean Data sheet is the cleaned copy and your default for all analysis; the Copilot Brief sheet (this one) holds the context and rules.
4. The analysis rules below, written in exactly as given:
- Treat the raw data sheet as read-only. Never modify, reformat, or delete it; do all work on copies.
- For each correlation, give plausible reasons and at least one alternative explanation. Do not claim one thing causes another.
- Flag any correlation under 0.4 as weak and note how little it actually explains. Do not base any recommendation on weak correlations alone.
- Before correlating, tell me how many rows each column actually has, and exclude or flag any column with significant gaps.
- Check whether a relationship could just be seasonality or a shared time trend before calling it meaningful.
- Only use values that are actually in the data. If a number is not present, say it is not available rather than estimating.

Stop and check: read the brief Copilot writes before you trust it. Fix any wrong column descriptions, and confirm all six rules came through exactly.

Part 1 checkpoint: you should now have three sheets — your original data (untouched), Clean Data, and Copilot Brief. Do not start Part 2 until all three exist.

You wrote six rules into the Copilot Brief in Step 3. Here is the reasoning behind them — what they protect against, and where the line falls between what you can use straight from Copilot and what you must verify yourself.

What you can use directly vs. what to verify before you rely on it

How outputs get misread — and the rule in your brief that guards against it

These six rules already live in your Copilot Brief from Step 3 — this section is the why behind them.

Copilot in Excel does not load your Copilot Brief sheet on its own. Do this at the start of every new Copilot chat in this workbook — including when you begin Part 2 below. Nothing works until Copilot is actually reading the brief.

Read the Copilot Brief sheet in this workbook before doing anything else, and treat it as the context and rules for this whole conversation. Work from the Clean Data sheet by default; only use the raw data sheet when I explicitly ask. Confirm what you have read and list the rules you will follow.

Read the Copilot Brief sheet in this workbook before doing anything else, and treat it as the context and rules for this whole conversation. Work from the Clean Data sheet by default; only use the raw data sheet when I explicitly ask. Confirm what you have read and list the rules you will follow.

Start broad before you drill. Ask for a small number of high-level findings with the numbers that support them, so you get oriented without drowning in detail. Save the output to a new sheet to keep your analysis documented and reproducible.

Using the Copilot Brief sheet, identify the 3 most important insights in this data. For each one, give the supporting numbers and one sentence on why it matters to the business. Save the summary to a new sheet.

Using the Copilot Brief sheet, identify the 3 most important insights in this data. For each one, give the supporting numbers and one sentence on why it matters to the business. Save the summary to a new sheet.

Stop and check: these are headlines to verify, not conclusions. Trace each number back to the sheet before you repeat it, and watch for anything that contradicts what you already know about the business.

Now follow the threads the overview surfaced. Rank what relates to your target, then pressure-test the strongest relationships over time, with lags, and against seasonality. Run these one at a time and read each result before moving on. Replace [target column] with the column name Copilot listed in Step 1 (for example, Revenue).

Calculate the correlation between [target column] and every numeric column. Rank by absolute strength and label each as strong, moderate, or weak. Save the table to a new sheet.

For the top 3 correlated indicators, chart each one against [target column] over time and flag any periods where they moved in opposite directions.

Test whether [indicator] predicts [target column] better with a 1 to 3 month lag than in the same month, and whether any pattern is just seasonality.

Calculate the correlation between [target column] and every numeric column. Rank by absolute strength and label each as strong, moderate, or weak. Save the table to a new sheet.

For the top 3 correlated indicators, chart each one against [target column] over time and flag any periods where they moved in opposite directions.

Test whether [indicator] predicts [target column] better with a 1 to 3 month lag than in the same month, and whether any pattern is just seasonality.

Stop and check: this is where the worst mistakes happen. A high correlation proves nothing on its own. Before you believe any relationship, make Copilot give an alternative explanation and the number of rows behind it, and rule out seasonality or a shared trend. If Copilot is reading your Copilot Brief sheet, the rules you saved in Step 3 enforce this automatically.

The simple rule: if a decision rides on the number, verify it before it leaves the room — and bring in the data science team when the work is a new project or needs a more formal forecast.

Paste the prompt below into Copilot chat. Answer one question at a time. When done, replace your minimal agent instructions with the personalized blocks Copilot generates.

You are helping me build a Weekly Update Agent for Copilot Agent Builder.

Ask me ONE short question at a time. Cover only:
1. How my manager likes updates (format, length, what they care about)
2. The 3–5 projects I report on weekly
3. What messy inputs I will paste each Friday

Then produce paste-ready blocks:
- Agent Description
- Agent Instructions (bullet rules + output sections)
- Weekly Input Template (conversation starter)
- Sample Output using my answers

Keep it practical. Under 8 questions total. Do not invent metrics.

Add Microsoft 365 sources to your Instructions if not already included:

When relevant, use:
- Outlook emails for recent updates
- Teams conversations for decisions/actions
- OneDrive files for project context
- Calendar for meetings and outcomes

Before you build anything, decide what durable knowledge the agent carries. For meeting prep, three documents do almost all the work. Give each a clear, stable name now and use it everywhere — you will reference these exact names in the agent’s instructions, and naming them has proven far more reliable than “the attached files”. The examples behind this guide are placeholders; your job is to build your own version of each:

• Sales Methodology — how you sell: account types and who leads each, your deal stages, the stakeholder types you sell to and what each cares about, and what you expect from every client meeting.
• Brand Voice Spec — how you sound: used only for the language the agent drafts for you to say out loud. Keep it off the rest of the doc, which stays in plain internal tone.
• Meeting Prep Template — what good output looks like: the fixed section order, the sourcing and honesty rules, and one worked example so the agent copies the right level of detail.

Optionally add a thin Portfolio Primer so the agent can map a client’s need to the right solution. Everything else — anything about a specific client — stays out of grounding on purpose.

Stop and check: if a document would go out of date when a client or a deal changes, it does not belong in grounding. Durable only.

You almost certainly already have the raw material — playbooks, onboarding notes, approved decks, CRM stage definitions, scattered across drives and inboxes. Use Copilot chat at microsoft365.com/chat (or Copilot in Word) to turn that into clean documents. Do these three prompts in order — finish and save each document before starting the next:

I am building a reusable Copilot agent that preps me for client meetings, and I need a clear “how we sell” reference for it to follow. I am pasting everything I have — sales playbooks, onboarding notes, CRM stage definitions, and my own notes. Synthesize this into a structured methodology covering: our account types and who leads each, our deal stages, the stakeholder types we sell to and what each one cares about, and what we expect from every client meeting. Keep it concrete and rule-based. Where my materials are silent or contradict each other, list the gap and ask me — do not invent an answer. [Paste your materials below.]

I want a short brand-voice spec my Copilot agent can follow when it drafts language I will say out loud to clients. I am pasting examples of approved messaging — decks, proposals, and emails that sound right. From these, extract: the voice and tone rules, a do-and-don’t list, the words and phrases we favor and avoid, and three to four before-and-after rewrite examples. Base every rule on a pattern you actually see in my examples, and flag anything you are inferring. [Paste your approved examples below.]

Help me design the output template my meeting-prep agent should always produce. The meeting is in person, not a presentation — I need points to hit and selling notes, not slides. Based on the sales methodology and stakeholder types in the document I am pasting, draft: a fixed section order for the prep doc; the sourcing and honesty rules the agent must follow (cite every client-specific claim with a date, never invent a stakeholder’s view, flag thin or assumed points); and one short worked example with a fictional client so I can see the level of detail. [Paste your methodology doc below.]

What separates grounding Copilot follows from grounding it ignores:

• Concrete beats abstract. Rules and examples outperform principles. “Flag any claim with one source” works; “be rigorous” does not.
• Show good and bad. Before-and-after pairs teach the agent where the line is far better than description alone.
• Include a worked example. The agent imitates the level of detail it sees. Give it a filled example and it fills the same way.
• You own it. Copilot drafts, you verify and correct. Wrong grounding poisons every meeting prep after it — read each doc before you attach it.

Stop and check: these three documents set the ceiling on everything the agent produces. Spend the time here; it is cheaper than fixing every prep doc downstream.

You already wrote your instructions in the grounding step — choose Skip to configure instead of describing the agent in chat.

Open Agent Builder on your computer (not on your phone — Agent Builder needs a desktop browser):

1. Go to microsoft365.com/chat .
2. In the left menu, click Agents, then New agent, then Skip to configure.
3. You will work on the Configure tab (fill in the fields), then Try it (test your agent), then click Create when you are ready to save.

1. On the Configure tab, set Name to Client Research & Meeting Prep.
2. Under Knowledge, click Browse and attach your three documents (Sales Methodology, Brand Voice Spec, Meeting Prep Template) from SharePoint or OneDrive.
3. Under Capabilities, turn on web search so the agent can find public client information.
4. Paste the system prompt below into the Instructions field, exactly as written.
5. Click Try it — ask the agent to summarise the Meeting Prep Template back to you. If it cannot, your documents did not attach correctly.
6. When checks pass, click Create to save the agent.

The system prompt calls out each grounding document by name so the agent knows exactly where to look:

ROLE
You are Client Research & Meeting Prep, a Copilot agent that researches a
client and produces an internal meeting-prep document for an in-person sales
meeting. Your output is points to hit and selling notes the seller reads before
the room — never a client-facing deck or marketing copy.

GROUNDING
You are grounded in three attached documents. Refer to them by these exact names:
1. "Sales Methodology" — account types and who leads each, deal stages,
   stakeholder lenses, and meeting expectations.
2. "Brand Voice Spec" — applies ONLY to language meant to be spoken to the
   client, not to the rest of the document.
3. "Meeting Prep Template" — the exact output shape, the sourcing rules, and a
   worked example. Follow its section order exactly, every time.

SOURCES
Client-specific facts come only from the sources the seller attaches this
session and from web search. Never reuse client details remembered from another
session. Cite a source — file, email, chat, or web link with a date — for every
client-specific claim. If a fact has no source, leave it out.

RULES
• Never invent that a stakeholder said, wants, or believes something. Attribute
  it or omit it.
• Separate fact from inference. Label reasoned-but-unconfirmed points as
  "Assumption:".
• Flag thin evidence: single-sourced, stale (give the date), or contradicted
  across sources.
• Identify the account type (we lead / dealer-led / combination) from the
  "Sales Methodology" before writing — the strategy differs.
• Map every point to the specific stakeholders in the room and what each cares
  about, using the lenses in the "Sales Methodology".
• Treat web findings as leads, not gospel; prefer primary sources and note
  recency.
• Apply the "Brand Voice Spec" only to the selling-notes language; keep
  everything else in plain internal tone.

WHEN UNCERTAIN
Ask the seller for what you are missing before producing the doc. List your
questions; do not fill gaps with guesses.

NEVER
• Invent client facts, stakeholder views, numbers, or references.
• Skip the "Meeting Prep Template" structure — produce every section, marked
  "Not in sources" if empty.
• Dress internal prep notes in marketing language.

Stop and check: two checks before you trust it. First, confirm grounding: ask the agent to summarise the Meeting Prep Template back to you and list the rules from its instructions — if it cannot, the docs or instructions did not attach. Second, test the guardrail: give it a client fact with no source and confirm it refuses to use it. If it accepts the fact anyway, the instructions are not taking — recheck they saved.

Open your saved agent: Agents → Client Research & Meeting Prep → start a new chat. Then gather the emails and files that matter for this meeting — about ten minutes. You are not dumping your whole inbox; you are choosing what is relevant and recent.

Client: [name]. Account type: [we lead / dealer-led / combination — and who leads]. Meeting: [date], in person at [location]. In the room: [their names + roles; our names + roles]. My objective: [one sentence]. Desired outcome: [one sentence]. Sources attached: [list the files and threads].

Client: [name]. Account type: [we lead / dealer-led / combination — and who leads]. Meeting: [date], in person at [location]. In the room: [their names + roles; our names + roles]. My objective: [one sentence]. Desired outcome: [one sentence]. Sources attached: [list the files and threads].

Stop and check: relevant and recent only. Old threads pull the prep off course, and naming the account type now decides how the agent frames everything that follows.

Start a new session, give the agent your meeting brief, and attach the sources. Have it research and report back before it drafts — and, like a good analyst, ask you about anything it cannot confirm rather than guessing.

Here is my meeting brief and the sources for this client. Read the attached sources and search the web for recent public information about this client. Before writing anything, tell me what you found and where each thing came from, then ask me up to eight short questions about anything you cannot confirm from the sources. Do not assume — flag every gap.

Here is my meeting brief and the sources for this client. Read the attached sources and search the web for recent public information about this client. Before writing anything, tell me what you found and where each thing came from, then ask me up to eight short questions about anything you cannot confirm from the sources. Do not assume — flag every gap.

Stop and check: answer its questions and correct any misread before it drafts. Fixing a wrong assumption now costs a sentence; fixing it after the doc is built costs a rewrite — or a bad moment in the meeting.

Now have it synthesize everything into the prep document, held to the Meeting Prep Template and your sourcing rules.

Now produce the meeting-prep document, following the Meeting Prep Template exactly. Cite a source with a date for every client-specific claim. Map the points to hit and the selling notes to the specific people in the room and what each one cares about. Label anything you are inferring as an assumption, and flag any point that is thin, single-sourced, or out of date.

Now produce the meeting-prep document, following the “Meeting Prep Template” exactly. Cite a source with a date for every client-specific claim. Map the points to hit and the selling notes to the specific people in the room and what each one cares about. Label anything you are inferring as an assumption, and flag any point that is thin, single-sourced, or out of date.

Stop and check: check it followed the Meeting Prep Template: every section present, the right account-type framing, and a source on every client claim. If a section is empty it should say “Not in sources”, not fill the gap with something plausible.

The last step is yours. Make the agent expose its evidence so you can spot-check the claims that matter before you walk in.

List every client-specific claim in the document as a table with its source and the date, and mark which ones are single-sourced or assumptions. I want to spot-check before the meeting.

List every client-specific claim in the document as a table with its source and the date, and mark which ones are single-sourced or assumptions. I want to spot-check before the meeting.

Stop and check: trace the riskiest claims back to the actual source, confirm the account framing and stakeholder fit, and fix anything off before you walk in. If the agent is following the system instructions you wrote in Step 3, most of this holds automatically — this is the check, not the safety net.

The prompt below looks long on purpose. Paste the entire block as your first message. Copilot will ask you one question at a time.

# Copilot Agent Architect (Enterprise Edition)

You are an expert Microsoft Copilot Agent Architect, AI Enablement Consultant, Knowledge Management Specialist, Process Improvement Facilitator, and Enterprise Solution Designer.

Your mission is to help users design high-quality, production-ready Copilot agents through a structured discovery interview before generating any agent instructions.

Your objective is **not** to build the biggest agent.

Your objective is to design the **smallest useful agent** that solves a real business problem, delivers measurable value, minimizes risk, and can be deployed with confidence.

***

# Critical Rules

1. Do not generate agent instructions until the interview is complete.
2. Conduct the interview first.
3. Never assume requirements.
4. Challenge vague answers.
5. Prefer specificity over generality.
6. Continuously look for ways to reduce scope.
7. If information is missing, continue the interview.
8. Use follow-up questions whenever answers are incomplete.
9. Prioritize practicality over complexity.
10. Recommend simpler solutions when an agent is not the best answer.

***

# Interview Control Rules (Critical)

These rules override all other instructions.

### Ask One Question At A Time

1. Ask exactly one question in each response.
2. Never ask multiple numbered questions in a single message.
3. Never present an entire questionnaire.
4. Never dump a phase worth of questions at once.
5. Wait for the user's answer before continuing.

### Evaluate Before Continuing

After each user response:

1. Evaluate whether the answer is:
   * Complete
   * Partially complete
   * Vague
   * Contradictory

2. If the answer is incomplete:
   * Ask a follow-up question.
   * Stay on the current question.

3. Do not advance until the current question has been adequately answered.

### No Premature Design

During the interview:

* Do not create agent instructions.
* Do not create system prompts.
* Do not create architecture.
* Do not recommend tools unless directly relevant.
* Do not jump ahead to implementation.

### No Assumptions

If the user says:

* Everyone
* Everything
* All documents
* Any source
* All departments

Treat the answer as incomplete and ask for clarification.

***

# Conversation State Management

Track internally:

* Current Phase
* Current Question
* Completed Questions
* Unresolved Questions
* Collected Requirements
* Risks
* Open Assumptions
* Missing Information

Do not display these internal notes unless specifically requested.

Never re-ask completed questions.

Never skip required questions.

***

# Clarification Protocol

Challenge vague responses.

Example:

User:

> Everyone will use it.

Response:

> That's typically too broad for a successful first-release agent. Who is the single primary user that would receive the most value from this solution?

Example:

User:

> It should use all our documents.

Response:

> Which specific repositories or content sources would a human expert actually use to answer these questions?

Example:

User:

> The agent helps sales.

Response:

> What specific sales activity? For example: account research, proposal creation, lead qualification, opportunity review, forecasting, customer communications, or something else?

***

# Discovery Process

***

# Phase 0: Agent Fit Assessment

### Question 1

What business problem are you trying to solve?

Why this matters:

This determines whether a Copilot agent is actually the right solution and establishes the foundation for all future design decisions.

Example answers:

* Responding to repetitive customer questions
* Creating project status reports
* Finding information across policies
* Reviewing supplier requests
* Helping new employees onboard

Wait for a response.

Do not continue until answered.

***

### Question 2

What are people doing manually today?

Wait.

***

### Question 3

Why is the current process painful?

Wait.

***

### Question 4

Is this primarily:

* Information retrieval
* Research
* Content creation
* Analysis
* Decision support
* Workflow execution
* Knowledge management
* Process guidance

Wait.

***

### Question 5

Why is a conversational AI agent the best solution?

Could a:

* SharePoint page
* Knowledge article
* Template
* Dashboard
* Workflow
* Existing application

solve this better?

Wait.

***

### Question 6

How frequently does this task occur?

* Multiple times per day
* Daily
* Weekly
* Monthly
* Quarterly
* Rarely

Wait.

***

# Phase 1: Define The User And Trigger

### Question 7

What repetitive task are you tired of doing?

Wait.

***

### Question 8

Complete this sentence:

> Every time I need to...

Wait.

***

### Question 9

Who is the primary user?

Only one primary audience.

Wait.

***

### Question 10

What level of expertise does this user have?

* Beginner
* Intermediate
* Expert

Wait.

***

### Question 11

What should users already know before using the agent?

Wait.

***

# Phase 2: Define The Work

### Question 12

What information will the user provide to the agent?

Wait.

***

### Question 13

What should the agent return?

Wait.

***

### Question 14

Show me an example of an excellent output.

Wait.

***

### Question 15

What decisions will people make using this output?

Wait.

***

### Question 16

What actions should users take after receiving the output?

Wait.

***

# Phase 3: Define Knowledge Sources

### Question 17

If a human expert had to answer this request, where would they go?

Wait.

***

### Question 18

Which source is authoritative if multiple sources disagree?

Wait.

***

### Question 19

What information should the agent never use?

Wait.

***

### Question 20

How often does the knowledge change?

Wait.

***

### Question 21

How will users know information is current?

Wait.

***

# Phase 4: Risk, Governance, And Human Oversight

### Question 22

Does the agent access sensitive information?

Wait.

***

### Question 23

Could incorrect output cause harm?

Wait.

***

### Question 24

Classify the overall risk:

* Low
* Medium
* High

Wait.

***

### Question 25

Which outputs require human review?

Wait.

***

### Question 26

What mistakes would immediately destroy trust in the agent?

Wait.

***

### Question 27

What should the agent refuse to do?

Wait.

***

# Phase 5: Define Success

### Question 28

Six months from now, how will you know this agent succeeded?

Wait.

***

### Question 29

What would your team stop doing manually?

Wait.

***

### Question 30

Which KPI should improve?

Wait.

***

# Readiness Review

After all questions have been completed:

Perform a readiness assessment before generating any solution.

Evaluate:

## Strengths

What is well-defined?

## Risks

What remains uncertain?

## Missing Requirements

What is incomplete?

## Scope Reduction Opportunities

Can the solution be made simpler?

***

# Interview Completion Gate

Before generating the agent specification verify that all categories have been completed:

* Business Problem
* Agent Fit
* User
* Trigger
* Inputs
* Outputs
* Knowledge Sources
* Knowledge Restrictions
* Risk Classification
* Human Review Requirements
* Success Criteria
* KPIs
* Refusal Criteria

If anything is missing:

Do not generate the agent.

Instead output:

## Information Still Needed

* Item 1
* Item 2
* Item 3

Then continue the interview.

***

# Agent Generation

Generate only after the interview has been successfully completed.

***

# Executive Summary

Include:

* Problem Being Solved
* Target Users
* Business Value
* Success Metrics
* Risk Classification

***

# Agent Overview

Create a concise description suitable for the Copilot Agent Builder Description field.

***

# Agent Instructions

## Role

## Purpose

## Scope

## Out Of Scope

## Users

## Inputs

## Knowledge Sources

## Knowledge Restrictions

## Decision Framework

### When Evidence Is Sufficient

### When Evidence Is Missing

### When Clarification Is Required

### When Escalation Is Required

### When Refusal Is Required

## Reasoning Process

## Response Requirements

## Quality Standards

## Human Review Requirements

## Safety And Governance Rules

## Refusal Criteria

***

# Knowledge Base Recommendations

Provide:

## Required Content

## Missing Content

## Metadata Recommendations

Examples:

* Owner
* Business Area
* Function
* Product
* Region
* Effective Date
* Expiration Date

## SharePoint Structure Recommendations

## File Organization Recommendations

## Governance Recommendations

***

# Testing Plan

Generate:

## 10 Happy Path Tests

For each:

* Test Prompt
* Expected Behavior
* Success Criteria

***

## 10 Edge Cases

For each:

* Test Prompt
* Expected Behavior
* Success Criteria

***

## 10 Failure Cases

For each:

* Test Prompt
* Expected Behavior
* Success Criteria

***

## 10 Hallucination Tests

Examples:

* Fake policy
* Fake product
* Missing document
* Unsupported recommendation
* Unknown acronym

For each:

* Test Prompt
* Expected Behavior
* Success Criteria

***

# Future Enhancements

Recommend:

* Additional Knowledge Sources
* Connected Agents
* Power Automate Opportunities
* Workflow Automation Opportunities
* Human-In-The-Loop Enhancements
* Metrics And KPIs
* Governance Enhancements
* Expansion Opportunities

Only recommend enhancements that directly support the original business objective.

Avoid unnecessary scope expansion.

***

# Final Design Principle

Always challenge complexity.

If a simpler solution can solve the problem, recommend the simpler solution.

The best agent is not the most powerful one.

The best agent is the smallest, safest, most trusted solution that reliably solves the user's problem.

1. Answer one question at a time until the interview is complete — plan about 30–45 minutes.
2. If Copilot jumps ahead, reply: “Stop. Ask one question at a time per the interview rules.”
3. When Copilot finishes, save the full specification — especially the Testing plan and Knowledge Base Recommendations.