One day on the factory floor at Bliss Aerospace
A precision components manufacturer with twenty thousand parts and no single screen to plan them on. We built that screen in an afternoon.
Bliss Aerospace makes precision-machined fasteners — nuts, bolts, screws, washers — across a catalogue of roughly twenty thousand SKUs. Every part moves through a long sequence of operations on the shop floor, sometimes seventeen or eighteen steps, sometimes back through the same machine more than once. The order of those steps matters. The timing of each one depends on the machine, the cycle, and the part.
The planning for all of this lived where it lives in most serious manufacturing companies: in spreadsheets, accounting software, and the heads of the people who have run the floor for years. An earlier attempt to fit a large off-the-shelf ERP to the business hadn't taken — the system couldn't bend to how the factory actually worked. What the team needed wasn't another rigid platform. It was a clear, single view of production planning that matched their own logic: monthly planning with daily agility, hundreds of line items a day, parts flowing across processes, billing closing every month.
So that was the scope for the day. Not a strategy deck, not a roadmap — one working dashboard for planning the movement of SKUs across the floor, at a yearly, monthly and daily resolution, built on their machine, with their data, owned by them from the first minute.
01What we did in the room
The day ran the way these days are meant to run. A round of introductions and genuine need-finding to understand how the factory actually plans — not how it's supposed to on paper. A short, deliberately non-technical explanation of how I use AI day to day. Then guided building, with the leadership person who knows the floor sitting beside me the whole time, and the other departments — production, sales, stores and quality, accounts — working in parallel.
The single most useful thing we did took five minutes and no software. I asked everyone in the room to name the one document that is the source of truth for their role. The answers converged, almost immediately, on a single Excel sheet. That sheet was the backbone of the whole operation — which meant it was also the exact thing the dashboard had to absorb and outperform. Everything after that had a target.
An early, easy win: people who had never touched AI before ran Copilot directly on that sheet and pulled out insights from data they already owned. The buy-in was instant. You could see it land.
One document, found fast
Asking everyone for the single most important document in their role converged the room on one Excel sheet. That sheet was the backbone of the dashboard and the bar it had to clear. Letting AI-newcomers run Copilot on their own sheet produced instant, visible buy-in — the easiest win of the day.
The skeptic who ran over time
Someone walked in saying their use case probably wasn't relevant for AI — a position they'd held even when the directors suggested otherwise. By the show-and-tell they were grinning and presenting for twice their allotted slot. Turning a skeptic is the most satisfying thing that happens in these rooms, and it happens more often than people expect.
Age was no barrier
I came in quietly worried that the younger team would be excited while older leadership stayed unconvinced. Wrong. Once the leadership here saw concrete value, they were genuinely open to trying the tool. Openness tracks with seeing something work, not with age.
Show value in the first hour
I'd planned to reveal the dashboard I'd built for them just before lunch. I showed it within the first hour instead, right after intros and need-finding. Dangling the carrot of what's possible early is what earns you everyone's attention for the slower work that follows.
Setup and debugging — leave it to the end
Permissions and debugging probably needed another thirty minutes. But doing it after the room has seen what's possible and decided what they'd use it for is what makes the slog worth it. This is genuinely harder in companies without a strong technical person to handle access. For the next iterations I want to send a junior person ahead of time — likely on the day I do the recce factory visit — to set up permissions and install the software needed on everyone's machines in advance. I think that one step alone could remove ninety percent of the friction and let us hit the ground running.
The ending needs a stronger landing
Everyone got so excited presenting what they'd made that we ran out of time — a good problem, but a problem. The room was buzzing and happy after show-and-tell, but the final punch — the close that gives you chills and ties every lesson together — wasn't there yet. The fix is to get the room seated again at the end for a proper run-through of the day's learnings and a clear nudge to keep building. The next session gets a modified format to do exactly this.
Group work versus individual instinct
Of three teams, only one actually worked as a team. The others defaulted to their own projects on their own laptops. Open question for the format: enforce collaboration harder, or let people follow the instinct that's clearly there?
People want the "how it works" part
The how-AI-works section is short by design — this is a build session, not a technical course. But the appetite for it was real. A candidate fix: an optional deeper module during lunch or one of the breakouts, for those who want it, without taxing the people who don't.
Tight scope worked — add a time study
Scoping the day to a single project gave us an achievable finish line and kept everyone focused; that stays. What I want to add is one section: a wider study of each person's actual day, with AI then suggesting tools to automate each part — likely as an individual activity with Claude.
The dashboard lives on their machine, with their keys and their data. They can extend it, customize it, and pay for the APIs directly — no vendor in the middle. That was the point from minute one. Teaching the team to fish, not selling them fish.