automations.help
Book a teardown

Inventory & suppliers

Build a reorder-point dashboard in Airtable

Pull live Shopify inventory and trailing sales into Airtable on a schedule, let formula fields turn raw counts into days of cover and a health status per SKU, then read it all on one Interface sorted by urgency. The point isn't to act for you — it's to give you the single screen that tells you what to order next, before a customer finds the gap.

Difficulty
Intermediate
Time to build
3-6 hrs
Updated
  • Airtable
  • Shopify
  • n8n

The manual way today

To answer 'what's running low?' someone opens Shopify's inventory report in one tab, a sales report in another, and a separate spreadsheet of suppliers and lead times in a third, then mentally crosses them: this SKU has 40 left, it sells around 8 a day, the supplier takes two weeks — so is 40 fine or already late? They do that math in their head, SKU by SKU, whenever someone happens to ask.

There's no standing answer, only a recurring scramble. Because the picture only exists when someone reconstructs it, a fast mover slips past the line between reconstructions and you learn about it from a 'sold out' page. The number that actually matters — how many days of stock you have left at the current sell-through — lives nowhere. Every reorder decision is a fresh guess instead of a glance.

What running looks like

One Airtable dashboard, refreshed on a schedule, that shows every SKU with its on-hand count, its recent sell-through, and the number that decides everything: days of cover left. Each row is colored by status — Critical, Reorder now, Watch, Healthy, Overstock — and the view is sorted so the SKUs about to run dry sit at the top. You open one screen and see what to order next, ranked by how close it is to empty, instead of rebuilding the answer from three reports.

01The build

How to build it

  1. Lay out the Products table with the inputs the math needs

    Needs a human

    One row per SKU. Manual, human-owned fields: SKU (your join key), product name, supplier, supplier lead time in days, and a safety-buffer in days for a bad week. Leave empty, system-filled fields for: on-hand units, units sold in the trailing window, and units in transit. The dashboard is only as honest as the lead times and buffers you put here, so keep them in a table the person who owns purchasing can edit — not buried in code.

  2. Sync live Shopify on-hand into Airtable on a schedule

    Runs itself

    In n8n, a Schedule node fires every few hours (or each morning). It reads available units per SKU from Shopify's Admin GraphQL API — inventoryLevels at your fulfillment location — and upserts each into the matching Airtable row, keyed on SKU. Join on SKU, never on product title, which gets edited and isn't unique. After this step every row carries a current on-hand count instead of a number someone typed last Tuesday.

  3. Pull trailing sell-through so cover is real, not a guess

    Runs itself

    On the same schedule, query Shopify orders from the last 30 days, sum units sold per SKU, and write both the total and an average-daily-units figure back to Airtable. This is the field that separates a dashboard from a static list: 40 units means nothing until you know whether you sell 2 a day or 20. Trailing sales is what turns on-hand into days of cover.

  4. Add back what's already on the way

    Runs itself

    If you track purchase orders, sum the quantities on POs marked placed-but-not-received, per SKU, and store it as units-in-transit. The dashboard should rank cover on (on-hand + in-transit) so a SKU you reordered last week isn't screaming Critical while the truck is two days out. No PO tracking yet? Leave in-transit at zero and the math still works — it just reads slightly conservative.

  5. Compute days of cover and a status with Airtable formula fields

    Runs itself

    Keep the logic in visible formula fields, not in n8n, so anyone can audit it. Days of cover = (on-hand + in-transit) ÷ average daily units. A status field then buckets each SKU: Critical when cover is below the lead time (it will run out before a reorder lands), Reorder now when cover is below lead time + buffer, Watch when it's getting close, Healthy above that, and Overstock when cover runs into months. Guard the divide-by-zero: a SKU with no recent sales reads 'No recent sales,' not 'infinite cover, all good.'

  6. Build the dashboard as an Airtable Interface, sorted by urgency

    Needs a human

    In Interface Designer, make one page that is the single view: a record list grouped by status, sorted by days of cover ascending so the closest-to-empty SKUs float to the top. Add number elements across the header — count of Critical, count of Reorder now, dollars tied up in Overstock — and color rows by status so red reads as red at a glance. This is the screen that replaces the three-tab scramble; everything else feeds it.

  7. Drop a daily link to the dashboard where the team already is

    Runs itself

    A dashboard nobody opens is a spreadsheet. Have n8n post a short morning message to Slack — 'X SKUs at Reorder now, Y Critical' with a link straight to the Interface. Keep the detail in Airtable and the nudge in Slack; the message exists to pull someone to the screen, not to replace it. (If you want full SKU-by-SKU alerts in the channel instead, that's its own build — see the low-stock Slack recipe.)

  8. Handle the SKUs that break a naive average

    Needs a human

    Three honest edge cases. New SKUs with only a few days of sales history can't be trusted for cover — flag them 'New, watch manually' until the window fills. Promo and seasonal spikes make a 30-day average overreact or under-react, so let a person widen the window or pin a reorder point for those SKUs. And a bundle or kit drains its component SKUs without selling them as line items — count component depletion, or the dashboard will call a component healthy while the bundle quietly empties it.

02The stack

What it’s built on

Airtable
The dashboard itself: the per-SKU table, the formula fields that compute days of cover and status, and the Interface page your team reads instead of three reports.Airtable's free tier covers a few hundred records and includes Interfaces, so a small catalog can build this at no cost; you'll want a paid plan once you pass the per-base record cap. A Google Sheet can hold the same formulas if you'd rather not add a tool — you just give up the polished Interface view.
Shopify
Source of truth for both halves of the math: live on-hand units via the Admin API and the trailing orders that give you sell-through.
n8n
The glue: the schedule, the Shopify inventory and orders pulls, the SKU-keyed upsert into Airtable, and the optional Slack nudge.n8n is open-source and self-hostable for free; their cloud tier just saves you running it yourself. Zapier or Make can drive the same sync if that's already in your stack.

03Questions

Before you build

How is this different from a low-stock Slack alert?

An alert pushes you a message when a SKU crosses a line; this is the standing view you open on purpose. The dashboard ranks every SKU by days of cover, shows the healthy and overstocked ones too, and answers 'what do I order next and in what order' — not just 'this one specific thing is low.' Many brands run both: the dashboard to plan, an alert to catch the urgent crossing. They're separate builds.

Where does 'days of cover' actually come from?

It's on-hand plus what's already on order, divided by your average daily units sold over the trailing 30 days. A SKU with 40 units selling 8 a day has 5 days of cover; the same 40 units selling 1 a day has 40. That's the whole reason the dashboard pulls sales and not just inventory — the raw count can't tell you whether you're fine or already late.

Won't it flag SKUs I've already reordered?

Not if you feed it in-transit quantities. The cover math runs on on-hand plus units on placed-but-not-received POs, so a SKU you ordered last week reads with the inbound stock counted. If you don't track POs yet, in-transit stays zero and the dashboard just errs toward reordering a touch early.

How often does it refresh, and will that hit Shopify's rate limits?

Every few hours is plenty for a reorder dashboard — inventory doesn't move minute to minute in a way that changes a buying decision. The Admin API is paginated and rate-limited, so the sync pulls inventory and orders in pages on a schedule rather than hammering it; a morning refresh is enough for most catalogs.

Do I need Airtable, or can I keep this in a Google Sheet?

A Google Sheet runs the same formulas and is the right call if you're avoiding another tool. Airtable earns its place for the Interface: grouped, color-coded, sorted-by-urgency views that read like a real dashboard, plus linked supplier records. The logic is identical — you're paying for the screen, not the math.

Can I build this myself, or should you build it?

If you're comfortable with the Shopify API and a few hours of Airtable setup, build it — the schema, the sync, the formula fields, and the edge cases are all written out above on purpose. If you'd rather not own the velocity math and the status logic, we'll build it on the Shopify, Airtable, and n8n accounts you already pay for, document every field, and hand you the keys. You own the dashboard outright: no monthly retainer, nothing locked behind us. It starts with a free 20-minute teardown where we map your SKUs and lead times — not a contract.