It is Tuesday of week one, and Dana, an operations manager three days into her first AI readiness assessment, types eleven words into a chatbot: "how can we improve our invoice approval process". The answer arrives in four seconds and it is, in a strict technical sense, perfect. Five bullet points: standardize workflows, automate manual steps, improve visibility, engage stakeholders, measure continuously. It is also completely useless, because those five bullets would fit any invoice process at any company on any continent since the invention of the invoice. Dana reads it twice, feels the specific deflation of being handed a fortune cookie when she asked for a diagnosis, and starts drafting the conclusion that will quietly kill her assessment before it starts: this tool cannot do real work. She is wrong, but not in the way the AI enthusiasts down the hall think. The tool did exactly what it was asked. The problem is that Dana asked it the way she asks a search engine, and a search engine is the one thing it is not.

Prompting Was Never the Blocker, But It Is Your Hand Tool

Let us get one thing straight before we teach you a single technique, because Level 1 of this program earned the right to say it plainly. When MIT's GenAI Divide report found that 95 percent of enterprise generative AI pilots delivered no measurable profit-and-loss return, the autopsy did not list "employees wrote bad prompts" among the causes of death. The pilots died of missing workflow integration, absent learning loops, and adoption without transformation. BCG's 10-20-70 rule carves up the same territory: 10 percent of the challenge is algorithms, 20 percent is technology and data, and 70 percent is people and process. Prompting sits inside that 70, and here is the point most prompt-engineering courses will never tell you: no prompt, however elegant, rescues an organization that never redesigned the work. If a two-day prompting workshop could fix the 95 percent, the 95 percent would not exist.

So why is an entire lesson, this early in Level 2, devoted to prompting basics? Because you have just changed jobs. In Level 1 you were the analyst of AI failure; from this lesson forward you are an AI-assisted readiness assessor, someone who uses the tool to do assessment work: summarizing stakeholder interviews, comparing standard operating procedures (SOPs, the written step-by-step instructions that define how a process is supposed to run) against how work actually happens, drafting gap analyses, extracting themes from workshop notes. And for that job, the prompt is your hand tool. A carpenter's chisel did not cause the housing crisis, but a carpenter who cannot hold a chisel cannot build a house. Most process professionals currently hold the chisel the way Dana did: they type at the AI the way they type at a search box, get back the average of the internet, and conclude the tool is shallow. The tool is not shallow. The request was.

Here is the mental shift that everything in this lesson hangs on. A search engine retrieves documents that already exist; vague queries work fine because you will do the judging on the results page. A large language model generates a new document on demand, shaped entirely by what you put in the request. Ask a vague question and it must guess who you are, what process you mean, what format you want, and how confident to sound, and it fills every one of those gaps with the most statistically average answer available: the consulting sludge Dana received. Ask a structured question and the gaps close. AI prompting for business is not a dark art. It is the discipline of closing gaps the model would otherwise fill with averages, and for process work it comes down to one repeatable prompt pattern with four parts.

The Artifact: Your Four-Part Prompt Card

This lesson's named artifact is the Four-Part Prompt Card: a pocket template you fill in before any assessment task you hand to an AI. It fits on an index card, and by the end of this level you should be able to fill one in about ninety seconds. The four parts:

• ROLE. Who should the AI act as for this task? One sentence: "Act as a senior process analyst reviewing an accounts payable workflow for automation readiness."
• CONTEXT. What does it need to know that only you can supply? The process, the organization, the volumes, and above all the actual artifacts: the SOP excerpt, the interview notes, the process map description, pasted directly into the prompt.
• CONSTRAINTS. What shape must the output take, what is in and out of scope, and what should the AI do when it is unsure? Format, length, structure, and an explicit honesty instruction.
• CITE YOUR SOURCE. The clause that forces every claim in the output to point at the material you supplied, or to say, in so many words, "not in the provided material."

That is the whole pattern. It is not proprietary, it is not clever, and it will not impress anyone at a conference. What it will do is turn the tool from a fortune-cookie dispenser into a junior analyst who works from your documents, follows your brief, and shows its work. Watch what happens when Dana's colleague Marcus, who has been running AI-assisted assessments for a year, takes her exact request and rebuilds it on the card.

Dana's version: "how can we improve our invoice approval process". Marcus's version: "Act as a senior process analyst specializing in AI readiness assessment [ROLE]. Below is the current SOP for our invoice approval process at a 400-person manufacturing firm, plus notes from two interviews with accounts payable staff describing how the work actually happens; we process roughly 3,000 invoices a month [CONTEXT]. Compare the SOP to the interview notes and produce a gap analysis as a table with three columns: SOP step, what staff actually do, and the discrepancy. Flag any step where the two sources conflict. Stay within invoice approval; do not extend into procurement or payment execution. If something is unclear or missing from these documents, say so rather than guessing [CONSTRAINTS]. For every claim you make, cite the specific SOP step number or interview line it comes from. If a claim is not supported by the provided material, label it 'not in the provided material' [CITE YOUR SOURCE]."

The output changes species. Instead of five bullets that fit every company on earth, Dana gets back a table telling her that SOP step 4 requires a second approval for invoices over 10,000 but both interviewees describe routinely skipping it under month-end pressure, that steps 6 and 7 exist in the SOP but neither interviewee mentioned them at all, and that the SOP never states who resolves a price mismatch, flagged honestly as a gap in the documentation rather than papered over with an invented answer. That is not consulting sludge. That is the first page of a real readiness finding, produced in under a minute, and every line of it is checkable against documents Dana already has. The rest of this lesson slow-walks why each of the four parts does what it does, because a template you understand survives contact with new situations and a template you memorized does not.

Why Each Part Changes the Output

Role: Setting the Register and the Domain Priors

A language model has read, in effect, everything: recipe blogs, legal filings, physics papers, and forum arguments. When you ask a question with no role, it answers from the average of all of it, which is why unrolled answers sound like the internet's median explainer. A role line ("act as a senior process analyst") does two things. First, it sets the register: vocabulary, level of formality, assumed expertise of the reader. You stop getting definitions of "invoice" and start getting analysis that assumes you know what a three-way match is. Second, and more useful, it shifts the domain priors, the model's assumptions about which considerations matter. A "process analyst" role surfaces cycle time, handoffs, exceptions, and control points; a "marketing consultant" role applied to the same material would surface messaging and stakeholder buy-in. Same model, same documents, different lens. Choosing the role is choosing the lens, and for readiness work you will usually want some flavor of analyst, auditor, or skeptical reviewer, not a cheerleader.

One caution, because Level 1 trained you to ask it: a role does not confer real expertise. Telling the model to act as a forensic accountant does not make its arithmetic audited. Role shapes the framing of the answer; verification, which we come to shortly, establishes its truth.

Context: Replacing the Average of the Internet with Your Actual Process

This is the part with the highest payoff per minute of effort, and the part process professionals skip most often. Without your material, the model answers from its training data, which contains thousands of generic invoice processes and zero copies of yours. The output can only ever be the average of those thousands: technically fluent, universally applicable, specifically useless. The moment you paste in your actual SOP excerpt, your actual interview notes, your actual exception log, the model stops averaging and starts reading. Every sentence of grounded material you supply displaces a sentence of guessed material in the answer.

Context is where your professional experience becomes leverage, which is why this program keeps insisting that operations people, not data scientists, are the natural drivers of AI readiness assessment. You already know which documents describe the process, which interviews revealed the real workflow, and which numbers matter. Prompting for process improvement is mostly the craft of selecting and pasting the right two pages, not writing clever instructions around them. A practical rule of thumb: if your prompt is longer than the material you attached to it, you have the ratio backwards. And a practical caution that becomes a whole lesson later in this level: never paste material you are not authorized to share into a tool your organization has not approved for it. Customer data, personal data, and anything confidential follow your organization's data rules first and your curiosity second.

Constraints: Stopping Scope Drift and Forcing Honest Uncertainty

Left unconstrained, a model behaves like an eager junior consultant on their first engagement: it answers the question you asked, then the three adjacent questions you did not, in whatever format it fancies, with unwavering confidence throughout. Constraints are how you manage that junior. Format constraints ("a table with these three columns", "no more than ten findings, ranked") make the output land in the shape your working documents need, so you spend your time judging content instead of reformatting it. Scope constraints ("invoice approval only; do not extend into procurement") stop the drift that otherwise buries your one question under a strategy memo.

But the constraint that separates professionals from tourists is the uncertainty instruction: "If the SOP does not state it, say so. Do not guess." Here is the uncomfortable mechanic underneath it: a language model's default behavior is to produce a plausible completion, and a confident invented answer is often more plausible-sounding than an honest "the document does not say." The model will not volunteer its uncertainty; you have to create a permitted exit for it. When you explicitly instruct that "not stated in the material" is an acceptable, even preferred, answer, you change what the model is optimizing toward for that response. You have not made it honest in any deep sense. You have made honesty an available move, and in assessment work, where an invented process step can end up in a steering deck (we will watch exactly that happen shortly), that available move is worth more than any other sentence in your prompt.

Cite Your Source: Converting Prose into Checkable Claims

The fourth part is the one to steal word for word, so here it is, verbatim, ready for your card:

"For every claim, finding, or number in your answer, cite the specific document, section, or line from the material I provided that supports it. If a claim is not directly supported by the provided material, label it clearly as 'not in the provided material' instead of stating it as fact."

Understand precisely what this clause buys you, because it is subtler than it looks. It does not make the model accurate. A model can cite a source and still misread it, and it can occasionally fabricate a citation with a straight face. What the clause does is convert every sentence of the output from unverifiable prose into a checkable claim. "Approvals are inconsistently applied" is an assertion you can only shrug at. "Approvals are inconsistently applied (SOP step 4; Interview B, describing month-end practice)" is a claim you can verify in ninety seconds by opening two documents. The clause changes the unit of output from opinion to evidence-pointer, and evidence-pointers are the raw material of a defensible ai readiness assessment: the kind you can put in front of a steering committee and survive the one person in the room who checks.

This is also the bridge to Lesson 4 of this chapter, where you will build the Verification Habit into a formal routine. Citations do not replace verification; they make verification cheap. An uncited five-page summary takes an afternoon to verify because you must hunt for the source of every claim. A cited one takes an hour because every claim arrives holding a map to its own evidence. Remember the program's spine: the job did not shift from "do the work" to "let the AI do the work." It shifted from "produce the draft" to "verify the draft," and cite-your-source is the single prompt-level move that makes the new job tractable.

A prompt without a source clause produces prose. A prompt with one produces claims you can check, and checkable claims are the only kind an assessor is allowed to sign.

One Request, Four Ways: Watching the Output Change Species

To make the pattern concrete, here is the same underlying need, "figure out what is wrong with our invoice approval process," phrased at four levels of craft, with what each version actually gets back. This is the fastest way to teach how to prompt AI for process analysis, because the differences are not subtle.

Notice the shape of the progression. The jump from row one to row two is cosmetic. The jump to row three is real, and it comes entirely from context: this is the single lever most people never pull. The jump to row four is the professional finish: constraints and citations do not add much apparent brilliance to the output, but they are what make the output safe to rely on, and in assessment work "safe to rely on" is the entire product. Rows one and two are why so many capable operations professionals privately concluded AI was overhyped. They were evaluating the tool on its ability to read minds. Rows three and four evaluate it on its ability to read documents, which it is genuinely good at.

A Worked Example: Fourteen Transcripts, Two Roads

Now let us put hypothetical but realistic numbers on the payoff, because this program does not deal in vibes. The figures below are illustrative, not research findings; treat them as a template for estimating your own case.

You are running a readiness assessment at a mid-size logistics company. You have conducted 14 stakeholder interviews, 45 to 60 minutes each, transcribed to roughly 160 pages of raw text. Your deliverable is a themed summary: what did stakeholders say about data quality, process documentation, appetite for change, and current AI usage, with supporting quotes for each theme.

The manual road. Reading 160 pages of transcript with a highlighter, coding themes, and assembling quotes is honest, familiar work, and at a realistic pace it costs two to three full days. Call it 20 working hours. If your loaded cost is a hypothetical $95 an hour, that is about $1,900 of assessor time, and, more painfully, it is the entire middle of your assessment week gone. Most assessors under deadline pressure do not actually read all 160 pages; they skim, and the skim silently drops the quiet dissenting voice in interview 11 that later turns out to have been the most important signal in the set.

The four-part road. You fill in a Prompt Card: role (qualitative analyst supporting an AI readiness assessment), context (transcripts supplied in batches, with a one-paragraph description of the company and the assessment's four theme areas), constraints (theme table with supporting quotes and interview numbers, flag themes mentioned by three or more interviewees separately from single mentions, if a theme area has no supporting evidence say so), and the cite-your-source clause requiring every quote to carry its interview number. Working in batches, the AI pass takes about 45 minutes of machine time and your steering. Then comes the part that is not optional: verification. You spend roughly 90 minutes spot-checking every load-bearing quote against its cited transcript, confirming the three-or-more counts, and reading in full the two interviews the summary flagged as outliers. Total: about two and a quarter hours of your time instead of twenty. Hypothetically, $215 of time instead of $1,900, and the deliverable is arguably better, because the machine actually processed all 160 pages and the citations let you prove it.

Why the 90 minutes is non-negotiable. It is tempting to read that arithmetic as "45 minutes instead of 20 hours" and skip the verification. Do not. The 90 minutes is not overhead on the new process; it is the new process. Without it you have not produced an assessment, you have produced an unaudited machine draft with your name on it, and every error in it is now professionally yours. The honest comparison is 20 hours of manual work versus 2.25 hours of AI-assisted work, and that is still a saving of roughly 89 percent of the time. Anyone who sells you the version without the verification line is selling you the next failure story, which brings us, on schedule, to one.

The Failure Story: The Escalation Step That Never Existed

A transformation lead at a hypothetical financial services firm, capable, senior, and two weeks behind schedule, asked a chatbot to "summarize our customer complaint handling process for the steering committee" and pasted in a policy document. No role, no format constraints, no uncertainty instruction, no source clause. The output was fluent and confident, and it included this sentence: "Complaints unresolved after 48 hours are automatically escalated to the regional compliance officer." It sounded exactly right. It matched how such processes usually work at such firms, which is precisely the problem: the model, finding no escalation rule in the pasted policy, completed the pattern from its training data's average of every complaint process it had ever read. The step did not exist at this firm. There was no 48-hour rule and no regional compliance officer in the escalation path.

The summary went into a steering deck unverified. The deck was presented. A board-adjacent risk committee, reassured by that crisp escalation step, referenced it in minutes. Three weeks later an internal auditor, preparing for a regulator interaction, went looking for the 48-hour rule and found nothing. The unwinding cost, in this illustration, was not measured in dollars first. It was measured in the meeting where the transformation lead had to explain that a governance document contained a process step that no one had ever performed, invented by a tool, unchecked by a human. Every AI-assisted deliverable that lead produced afterward was re-reviewed line by line for months. The 20 minutes the shortcut saved was repaid at a hypothetical thousand-to-one interest rate in lost credibility, and the firm's whole AI-assisted assessment effort took the reputational hit. Recall the constraint and clause this lesson gave you: "if the document does not state it, say so" plus "label unsupported claims as not in the provided material". Either one, in that prompt, and the invented step arrives pre-flagged instead of pre-trusted. Both together cost two sentences. That is the entire trade.

This story is also why prompting earns its place inside BCG's 70 percent, the people-and-process share of the challenge. The four-part pattern is not a technology skill; it is a work practice, like double-entry bookkeeping or the surgical checklist, a way of structuring a task so that errors surface early and cheaply. The MIT 95 percent did not die of bad prompts, and your assessment will not be saved by good ones alone. But an assessor who cannot drive the hand tool cannot run an AI-assisted assessment at all, and an assessor who drives it without a source clause is one steering deck away from the story you just read.

What to Do Monday Morning

This lesson converts to muscle memory in one week of deliberate use. Here is the sequence.

1. Build your Four-Part Prompt Card. One page or one index card: ROLE, CONTEXT, CONSTRAINTS, CITE YOUR SOURCE, each with a one-line reminder of what it is for and your default wording. Write the cite-your-source clause out in full; it is the part you will otherwise abbreviate into uselessness.
2. Run one real assessment task through the card, twice. Pick a genuine task from your current work: summarize a meeting's notes, compare an SOP to reality, extract risks from a document. Run it once as a search-box prompt and once through the full card, then put the two outputs side by side and mark the differences. Ten minutes of diffing will teach the pattern more permanently than this lesson can.
3. Add the cite-your-source clause to every prompt you write this week. Every one, including the trivial ones. The goal is that by Friday its absence feels like leaving the house without your badge.
4. Verify one cited output end to end. Take one AI answer and check every citation against the source material. Time it. That number, citations-to-verified, is a personal baseline you will use in Lesson 4 when the Verification Habit becomes a formal routine.
5. Start a personal file of prompts that worked. A plain document: the task, the full prompt, one line on why the output was good. This file is the seed of the prompt library you will build properly in Lesson 5; assessors who keep one stop re-solving the same prompt every Monday.

Key Takeaways

• Keep prompting in its place: it was never why 95 percent of pilots failed (MIT's autopsy blames missing integration, learning loops, and transformation), but it is the hand tool of AI-assisted assessment, living inside BCG's 70 percent as a work practice, not a technology.
• Stop treating the AI like a search box: a search engine retrieves what exists, a language model generates what you specify, and every gap you leave in the specification gets filled with the average of the internet.
• Build every assessment prompt on the Four-Part Prompt Card: ROLE to set register and domain lens, CONTEXT to replace guessed material with your actual documents, CONSTRAINTS to fix format and scope, CITE YOUR SOURCE to make every claim checkable.
• Paste your material: context is the highest-payoff part of the pattern, your process knowledge is the leverage, and if your instructions are longer than your attached material the ratio is backwards; respect your organization's data rules on what may be pasted where.
• Write the honesty exit into every prompt: "if the document does not state it, say so, do not guess" makes uncertainty an available move for a model whose default is confident completion.
• Use the cite-your-source clause verbatim and understand what it buys: not accuracy, but checkability, converting prose into evidence-pointers that make verification cheap and assessments defensible.
• Count the verification time as part of the method, never as optional overhead: 45 minutes of AI time plus 90 minutes of checking still beat 20 manual hours in the illustrative transcript example, and skipping the 90 is how invented escalation steps reach steering decks.
• Start your prompt file this week: one real task run twice (search-box versus four-part), the diff studied, and every working prompt saved, seeds the prompt library you will formalize in Lesson 5.