A garden centre killed its double-stocktake with a two-system sync

Representative examplesEvery case study in this library is an illustrative composite of the kind of engagement we deliver — written to show our method and standards, not to name clients.

Where they started

A garden centre that has grown from a family nursery into a proper retail operation: a physical site with a POS, an online shop that now outsells the car park on weekends, and stock that is genuinely alive — plants arrive, sell, wilt, and get marked down or composted. The two systems grew up separately, the online catalogue was built from a supplier feed years ago, and the person who understands the POS's quirks is the owner, on the shop floor, with a phone in his pocket.

What it was costing

The POS and the online shop kept separate stock levels. Overselling live plants online was routine, staff re-keyed sales into the shop system nightly, and the 'current' stock count was whoever's spreadsheet had been updated last.

What they could see

• The online shop sold plants the POS had already marked as gone, and staff refunded apologetic customers by hand.
• Every evening someone re-keyed the day's shop sales into the other system, usually late and occasionally not at all.
• The stock count each team quoted differed, and the dispute ended with whoever's spreadsheet had been opened most recently.
• Marked-down and dead stock lived in the POS under codes nobody on the e-commerce side understood.

The constraints we worked inside

• Live plants sell in units with condition grades; the sync had to handle the POS's messy reality.
• The POS had no real-time API — polling windows had to be tight enough to matter.
• The owner checks stock on the shop floor from a phone; alerts had to be mobile-first.

What had been tried before

A nightly CSV export from the POS was scripted into the shop's importer.

Image paths, categories, and plant sizes never lined up with the shop's catalogue, and a bad import once blanked half the online listing photos.

A marketplace-style sync plugin was trialed during a quiet month.

It assumed a clean product database with simple units; the POS's condition grades broke its matching logic on the first live sync.

What we proposed

We proposed a self-hosted n8n sync that polls the POS database every 15 minutes, reconciles both systems on a log the owner can actually read, and reserves online sales against POS stock immediately — with a compensation rule for refunds so the books never drift. The polling window was chosen against the POS's reality: no real-time API, so tight, boring polling beats pretending. Every design decision was tested against the shop floor: alerts text the owner because dashboards don't get opened between customers, and condition grades are first-class states, not noise to filter out.

Just as important is what we ruled out, and why:

• Replacing the POS outright — The POS holds years of trade-customer history and the only staff who understand it; replacing it to fix a sync was the tail wagging the dog.
• Rebuilding the online shop on a platform with native POS sync — No platform natively spoke to their POS's polling-only database, so the sync problem would have remained after a months-long rebuild.
• One-way daily updates from shop to POS — Oversell happens online in the hours between updates; a daily batch would have fixed re-keying while leaving the actual bleeding untouched.

How the work ran

Delivered by the systems pod — automation specialist + engineer over 5 weeks, with working increments reviewed with the client every week.

The stack, and the reasoning

n8n (self-hosted)

Stock is commercially sensitive and the owner wanted the polling jobs on hardware he controls, next to the POS database itself.

POS database polling

The POS has no real-time API, so read-only polling against its database was the honest fastest option — and it works with its quirks rather than around them.

Shop API

The online shop's API handles decrements and refunds cleanly, which let the reservation rule live where the sales actually happen.

SMS alerts

The owner checks stock from the shop floor between customers; a text survives that context, a dashboard doesn't get opened.

Error workflows

A failed sync looks like a normal quiet hour until the oversells start; exceptions now collect into a weekly digest the e-commerce manager clears in one sitting, instead of an alarm nobody is free to answer.

What went wrong

How we worked together

Cadence

Twice-weekly 20-minute calls with the owner and the shop manager, plus the nightly reconciliation text every morning as a standing artifact.

Client side

The owner owned the condition-grade rules — no one else could; the e-commerce manager tested every publishing rule against live plants.

Decisions

The owner decided by walking the aisles: disputed mappings got settled with a plant in hand, usually inside a day.

They provided

Read access to the POS database, a stocked test bench of plants in every condition grade, and honest weekend traffic forecasts.

What changed

The headline: oversell incidents per month, three months post-launch versus three months before — 23 → 0, read from Order and POS reconciliation logs. A second check: nightly manual re-keying (eliminated) at −100%.

The nightly re-keying ritual is gone and nobody misses it; the evening staff close the till and leave. The owner texts less than he expected to — silence is the system working — and the morning reconciliation text has become how he starts the day: one glance, no drift, out the door to the nursery. The e-commerce team stopped pre-emptively discounting stock they feared would oversell, which the accountants noticed before anyone said it aloud.

The result was read from Order and POS reconciliation logs against the pre-engagement baseline over the stated window, with a guardrail check on nightly manual re-keying (eliminated). Where platform-reported numbers and business outcomes differ, this record says which layer it is quoting.

What they own now

• The self-hosted n8n sync between the POS database and the online shop's API, with a signed workflow export.
• A condition-grade mapping table the owner maintains when codes change.
• The reconciliation runbook, including what each alert threshold means in plants and where the database credentials are held.
• The polling schedule documented, with its trade-off explained in plain terms.
• A hands-on session training the e-commerce manager to read the sync logs.