Pinwheel.
All Articles
FloristDelivery RoutingHeadless CommerceMedusa.jsTechnical

Multi-Postcode Delivery Routing for Florists: How It Actually Works

Delivery zones. Cut-off times by postcode. National vs local order logic. Same-day versus next-day by area. Most florist platforms treat postcode routing as a settings screen. Here's why that's not enough — and what a proper implementation looks like.

PinwheelEngineering Team, Pinwheel Media Ltd
·1 June 2026·6 min read

Florist delivery logic is more complex than most e-commerce categories. You're not shipping a parcel with a 3–5 day window. You're delivering a perishable product to a specific address, on a specific date, often within a tight same-day or next-day window — and the rules change based on where the customer lives, what they're ordering, and what time they placed the order.

Most florist platforms give you a postcode settings screen. Enter your delivery areas. Set a flat rate or a distance-based fee. Done.

For a small single-location florist doing local deliveries, that works. For anything more complex — multiple locations, national delivery, same-day cut-offs by area, different lead times for different product categories — it breaks down quickly.

This post covers what multi-postcode delivery routing actually involves, where off-the-shelf platforms hit their limits, and how a custom implementation solves it.

The Problem With Simple Postcode Zones

Most platform implementations treat delivery as a flat configuration:

  • Here are the postcodes I deliver to
  • Here is my delivery fee
  • Here is my cut-off time

The real-world logic is almost always more nuanced:

Same-day versus next-day varies by postcode. A florist based in South London might offer same-day delivery to SW, SE, W, and E postcodes, next-day to the rest of London, and 3-day lead time to anywhere outside Greater London. This isn't one rule — it's three separate rules keyed to postcode prefix.

Cut-off times vary by distance. Orders for local same-day delivery cut off at 2pm. Orders for national next-day delivery cut off at 11am to allow for courier collection. Orders for specific product categories (wedding flowers, large installations) need 5 days regardless of location. These overlap and interact in ways a flat postcode setting can't capture.

Product-level delivery constraints exist. A standard bouquet can go national via courier. A hand-tied arrangement in a vase can't be couriered — it needs local delivery only. A Christmas wreath has a different lead time than a birthday bouquet. When your delivery rules need to apply differently per product or category, you need a data model that supports that.

Multiple locations complicate routing. For a business like the Blooms group — three storefronts in different parts of London and Surrey — a customer's delivery postcode might be best served by one location but they placed their order on a different storefront. Which location fulfils the order? How does that affect the cut-off time and delivery fee they were shown at checkout?

How a Proper Implementation Models This

The answer is treating delivery routing as a first-class data problem, not a settings screen.

Postcode Prefix Rules

Rather than a flat list of postcodes, the system stores rules keyed to postcode prefix (the first 2–4 characters of a UK postcode, e.g. SW1, KT17, EC).

Each rule contains:

  • delivery_type: same_day | next_day | national | unavailable
  • cutoff_time: the time before which an order must be placed for this rule to apply today
  • lead_time_days: minimum days from order to delivery
  • fee: delivery fee for this zone
  • priority: when two rules match (e.g. SW and SW1), the more specific one wins

When a customer enters their delivery postcode at checkout, the system evaluates their postcode against this ruleset and returns the applicable delivery options, cut-off times, and fees in real time.

Product-Level Overrides

For products that can't be couriered, or products that need extended lead times, the product record carries a delivery_override field:

  • local_only: true — hide national delivery options regardless of postcode
  • min_lead_days: 5 — enforce a minimum of 5 days lead time for this product, overriding the zone default

When a cart contains a mix of standard products and restricted products, the checkout applies the most restrictive rule. If the customer wants to order a same-day bouquet and a wedding installation in the same transaction, the cart tells them the soonest available delivery date for the full order — not just the bouquet.

Cut-Off Time Logic

Cut-off times need to account for time zones, bank holidays, and business hours. A naive implementation that simply says "cut-off is 2pm" fails when:

  • The customer places their order at 1:58pm and the payment takes 3 minutes to process
  • It's a bank holiday and same-day delivery isn't running
  • The order comes in on a Sunday and the earliest available slot is Tuesday

A robust implementation uses a calendar of operational days and calculates the next available delivery date from the moment of order confirmation, not order placement.

National vs Local Order Routing

For multi-location businesses, the national/local split matters operationally. When an order is flagged as local (postcode is within driving range of a specific location), it can be fulfilled directly by the nearest shop. When it's national, it routes to whichever location is set as the national fulfilment hub.

This routing decision can be made automatically at order creation time based on the delivery postcode, and communicated to the relevant location via WhatsApp notification or admin panel flag.

What This Looks Like at Checkout

Done well, the customer experience is simple: they enter their postcode, and the checkout immediately shows them their available delivery options with accurate dates and fees. No guessing. No ordering same-day delivery and receiving a next-day email telling them it's not possible.

Done badly, customers either see options that can't actually be fulfilled (which requires manual intervention) or they see options so restricted that they abandon.

The difference is almost always in whether the business modelled their actual delivery rules as structured data, or tried to make a flat settings screen do something it wasn't designed for.

Where Platform Limits Show

Most florist-specific platforms (Florist Touch, Florist Pro, Florist Window) offer delivery zone configuration. They typically support:

  • ✅ Postcode-based delivery area restrictions
  • ✅ Flat delivery fees per zone
  • ✅ A single global cut-off time

They typically don't support:

  • ❌ Per-postcode cut-off times
  • ❌ Product-level delivery restrictions
  • ❌ Multi-location routing logic
  • ❌ Dynamic available-date calculation at checkout

For simpler operations, what they offer is sufficient. For a business with more than one location, national delivery, or product categories with different lead times — you'll eventually be implementing workarounds that eat staff time.


Multi-postcode delivery routing is one of the eight features we built into the Blooms at London platform — and it's a core part of what we offer for florists moving to headless. If you want to see the full feature set, our florist e-commerce service page covers it in detail.

If you're trying to work out whether a custom build makes commercial sense for your business, run the numbers through our ROI calculator.

About the author

Pinwheel

Engineering Team, Pinwheel Media Ltd

Pinwheel is a UK web design and engineering agency specialising in headless e-commerce, bespoke website builds, and business automation systems. Based in Surrey, we've delivered 100+ projects for UK businesses since 2015 — from local service websites to complex multi-tenant commerce platforms.

● Ready to Build?

Let's Build SomethingRemarkable.

Whether it's a headless commerce platform, a bespoke automation system, or a high-performance web presence — we'd love to hear about it.