Boat assembly tracking without the paper chase
Agent Stories are fictional scenarios inspired by client projects we’ve delivered. The businesses, people, data and workflows shown are independently created illustrations. Our clients’ systems belong to them, so we keep their actual systems, private data and proprietary implementation details confidential.
Picture a small boat assembly shop on the North Carolina coast. It takes a finished hull and fits the console, controls, wiring and equipment that make a customer's boat ready for the water.
Inside the workshop, each build moves on a paper job sheet. One team finishes its part and hands the paperwork to the next. When a customer asks how their boat is coming along, the production manager has to walk the floor to find out.
Here's the short version of how we'd approach it: one build record, a clear owner at every step, and customer updates the team can trust. The rest of this story covers what that would look like and where the automation stops.
Why the paper chase costs more than time
A paper job sheet only knows where it is right now. It doesn't tell anyone what's waiting, what's blocked or who has it.
So the production manager rebuilds the status by hand every time someone asks. That means finding the sheet, checking with the station, and working out whether the work is really done or just nearly done. It's real effort, and it pulls the manager away from running the floor.
The customer feels it too. They wait for an answer, or they follow up, and each follow-up starts another walk around the shop. Nobody is doing anything wrong. The build just has no single place where its status lives.
What one build record holds
The fix starts with deciding what belongs together. For each boat, one digital build record would hold:
The boat specification, so every station works from the same details.
The assigned work for each station, from console and controls to wiring and equipment.
The responsible team member, so each task has a named owner.
Station progress, showing what's done, what's in progress and what's waiting.
The customer contact, so updates go to the right person.
If any of these is missing, the build isn't ready to move to the next station, and that's useful to know right away rather than at pickup.
The proposed stack
This is a proposed design, not a system we deployed. Each tool would have one job:
Airtable would hold the build records and give each station its own work queue. It would also track task ownership and quality checks and give the manager a production overview.
Make would connect approved milestones to customer updates. It would route each milestone, check that the right approval is in place, and queue the customer message.
Microsoft Outlook would send those customer emails from the shop's mailbox, so customers hear from the shop they already know.
Put together, the flow would look like this. Stations record their work on the build record in Airtable. When a milestone is complete or the manager approves a message, Make picks it up and sends the customer update through Outlook.
One honest detail: Make's standard Airtable trigger checks for changes on a schedule, so updates would go out on a regular cycle rather than the instant a box is ticked. That's usually fine for a customer email, and a real build could make it faster if needed.
What technicians and stations would see
A technician would sign in, open the assigned task and record its completion. There's no hunting for a sheet and no guessing which build is next.
The build would only move forward when its required work is complete. That way, the next station never starts on a boat that isn't ready for it.
The manager would see the whole floor at once: what's active, what's waiting and what needs attention. Answering a customer question becomes a matter of opening the record, not walking the floor.
If you're wondering how each station would see only its own queue, our guide to Airtable sharing levels explains how interfaces give people scoped access without opening up the whole base.
When a part is missing, people decide
Delays happen. A missing part can hold up a build for days, and that's exactly when a customer update matters most and is easiest to get wrong.
In this design, the team would flag the hold-up on the build record. The manager would review the revised timing and approve the customer message before it goes out. Make would only send it after that approval.
Automation prepares the update. A person decides what the customer hears.
Quality stays with the people doing the work
Quality checks would stay with the technicians who know the work. A failed check would send the task back for rework, and the build would stay where it is until that work is done.
Only a final quality sign-off would make the boat ready for pickup. That sign-off is what would trigger the pickup notice to the customer, so nobody gets told their boat is ready before it really is.
What a real build would still need to check
A design like this is a starting point, not a finished system. A real version would still need careful decisions about:
Who can edit and who can only view each station's queue.
A dependable approval gate in front of every customer email.
What happens if an email fails to send or has to retry.
Keeping each customer's details out of every other customer's messages.
Whether and how parts and inventory data should connect to the build record.
Those details depend on the shop, and we'd work through them before building anything. If linked records are new to you, our beginner's guide to an Airtable project tracker shows the same idea in a simpler setting.
Where does your production process get stuck?
Think about the last time a customer asked for a status update. Was the answer hard to give because the work was behind, or because nobody could see where the work was? If it was the second, that's the part a clearer workflow can address.
Let's build a clearer workflow.
Comments