AI Enablement: Effective AI Building Requires Playbooks, Not Just Prompts

Key Takeaways

• Using AI and being good with it are different skills. Training builds the first. Building builds the second.
• A prompt helps one person once. A playbook is a tested, saved set of instructions (some vendors call these skills) that helps a team get the same result every time.
• Citizen developers carry this work. They are regular AI users with rigor, not programmers. Start with three or four people already building.

Your people are AI-fluent now. Someone in finance saved a workflow that reviews a report in minutes. Someone in operations built a dashboard that used to take a day. These are real wins, and almost none of them can be used by anyone else. Read on to change that.

Did you miss Part 1 of this article series on who owns AI in successful organizations? Read it here.

Using AI Is Not the Same as Being Good at Using AI

Knowing how to use the tool means you can write a prompt, read the answer, and move on. Being good with it means knowing how to shape a problem, when to trust the output, and when the work is too consequential to hand off without review.

Training delivers the first (the ability to use AI). People develop the second (being good at using AI) by building.

The people building fastest are rarely in technical functions. They sit in finance, operations, and the other functions where the work lives. This is encouraging, but also where the gap opens.

Every Prompt Is a Personal Workaround

At the first maturity level, individual use, gains stay with the person who found them. Everyone prompts differently, and people lose time reworking answers. The same question asked twice can return two different results. The organization sees none of it, so none of it compounds.

From Prompt to Playbook: A Month-End Example

Consider a fictional mid-sized manufacturer closing its books for the month: eight bank accounts, about 1,200 bank transactions, and a general ledger export. The controller wants every unreconciled item reviewed before Thursday’s close meeting.

The policy, in plain terms: timing differences clear within three business days, any unexplained difference over $500 needs an explanation, items outstanding more than 60 days escalate, and no one reconciles an account they can also post to.

A reviewer reading line-by-line would notice a check outstanding for 94 days, a payment that appears twice in the same week, and a manual journal entry of $9,950 just under a $10,000 approval threshold. But nobody has time to read 1,200 lines.

The first attempt with AI is a simple ask: What looks unusual here? The answer is generic, because the tool is guessing at the rules. Each step that follows adds control:

• Give it context. The written policy, the bank statements, the ledger export, and last month’s outstanding items turn a guess into a review against named criteria. Every finding points back to the rule it broke.
• Ask for a plan first. The tool proposes its tests, what it cannot determine from the data, and what it needs from you. You correct the approach while it is still only a plan, a principle of tokenomics.
• Define the output. You name the format, columns, and sort order: account, item, amount, type of difference, rule applied, risk rating, and recommended follow-up. You also ask for a summary paragraph that the controller can forward.
• Ask it to grade its own work. It flags thin evidence and instances where it assumed an item was a timing difference instead of tracing it to the statement.
• Save it as a playbook. Next month, the preparer runs one command and attaches the new statements.

The lesson is that context is the control. Judgment without context is a guess. The AI prepares, and a person still traces every exception to the bank statement and ledger before anyone signs off.

Rules Where Rules Work

Every workflow mixes steps with one right answer and steps that need judgment. Thresholds, mappings, and matching belong in rules or code. Interpretation belongs to the model. Seeing that split is the first step toward a playbook that behaves the same way each cycle.

The first draft of a playbook is fast. The reliable version takes testing and iteration. Applying automation to a broken process produces broken output faster, so mapping the process first often delivers value before any automation exists.

The Citizen Developer: Rigor, Not Code

The person who builds and maintains playbooks needs three things:

• Knowledge of the domain
• Discipline to test the output
• The habit of documenting and maintaining what they build

No coding experience is required. We call this role the citizen developer.

We recommend naming three or four citizen developers from the people already building, and one champion per function. Champions advocate, teach, and surface what works. Citizen developers turn it into shared playbooks. Each playbook has a named owner and a second owner, as Part 1 described.

Ground rules set the boundary. Builders can create playbooks, prompt templates, and light automation. Anything that writes into a system of record, and any agent or data application, goes to IT or a build partner. For a reconciliation playbook, that line is clear: The playbook can prepare the review, but posting an adjusting entry stays with people and the accounting system.

Questions to Ask This Week

• Which repeated, rules-heavy task takes your team the most time for the least judgment?
• Who are the three or four people already building, and do you know that they’re doing so?
• Is there a defined line between a personal tool and a shared one?

Continue Reading Part 3 on Managing AI at Your Organization

When everyone can build, the next question is not how to build more. It is who decides what ships. Part 3 takes that on.

This article was prepared with AI assistance and edited and enhanced by EisnerAmper professionals for accuracy and completeness. All technical content, analysis, and recommendations reflect the knowledge of our team.