# Operating Templates — `[TEAM / COMPANY NAME]` *Six one-page tools for running the rollout, not just planning it. The playbook tells you what to do; these are what you fill in while you do it. Copy the one you need, delete the rest, and make each your own.* Reach for them roughly in this order: 1. **Use-case scoring sheet** — decide what's worth trying. 2. **"Can I use AI for this?" decision aid** — the 30-second check anyone runs before pasting. 3. **Pilot tracker** — run the small experiment and decide its fate. 4. **Output-evaluation checklist** — prove the output holds up before anyone relies on it. 5. **Graduation & ownership record** — when an experiment becomes a dependency someone has to maintain. 6. **Leadership update** — report honestly, and make the next ask credible. Everything is plain Markdown. Nothing here is meant to survive contact with your team unchanged. **Want to see all six filled in first?** [worked-example.md](./worked-example.md) is one (invented) 14-person team taken through every template on this page — the scoring with real candidates and the losers explained, a pilot tracker with four weeks of check-ins, a verification that found two genuine defects, and the update that went to the VP. Sections 3 through 8 map one-to-one onto sheets 1 through 6 below. --- ## 1. Use-case scoring sheet *Most teams pick their first use case badly, and predictably: too ambitious, too rare, too far from the person choosing. Score the candidates instead of arguing about them. Higher total = better first bet.* Rate each candidate 1–5 on five axes: | Axis | 1 (poor bet) | 5 (good bet) | | --- | --- | --- | | **Frequency** | Quarterly or rarer | Daily or weekly | | **Stakes if wrong** | Customer-facing, hard to undo | Internal, easy to catch and fix | | **Data risk** | Needs confidential / regulated data | Uses nothing sensitive | | **Ease of review** | Nobody can quickly tell if it's right | A person can verify in seconds | | **Likely reuse** | One-off | Same shape every time, many people | | Candidate use case | Freq | Stakes | Data | Review | Reuse | Total | | --- | --- | --- | --- | --- | --- | --- | | `[…]` | | | | | | | | `[…]` | | | | | | | | `[…]` | | | | | | | | `[…]` | | | | | | | **How to read it.** Start with the highest total. A near-zero on **Data risk** or **Ease of review** is close to a veto no matter how high the total — a frequent, high-reuse task you can't safely feed or can't check is a trap, not a starter. The best first use case is frequent, low-stakes, sensitive-data-free, and easy to check. --- ## 2. "Can I use AI for this?" decision aid *The one-page policy draws hard lines. This is for the borderline case in the moment — a fast check anyone can run at their desk. It doesn't replace the policy and it can't extend it; it walks you through it. When in doubt, the answer is "ask," never "guess."* **Don't hand this out before your policy exists.** Every step below resolves against your written data rules, so without them it has nothing to check against and becomes an invitation to improvise. If you're still waiting on sign-off, hand out the interim notice in [getting-approval.md](./getting-approval.md) instead. Work down the list. Stop at the first **STOP**. 1. **Am I in the approved, company account?** No → switch to it, or **STOP**. Personal or free accounts are not approved for company material unless your written policy explicitly says otherwise. 2. **Does what I'd paste identify a real person, or is it confidential, regulated, or under NDA?** (Customer or employee data, health, financial, legal, credentials, unreleased plans.) Yes → go to step 3. No → skip to step 4. 3. **Do our written data rules explicitly allow sanitized material?** Check the policy — don't go from memory or from what seems sensible. Whether removing names makes a record acceptable is an organization-specific call, and in regulated work the answer is often no: de-identified data can frequently be re-identified, so plenty of employers treat a stripped export as still in scope. - **Yes, and it says how** → sanitize exactly the way the rules describe, then continue. - **Yes, but it doesn't say how, or you're unsure it covers this** → **STOP. Ask `[NAME]`.** - **Silent or no** → **STOP. Ask `[NAME]`.** Don't infer permission from the absence of a prohibition. A made-up example with the same *shape* as the real thing — invented names, invented numbers — is a different matter and is always available to you. It's not sanitized real data; it's not real data at all. When you're blocked here, that's usually the way through. 4. **Will the output leave the team or drive a real decision** — something a customer sees, a number in a report, anything consequential? Yes → you may use AI to draft it, but **you verify every fact before it ships** (see the checklist below), and disclose where your audience would reasonably want to know. No → go ahead; a quick sanity-check is enough. 5. **Is this one of the things that stay human?** (Performance feedback, discipline, condolences, a personal apology, anything where the point is that a person spent the time.) Yes → **STOP.** Write it yourself. Still unsure after all five? That uncertainty *is* the answer: **ask `[NAME]` in `[CHANNEL]` before, not after.** Nobody here has ever been in trouble for asking. --- ## 3. Pilot tracker *One page per pilot. The pilot's job is not to prove AI works — you already believe that. Its job is to produce three or four concrete examples from your team's own work that you can show the room later. Fill the top in once; add a check-in line each week; make a call at the end.* **Pilot:** `[SHORT NAME]` **Owner:** `[YOU]` **Window:** `[START DATE]` → `[END DATE]` *(aim for four weeks)* **People:** `[3–5 NAMES — picked for credibility, not enthusiasm]` **Approved tool:** `[TOOL]` · **Data class allowed:** `[e.g. internal, non-identifying only]` **The workflow we're testing:** `[the specific, frequent task]` **Baseline, before we start** *(take this — you can't show improvement without it)*: - Time it takes today: `[e.g. ~90 min/week]` - Current quality / pain: `[what's annoying or slow about it now]` **Hypothesis:** With `[TOOL]`, `[this task]` gets `[faster / better / less tedious]` without losing `[the quality that matters]`. **Success threshold** *(decide now, so you can't move the goalposts later)*: `[e.g. "half the time, and the reviewer can't tell it was AI-assisted"]` **Weekly check-ins** *(individual, and ask to see what's working right now — "how's it going" gets you "fine" from the person who's stuck)*: | Week | Who | What they showed me | Blocked on | Time now | | --- | --- | --- | --- | --- | | 1 | | | | | | 2 | | | | | | 3 | | | | | | 4 | | | | | **Examples worth showing the room** *(the whole point — name the person, the task, the before/after)*: - `[e.g. Maria's Friday report: ~90 min → ~20 min]` - `[…]` **Decision:** ☐ Continue as-is ☐ Change and re-run ☐ Stop **Why:** `[one honest sentence]` --- ## 4. Output-evaluation checklist *The policy says "verify." The maintenance guidance says "spot-check." Neither says how. This is how — for any output someone is about to rely on, and again whenever the model or the prompt changes. Silent, confident, wrong-but-plausible output is the failure mode you're designing against.* **What we're checking:** `[the output — e.g. the weekly customer summary]` **Reviewer:** `[NAME]` · **Date:** `[…]` · **Tool / prompt version:** `[…]` Run it against a few **representative test cases**, not one lucky one — including at least one you know is awkward (missing data, an edge case, an unusual input). For each output, check: - [ ] **Facts are right.** Numbers, names, dates, quotes, and citations trace back to a real source — not just to a confident sentence. These tools invent all of these. - [ ] **Nothing important is missing.** It didn't quietly drop the caveat, the exception, or the one number that changes the decision. - [ ] **Nothing is invented.** No made-up references, people, features, or policies that sound plausible but aren't real. - [ ] **Tone and format fit.** It reads like us and slots into where it's going without a rewrite. - [ ] **No unacceptable failure.** List the specific ways this output must *never* fail — `[e.g. never quotes a price, never names a customer, never states legal advice]` — and confirm none happened. **Test cases run:** | Test case | Facts | Complete | No invention | Tone/format | Verdict | | --- | --- | --- | --- | --- | --- | | `[typical]` | | | | | ☐ pass ☐ fail | | `[awkward / edge]` | | | | | ☐ pass ☐ fail | | `[…]` | | | | | ☐ pass ☐ fail | **Re-test trigger:** re-run this whenever the tool updates or the prompt changes. A prompt tuned to one model version can behave differently after an update — that's not a one-time check. **Cleared for use?** ☐ Yes ☐ Not yet — `[what has to change first]` --- ## 5. Graduation & ownership record *Anything built in a workshop and adopted without an owner becomes the team's problem in six months. Fill one of these in the moment something graduates from experiment to dependency — the moment people start relying on it. If you can't answer these, it isn't ready to be relied on.* **What it is:** `[the prompt / skill / workflow, in one line]` **Owner:** `[ONE PERSON — not a team, not an alias]` **Graduated on:** `[DATE]` - **Who can use it:** `[everyone / this role / named people]` - **Where it lives:** `[link — a shared location, not someone's private chat history]` - **What breaks if it stops working:** `[the real-world consequence]` - **Fallback if it's down or wrong:** `[the manual way to get it done]` - **Sensitive-data constraints:** `[what must never go into it]` - **Escalation contact:** `[who to tell when it misbehaves]` - **Re-check cadence:** `[how often someone spot-checks the output — monthly is a reasonable default for anything load-bearing]` **Single-point-of-failure check:** - [ ] It lives somewhere shared, not in one person's private account. - [ ] **A second person has actually run it, start to finish, successfully.** (Not "could" — has.) `[NAME, DATE]` If either box is empty, it hasn't really graduated — it's one resignation away from being nobody's job. --- ## 6. Leadership update *Your measurement already produces the content. This is the ready-to-send format. The credibility comes from being specific, checkable, and honest about what you haven't measured — that's what makes the ask land.* **To:** `[LEADER]` · **From:** `[YOU]` · **Period:** `[MONTH / QUARTER]` **Where we are:** - **Access vs. use:** `[N]` people have access; `[N]` used it last `[week / month]`. - **What's survived:** `[N]` things were built; `[N]` are still in real use at 30 days. - **Confidence:** team self-rating moved from `[X]` to `[Y]` on our five-question survey (1–5). **The clearest single result** *(one real, named, checkable example beats any aggregate)*: > `[NAME]`'s `[TASK]` took about `[BEFORE]` and now takes about > `[AFTER]` — their estimate. **The honest caveat** *(say this before someone else does)*: > We have **not** tried to measure aggregate productivity, and I'd be > skeptical of anyone who claims to. Time saved on a task isn't the > same as time returned to the business. What we're reporting is > adoption and concrete examples, not a bottom-line number. **What we need next:** `[the specific ask — budget, a decision, air cover, more seats]`. *Specific, checkable, and honest is what makes the next ask credible. Inflate one number and the first person who checks discredits the whole effort — including the parts that genuinely worked.* --- ## Notes for whoever is filling these in *Not part of the templates — delete before handing them out.* - **Take a baseline before anything launches.** Every one of these leans on a "before" number. You can't recover one after the fact. - **Name real people, not roles**, wherever a template asks for an owner, a reviewer, or someone to ask. The whole mechanism depends on there being someone obvious. - **These are the operating half of the toolkit.** The reasoning behind them is in the full playbook: pilots and use cases in [managers-toolkit.md](./managers-toolkit.md), the hard-line rules in [ai-policy-template.md](./ai-policy-template.md), the workshop where your team fills several of these in for real in [ai-workshop.md](./ai-workshop.md). - **If a blank template is hard to start,** open [worked-example.md](./worked-example.md) next to it and fill yours in alongside. Copying the level of detail is the point — a scoring sheet whose candidates say "reporting" instead of "the Monday claims-status report for the VP" won't discriminate between them.