AI makes Excel faster. It doesn't make Excel governed.

Let's be fair about what these tools do well. They write formulas. They untangle someone else's workbook. They clean data and build model scaffolding fast, and that is real time back in your week.

What they don't do is fix the reason the workbook was wrong in the first place.

The numbers came from a copy-paste of a data dump that was stale the moment it landed — and every planner's file disagrees with every other planner's file.

That's the disease. AI makes Excel work faster; it doesn't make Excel data governed. Planners live in Excel. The data they need lives somewhere Excel can't reach. Speeding up the copy-paste doesn't close that gap, it just gets you to the wrong number sooner.

So I closed it

I built an assortment unit plan in Claude Code that uses Excel as the working plan and connects straight to the database. Real live data, full history, no exports, no stale pulls.

Size scales and curves build in the sheet and write back to the database.
Committed placeholder buys generate and append straight to the on-order table — the purchase order table, for the non-database folk.
Assortment choice count and tops-down reconciliation right out of the gate.
New choices get a code the moment you type the description.

Excel is just the portal. No version roulette. No corrupt file at 11pm the night before market.

Step 01 · the build

Claude Code

Asked in plain English. A CLAUDE.md ruleset the request is filtered through, so it edits the workbook — never rebuilds it from scratch. The Excel work runs as VBScript through cscript.

new_plan.vbs
agent_refresh.vbs
agent_append_po.vbs

Rebuildable on demand. The template is code, not a file someone saved.

generates

The portal

What the planner opens

Excel planning workbook

Refresh pulls real sales, inventory and on-order. Planners forecast in the cells they already know. Save writes the plan back.

ChoiceUnits soldOn handFcst units

Core Tee / Black4,1801,9055,250

Merino Crew / Navy1,7426122,400

Tech Short / Slate98601,880

Read columns come from the database on refresh. Nobody types them.

Write columns are the planner's. They post back on save.

pull write back

System of record

SQL database

Every plan version, forecast and placeholder PO stored with who saved it and when.

sales$
inv_wk$
otb_snapshot_line
inbound$

Validated on write. Versioned, not overwritten.

Your inputs survive

Refresh the data. Rebuild the tabs.

Everything you typed is matched by category and month, not by where it sat. The data lives in SQL, keyed — not trapped in a spreadsheet.

Every version is kept

Last month's plan is still there.

Plans save as named snapshots — “Aug Final”, not “final_v3_USE_THIS” — each stamped with who saved it and when. A duplicate name is refused rather than quietly overwritten.

One set of numbers

The plan lives outside the file.

Because the plan is in the database, finance and BI read the same forecast the planner just saved — no export, no reconciliation.

The workbook shown is illustrative. Figures are from SMP’s own demonstration dataset — no client data.

See it running

This is the plan being built end to end, on live data, in the tool a planner already knows how to open.

There are more walkthroughs — the data layer underneath it, size curves, the forecast tooling — over on the demos page.

Recognize your own workbook in this?

If your planners are rebuilding the same file every season from a dump that's already out of date, that's a fixable problem and it's most of what I do.

Book a 30-minute call

← All insights