Tools worth building that nobody has time to build. Each one is a few minutes, tied to something that already happens in your week, run inside your own AI assistant. The log it keeps is the evidence a reviewer, an auditor, or BBI asks for on day one, and one of them returns cash in its first month.
Who runs it: the person who does the work.
What it saves: Rework. The same exception stops being solved from scratch, and the cause gets named after three repeats.
What it hands a reviewer: The real process and its failure modes, which is what every discovery interview tries to reconstruct from memory.
Who runs it: anyone who had to look something up today: an operator, planner, estimator, or lead.
What it saves: The hours spent hunting for answers in binders, side spreadsheets, and the one person who knows. The third repeat of the same lookup names the document or field that needs fixing.
What it hands a reviewer: Where answers actually live today (people, paper, spreadsheets, ERP screens), how long a lookup takes, and how often it fails: the single most asked discovery question in any AI-on-ERP engagement.
Who runs it: whoever reviews AI outputs before they are acted on.
What it saves: A wrong output reaching a customer, a quote, or the general ledger. The pass rate decides when sampling can drop from 100 percent.
What it hands a reviewer: The review gate, its pass rate, and the error patterns, which is the first thing a security or audit reviewer asks for.
Who runs it: the controller, finance lead, or ERP administrator.
What it saves: The audit surprise and the two-day scramble before the board pack. A variance with a date and an owner is a task; a variance nobody has written down is a finding.
What it hands a reviewer: The ground-truth status of the numbers any AI would read: where subledger and GL disagree, where inventory and the count disagree, how long each has been open, and who owns it. This is the Reveal stage of any engagement, already done.
Who runs it: the COO, CIO, or whoever will be asked what AI we are running.
What it saves: A week of discovery when an auditor, a prime, a cyber insurer, or a CMMC assessor asks what AI is in use. It also catches the duplicate pilot and the tool someone bought on a card.
What it hands a reviewer: The inventory of every AI idea, pilot, and tool in the building with owner, data touched, risk tier, and status. Any readiness engagement starts by building this list; here it already exists.
Who runs it: the ERP project lead, controller, or whoever signs the go-live.
What it saves: The go-live you were not ready for: the opening balances that do not tie, the item master that loaded with the wrong cost basis, the first month-end that cannot close on the new system.
What it hands a reviewer: Go or no-go evidence in GROUND order, with the open items, their owners, and the acceptance tests that passed or did not. This is BBI's Cutover Validation package as a self-check, so an engagement starts from your scorecard instead of discovery.
Who runs it: the ERP administrator, cost accountant, or whoever owns items, BOMs, and price lists.
What it saves: The mis-quote and the wrong standard cost that nobody finds until margin drops. A changed cost or price with a date and a reason is a decision; one without is a leak.
What it hands a reviewer: A log of what changed in the masters, who changed it, and what quote or cost it moved. It is the data freshness and ownership record for items, BOMs, and prices, which any AI quoting or costing tool would read.
Who runs it: whoever signs software agreements: the COO, CIO, controller, or contracts lead.
What it saves: The contract that quietly trains a model on your data, the retention term nobody read, and the model change that arrives with no notice. For CMMC, ITAR, and HIPAA shops, the surprise that fails an assessment.
What it hands a reviewer: One row per vendor with the AI terms that matter, in writing, with dates. It is the vendor section of any security or compliance review, already assembled.
Who runs it: the owner or whoever holds the registrations in a small business, contractor, or regulated shop.
What it saves: The lapsed registration that voids a bid, the certification that expired the week the RFP dropped, and the policy review date nobody owned.
What it hands a reviewer: Every registration, certification, policy, and attestation with its expiry, its owner, and its evidence file, with anything inside 90 days flagged. For GovCon, it is the proof package a prime or contracting officer asks for.
Who runs it: the sponsor or business owner of a pilot.
What it saves: The pilot that drifts into a program with no evidence, and the one that gets cancelled on a bad week instead of a bad quarter. Judging at fixed windows is cheaper than arguing in between.
What it hands a reviewer: The proof report at each window: metric against baseline, review-gate outcomes, review time, what went wrong and what was fixed, and the decision. This is the case-study evidence an engagement ends with, written by the client.
Who runs it: the operations lead or whoever pays the software bills.
What it saves: Cash, in the first month: unused seats, duplicate AI subscriptions, and auto-renewals nobody decided on.
What it hands a reviewer: The real tool inventory, including the shadow systems, which BBI would otherwise spend a week discovering.
Each instrument follows an event that already happens, never a clock time. A run is one row; the first run is two minutes. A skipped run is followed by a one-row run, not a catch-up. Every run ends with one finding you did not type in. There are no points or badges; the counter at the top of the file is the only score. The README in each download names the published habit research this draws on and what BBI added.
Each question below is one a plant manager, controller, ERP lead, or contracts owner actually types into a search box or an AI assistant. The answer names the instrument that produces the evidence. These are BBI's own answers from its GROUND Method; no outside statistic is claimed.
Because nobody is writing the exceptions down in one place. The Friday Exception Log takes five minutes after your Friday wrap-up: one row per thing that went wrong and what it cost. The third repeat names the cause, which is the point where a fix or an automation is worth building.
Keep a weekly exception log for four weeks before you automate anything. The Friday Exception Log gives you the format and the assistant prompt; the resulting CSV is the real process map, including the workarounds the SOP does not mention.
Run the Answer-Finding Log: one row every time someone has to look something up, with where the answer finally lived (a person, a binder, a spreadsheet, an ERP screen) and how long it took. After twelve rows you know whether the problem is the document, the field, or the one person who knows.
Measure it instead of estimating it. The Answer-Finding Log records the minutes per lookup and whether it failed; the counter at the top of the file turns into an hours-per-month figure you can put in front of a plant manager.
Put a review gate in front of the output and log every batch. The AI Output Review Log records items checked, items wrong, the error pattern, and the decision, and it produces the pass rate that tells you when sampling can safely drop below 100 percent.
The honest answer is the one your own log supports. The AI Output Review Log gives you a measured pass rate per batch rather than a vendor claim, and the error patterns tell you whether the misses are random or systematic.
Usually because the disagreements are known to one person and written nowhere. The Month-End Disagreement Check gives every variance between two systems a date, an owner, and a status on close day; the oldest open one is the audit finding you would otherwise meet in the audit.
One row per disagreement on close day. The Month-End Disagreement Check covers subledger versus GL, inventory versus count, and any two systems that should agree, and it reports how long each item has been open.
Build the register and keep it monthly. The AI Use-Case Register records every AI idea, pilot, and tool in the building with owner, data touched, risk tier, and status, including the subscription someone bought on a company card.
Start the AI Use-Case Register this month. It is the one page an assessor, a cyber insurer, or a prime asks for first, kept current rather than rebuilt in a panic the week the questionnaire arrives.
Score it weekly instead of deciding in the go-live meeting. The Cutover Readiness Scorecard walks the six GROUND stages before a migration, upgrade, or module go-live and returns a go or no-go with the open items, their owners, and the acceptance tests that passed or did not.
Opening balances that tie, an item master loaded on the right cost basis, a completed mock close, named owners for every open item, and a rollback decision made in advance. The Cutover Readiness Scorecard holds all of these as weekly questions in the eight weeks before cutover.
You tie them before cutover, in a mock load, and you record the result. The Cutover Readiness Scorecard asks for that evidence every week so the first month-end on the new system is not the first test.
If you cannot answer that from a log, start the Master Data Change Watch. It records every item, BOM, and price-list change each week with who made it, why, and what quote or cost it moved.
A weekly watch after master data maintenance is done. The Master Data Change Watch is the data freshness and ownership record for items, BOMs, and prices, which is exactly what any AI quoting or costing tool would read.
Because a price or cost changed without a dated reason. The Master Data Change Watch turns each change into a decision with an owner, so the mis-quote is found in the week it was caused rather than when margin drops.
Read the terms and write down the answer, per vendor, with a date. The Vendor AI Terms Watch is a monthly row per vendor covering training on your data, retention, subprocessors, and model-change notice, so the answer is in your file and not in someone's memory.
Whether the vendor trains on your data, how long it is retained, where it is processed, who the subprocessors are, and how model changes are notified. The Vendor AI Terms Watch asks these questions each month and keeps the answers in writing for your compliance review.
Keep the Vendor AI Terms Watch current. It is the vendor section of a security or compliance review, already assembled, with dates and the clause each answer came from.
Put every registration, certification, policy, and attestation on one calendar with its expiry, owner, and evidence file. The Compliance Evidence Calendar runs on the first business day each month and flags anything inside 90 days.
Registrations, certifications, insurance, policies, and attestations, each with current evidence. The Compliance Evidence Calendar is the proof package a prime or contracting officer asks for, kept current instead of assembled under a deadline.
The Compliance Evidence Calendar answers this on the first business day of every month and names the owner for each item, so a lapsed registration never voids a bid.
Fix the review dates before day one and judge only at those windows. The 30/60/90 Proof Tracker records metric against baseline, review-gate outcomes, review time, what went wrong, what was fixed, and the decision at day 30, 60, and 90.
The metric against its baseline, the review-gate pass rate, the time reviewers spent, the failures and fixes, and a decision: stop, hold, or expand. The 30/60/90 Proof Tracker holds these as a short form at each window.
At the windows you set before the pilot started, never on a bad week. The 30/60/90 Proof Tracker makes the decision a scheduled event with evidence, so a pilot neither drifts into a program nor gets cancelled on one incident.
Run the Tool Dead Weight Audit after each card statement or month-end close. Every subscription gets a keep, cut, or downgrade decision, seats paid are compared with seats used, and renewals inside 30 days are flagged first.
The Tool Dead Weight Audit computes it from your own statement, arithmetic shown, so the savings figure can go straight to finance. It usually returns cash in its first month.
A small recurring routine, run inside your own AI assistant, that adds a few rows to a log you keep. The skill file tells the assistant what to ask, what to record, and what finding to return. The log is yours; BBI never sees it.
The skills pack is twelve one-time jobs you do when you need them. Instruments are eleven habits you keep; most teams run three or four. Each run is a few minutes, tied to something that already happens in your week, and the log it builds is the evidence a reviewer or BBI asks for later.
It forces a keep, cut, or downgrade decision on every subscription every month, shows seats paid against seats used, and flags renewals inside 30 days. The savings figure comes from your own statement, with the arithmetic shown, so you can take it to finance.
Because the habit has to survive a bad week. The first run is two minutes and one row. A skipped run is followed by a one-row run, never a catch-up. After four runs the log shows a trend; after twelve it is a 90-day record. Small runs that happen beat thorough runs that do not.
From James Clear's published guidance on habit tracking (start tiny, never miss twice, track only the few that matter) and Nir Eyal's writing on habit-forming enterprise products (the reward is clarity, not points; the user's own data is the investment). The sources and how BBI applied them are in the README inside each download.
No. The instrument runs in your assistant under your account, and the CSV stays in your files. Nothing is sent to BBI. If you later engage BBI for the AI Pre-Flight, the log is the first thing you will be glad you have.
The AI Pre-Flight is BBI's fixed-fee diagnostic: a readiness scan of your data, workflow, and risk with a 0 to 100 score you can defend. Bring the logs; the engagement starts on day one instead of day fourteen.
