QR Codes, Airtable, and ChatGPT: Reorganising 400 Storage Slots

Most asset tracking projects fail at the same point. The database is fine, the fields are sensible, the automations work — and then somebody has to walk out into a physical yard and reconcile 400 real objects against 400 rows. That is where spreadsheets quietly die.

This tutorial covers a system built for a local sailing club that solves both halves of that problem. The first half is the boring, durable part: QR stickers on every boat, Airtable interfaces for the people on the ground, linked records tying boats to owners, and monthly storage fees that calculate themselves. The second half is the experiment: connecting ChatGPT directly to the base and asking it to reorganise the entire storage yard — splitting compound location records, allocating boats by member activity and hull type, and producing a printable moving plan for the volunteers who have to physically shift them.

Video Tutorial

What is in the video

• 0:33 — The base structure: members, boats, boat types, fees, and QR codes
• 1:56 — Generating and printing QR stickers with an Airtable extension
• 2:38 — Scanning a sticker and landing in the interface
• 2:46 — The data problem: three rack slots crammed into one record
• 3:16 — Connecting ChatGPT to Airtable and the first restructuring prompt
• 4:42 — Filling the gaps in the location numbering
• 5:22 — The allocation rules: sheds, hull types, and member activity
• 6:38 — Catamarans getting three adjacent slots
• 8:19 — The result: 100% of racks filled, 43 boats on the lawn
• 9:08 — The printable moving sheet

Key Takeaways

• Pre-print your codes. Generate and print a batch of QR stickers before you need them, each already a row in the base. Assigning a sticker to a new asset then takes seconds instead of a print run.
• Encode a URL, not an ID. The QR code points at an Airtable interface, so a phone camera replaces the mobile app you would otherwise build. Choose the sharing mode deliberately: a public link opens with no login but is read-only and exposes everything the page shows, while write-back requires a signed-in account with editor permission.
• One physical slot, one row. A rack entry covering three positions, stored as A/B/C in a single cell, breaks every occupancy count, allocation rule, and fee calculation you build on top of it.
• Let the model restructure, not just answer. Connected to the base, ChatGPT split compound records, created missing rows, added a field, and rewrote hundreds of assignments — work that is hours of manual editing.
• Stage the output in a new field. Writing the proposed allocation to a separate New location field keeps the current state intact and turns the AI pass into a proposal you approve rather than a change you discover.
• Expect iterations. The first allocation was not the final one. Gaps, absent members, and under-filled racks each needed a correction round before the plan held.

The System That Was Already Running

Before any AI gets involved, there is a working base. Five tables carry it.

Two details in that structure do a lot of work later.

The first is that boat names include the owner's ID. It looks redundant next to a linked record field, but it means a boat is identifiable from its name alone — on a printed list, in a message between volunteers, on a sticker read at arm's length in the rain. Systems that live partly on paper benefit from human-readable keys.

The second is that boat type is a field rather than an assumption. A catamaran, a standard monohull, and a monohull that has to be stored with its mast up are three different storage footprints. Because that distinction is captured as data, it can later be handed to an allocation process as a rule. Had it lived in someone's head, the reorganisation in part two would have been impossible to delegate.

How the QR Code Layer Works

Codes are printed before they are needed

The club generates QR codes in batches and prints the stickers in advance. Each printed code already exists as a row in the QR codes table, unassigned.

When a new boat arrives, whoever is registering it peels off any free sticker, puts it on the hull, and links that code to the new boat record. The code table shows immediately which stickers already carry a serial number and which are still available.

This inverts the usual order of operations, and it is the single most practical decision in the build. Generating a code per asset on demand means a print job every time someone joins the club. A roll of pre-printed stickers means registration happens at the rack, in a minute, by a volunteer.

The codes are generated by an extension

The QR images come from a QR code generator extension from the Airtable marketplace — the paid version, which costs a few dollars. It reads a URL field and renders it as a QR code, either for a single record or in bulk across the whole table.

Bulk generation is what makes the pre-printing workflow viable: select the range, generate every code at once, export, print. If you are new to the extension layer, our guide on using Airtable extensions covers how they are installed and where they run.

There is also a native option. Airtable has a barcode field type that can hold scanned values directly, which we cover in the barcode and QR code system guide. The extension route was chosen here because the goal was not to store a scanned value — it was to produce a printable image that resolves to a live interface.

The code encodes an interface URL

This is the part worth copying. The QR code does not encode a record ID or a SKU. It encodes a URL pointing at an Airtable interface.

Scan the sticker with a phone camera and the interface opens on the boat, its owner, its storage location, and its fee status — without anyone knowing what a base is, and without anyone building a mobile app.

How you share that interface is a decision to make deliberately, because it sets both who can see the data and whether a scan can change anything:

• Shared publicly. Anyone who scans opens the interface with no login, which is the frictionless option. The trade-off is real: the URL is the only thing protecting the page, so owner names, storage locations, and fee status are visible to anyone who scans a sticker or is sent the link. A publicly shared interface is read-only — nobody updates a record this way.
• Restricted to collaborators. The person scanning has to be signed in to an Airtable account with access to the interface, and needs editor permission before the page will accept an edit. This is the only mode in which a scan can write back — logging a move, marking a fee paid, flagging damage.

For a club yard where members mostly look up their own boat, the public link is usually the right call, with the interface filtered down to fields nobody minds being seen. The moment you want scans to update records, you are in account-and-permission territory, and the login stops being optional.

That is the whole user experience for the people who are not administrators. A sticker and a camera.

For teams that need the reverse flow — a scanner inside the interface that looks records up rather than a code that opens one — the QR code scanning interface tutorial covers the custom extension approach.

Storage fees fall out of the same data

Because boats are linked to members and carry a fee type, the monthly storage charge is a calculation rather than an admin job. Fee categories sit in their own table, each boat points at one, and billing rolls up from there.

This is the quiet argument for putting a physical yard into a relational base at all. The QR codes are the visible feature. The fact that nobody assembles the monthly invoice list by hand is the one that saves recurring time. Our guide to lookup fields covers the mechanics of pulling linked values into the record where you need them.

The Data Problem the Scans Exposed

Scanning a sticker in the yard surfaced a flaw that had been invisible in the grid.

Catamarans are wider than a single rack position, so each one occupies three. In the base, that was recorded by putting three slot references into one cell, separated by slashes — one row claiming to be one location while physically being three.

Every cell like that quietly breaks the system:

• Counting is wrong. The location table reports fewer positions than the yard actually has.
• Occupancy is unknowable. You cannot compute free space when one row means one slot in some places and three in others.
• Allocation cannot be automated. Any process that assigns boats to slots has to parse text to know what a row means.
• Scanning returns a mush. Scan the sticker on a catamaran and you get a compound string rather than a position.

The fix is structural: one physical slot, one row. Doing that by hand across hundreds of records — while keeping every QR code linked to the right position — is a long, error-prone afternoon. That is the job handed to ChatGPT.

Part Two: Connecting ChatGPT to the Base

Airtable is available inside ChatGPT as a connected app. You add it, authorise it, and configure it against a specific base. From then on ChatGPT can read the schema, query records, create records, add fields, and update values in that base directly.

This is the same shape of integration as an MCP server: the model is given tools that act on live data rather than a description of it. If the concept is new, start with what MCP means for Airtable and the Airtable MCP server explainer. For how far this goes — building interfaces and automations from a prompt — see Airtable MCP just overtook the Airtable API. If you use Claude rather than ChatGPT, the same pattern applies — see Claude MCP building Airtable bases and our Claude vs ChatGPT for Airtable comparison.

One thing to be clear about: this is not a chat that tells you how to fix your data. It fixes your data. Everything below happened in the live base while the video was recording.

Step 1: Split compound locations into one row per slot

The first prompt describes the table, the defect, and the required end state:

In the connected Airtable you have a Location table. On the Location table we have storage racks for boats, and some of the rows have multiple racks in them. So instead of being the address of a single location, some of them contain three locations, using a slash. Break them down into multiple lines and keep the QR codes linked to them.

Three things make that prompt work, and they generalise to any restructuring task:

1. It names the table and the field. No guessing which of five tables is meant.
2. It describes the defect concretely — a slash separating three addresses in one cell — rather than saying "clean up the locations".
3. It states the constraint that must survive the operation. Keeping the QR codes linked is the requirement that turns a destructive split into a safe one.

ChatGPT worked through the table and created the additional location rows. Sorting the result showed the same boat correctly occupying two or three consecutive positions instead of one overloaded row.

Step 2: Fill the gaps in the numbering

The split left holes. Some rack numbers that exist in the yard had never been entered, so the sequence had gaps — location 024 simply was not there.

A second instruction asked for the missing positions to be created so the table matched the physical numbering. The location table grew past 400 rows, and for the first time the database contained every slot the club actually owns.

That is worth stating plainly: the yard had more storage positions than the system knew about. Restructuring did not just tidy the data, it found capacity.

Step 3: Add a staging field before moving anything

Next came a new field on the QR codes table: New location.

This is the safeguard that makes the rest of the exercise sane. The AI writes its proposed assignment into New location while the current position stays untouched in the existing field. Nothing about where a boat is today is destroyed by a proposal about where it should go tomorrow.

It also produces exactly the artefact the club needs: a before-and-after pair on every row, which is what a moving plan is made of.

If you are going to copy one habit from this entire tutorial, copy this one. When AI is reassigning values, let it write to a new field rather than over the live one. That applies to the allocation work in the next two steps, not to the structural writes in Steps 1 and 2 — splitting a record into three or creating missing rows changes the table itself, and no staging field can hold that. Those operations are covered by the other safeguard: take a base snapshot before you start, using one of the options in our Airtable backup guide.

Step 4: Give it the allocation rules

With clean locations and a staging field, the real task begins. The rules were given in plain language:

In Sheds 1 and 2 we want to put the boats of the users who most frequently come to the club. We can only put their monohulls — ILCA monohulls. We cannot put their monohull mast-up boats, because they are too big. So pick only the monohull ILCA and catamarans. For a catamaran we need three locations, so one catamaran needs to be assigned to three locations, and a monohull needs to be assigned to one location.

Read that again as a specification and notice what it contains: a priority signal (member frequency), a hard physical constraint (mast-up boats do not fit in the sheds), an eligibility filter (which hull types belong in this zone), and a sizing rule (three slots versus one).

To make the priority signal available, a lookup field for member activity was added to the boats table, so each boat carries its owner's attendance frequency and the comparison can be checked by a human afterwards.

ChatGPT identified the qualifying boats and started rewriting rack assignments. Catamarans came back with three consecutive positions each — 25, 26, 27 — which is the correct interpretation of a spatial rule expressed in one sentence.

Step 5: Allocate everything else progressively

The second allocation pass covered the rest of the yard: assign every remaining boat, filling the closest racks first and pushing less frequently used boats further back.

It excluded some categories on its own — kayaks and Optimists were left out of the rack allocation, which was the right call, since those are stored differently.

It also under-filled. A follow-up correction — why are there so many boats on this rack, make sure it uses all the space — pushed it to pack the racks properly.

After several rounds: 100% of racks filled, with roughly 43 boats moved to the lawn. Spot-checking the result showed boats ordered broadly by owner activity, with frequent members near the front and once-or-twice-a-season members further back. Which is precisely the outcome the club wanted and could not easily produce by hand.

Step 6: Ask for the moving sheet

The final prompt is the one that turns a database update into an operation people can actually execute:

Create a moving sheet that describes how we should move the boats from their current location to their new location, and give it as a document file we can print out and follow.

The document that came back is a genuine work plan:

• Data to verify first — the assumptions the plan rests on
• Boats not to move — anything already in the right place
• Sequenced batches — clearing racks before filling them, because you cannot move a boat into an occupied slot
• Temporary staging — one boat parked on the lawn to break a dependency cycle
• Per-boat instructions — from current location to new location
• Verification checks at the end

That sequencing detail is the part worth noticing. Reallocating a full yard is not a list of moves, it is an ordering problem, and the model handled it as one without being told to. Some boats move from good positions to worse ones, some the reverse, and the batches are arranged so each destination is empty when its boat arrives.

What Worked, and What Needed Correcting

An honest summary, because the useful lesson is in the failures as much as the successes.

Worked well:

• Splitting compound location records while preserving the QR code links
• Creating missing location rows to match the physical numbering
• Creating a new field on request and writing proposed assignments into it
• Applying the three-slots-per-catamaran rule with consecutive positions
• Excluding asset categories that did not belong in the rack allocation
• Producing a sequenced, printable moving plan including temporary staging

Needed correction:

• The first split left gaps in the numbering, fixed by a follow-up prompt
• Boats belonging to members marked absent were included in the prime-position allocation, because an absent member might still theoretically use a boat. A data ambiguity, not a reasoning error — but you only find it by looking
• The first full allocation under-filled the racks and had to be pushed to use all available space
• Some slots were assigned two locations where three were required, caught by inspection

The pattern is consistent: the model is excellent at the restructuring work and needs supervision on the judgement calls. Every correction above was found by a person looking at the result and asking why a number seemed off. None of them would have been caught by trusting the output.

The Prompting Patterns Worth Reusing

Five habits carried this session, and they transfer to any base.

Name the table and the field. "The Location table" beats "the locations". Connected models can read your schema, but ambiguity is where wrong tables get edited.

Describe the defect, not the goal. "Some rows contain three addresses separated by a slash" gives the model something to detect. "Clean up the locations" does not.

State what must survive. "Keep the QR codes linked to them" is the difference between a restructure and a data loss event. Every destructive operation should carry one of these.

Give constraints as rules with numbers. "A catamaran needs three locations, a monohull needs one" is executable. "Catamarans are bigger" is not.

Correct in small steps. Every good outcome here came from a follow-up: fill the gaps, use all the space, why is this boat here. Treat the first output as a draft.

Should You Let AI Write to Your Production Base?

Not without the three safeguards this build used.

Write to a staging field. For anything that reassigns values, the New location pattern keeps the proposal and the current state side by side, so a human approves the switch. Structural edits — splitting records, creating rows, adding fields — cannot be staged this way, which is what the snapshot below is for.

Snapshot before you start. Airtable keeps revision history, but restoring a snapshot is faster than undoing a few hundred scattered edits. Take one before any bulk operation.

Scope the connector. Point it at one base, not the workspace. The model should not be able to reach tables that are not part of the task.

For a first attempt, duplicate the base and let the model work on the copy. It costs nothing, and it converts an anxious operation into a rehearsal.

Where This Pattern Applies Beyond Boats

Strip out the sailing and the structure is generic: a physical item, a code attached to it, a location it occupies, an owner it belongs to, a fee attached to it, and a periodic reallocation that nobody wants to do by hand.

• Gyms, ski clubs, and marinas — member equipment storage with lockers, racks, or berths and seasonal reallocation
• Self-storage and caravan parks — unit assignment, occupancy reporting, and recurring billing from the same records
• Tool and plant hire — asset tags, yard positions, condition status, and hire charges
• Warehouse racking — bin locations, item footprints, and pick-path optimisation by movement frequency
• Museums, archives, and libraries — shelf positions, accession codes, and periodic reshelving projects
• Schools and universities — instrument, equipment, and locker allocation refreshed every academic year
• Event and AV companies — case-level tracking with codes that resolve to a kit list on a phone

The inventory tracking automation page covers how we structure this kind of base, and field workforce management covers the mobile side for teams working away from a desk. Clubs and associations running this as volunteers usually start from the nonprofit solutions angle, and the inventory tracking automation tutorial covers the automation layer in more depth.

Build It Yourself: The Sequence

1. Model the physical world one row at a time. One slot, one row. One asset, one row. Resist every temptation to pack two things into one cell.
2. Capture the constraints as fields. Asset type, footprint, hull class, size category — whatever determines where a thing can go must be data, not knowledge.
3. Create the code table up front. Generate a batch of codes, print the stickers, leave them unassigned.
4. Point the codes at an interface. Build the interface first, then encode its URL. Test one scan on a real phone before printing 400.
5. Link assets to owners and fee types. This is where billing stops being a monthly chore.
6. Connect ChatGPT to the base — one base, scoped deliberately — and snapshot before the first write.
7. Add a staging field for AI-proposed assignment changes, and rely on the snapshot for structural ones.
8. Restructure first, allocate second. Clean rows before assignment rules; allocation against broken data produces confident nonsense.
9. Give the rules with numbers, then check the first output hard.
10. Ask for the moving sheet. The plan that gets the work done physically is as much a deliverable as the updated records.

When to Get Help

This system was built by someone who knows Airtable well, and the AI section still needed several correction rounds. Bringing in help makes sense when:

• The physical constraints are more complex than "three slots or one" — weight limits, access order, seasonal rotation, or hazardous storage rules
• Fees need to reach an accounting system rather than sit in a field, such as invoices raised in Xero or Stripe
• Members or customers need their own login to see their asset, location, and balance
• The allocation has to run on a schedule rather than as an ad-hoc conversation
• The base itself is the problem, and the reorganisation difficulty is a symptom of a data model built before anyone knew what would be asked of it

We build Airtable systems like this one — asset tracking, QR and barcode workflows, interfaces for non-technical teams, and the automations that connect them to billing. Talk to our Airtable team if you want this adapted to your own yard, warehouse, or storeroom.

Next Steps

• Audit your own base for compound cells — anything with a slash, comma, or "and" doing the work a second row should do. That is your first restructuring job
• Read the barcode and QR code system guide to decide between the native barcode field and the extension route for your use case
• Add the Airtable connector in ChatGPT against a duplicated base and run a harmless restructuring task to see how it behaves before pointing it at anything live
• Review what MCP means for Airtable if you want the wider picture of AI tools operating on your data
• Plan your backup routine with the Airtable backup guide before any bulk AI operation

The interesting result here is not that an AI could answer questions about a boat yard. It is that it could restructure the records, apply physical constraints, reallocate the entire yard, and then hand back a printable plan for the people carrying the boats — a job that would otherwise be a long, tedious, mistake-prone afternoon with a spreadsheet and a clipboard.