Scottish delivery zones in product feed software

What to take away

Why Highlands and islands delivery costs more to serve

A parcel to Inverness and a parcel to Islington leave the same warehouse but do not cost the same to deliver. Distance is only part of it. The last leg often runs on a smaller van, a ferry or an air service, and those legs have fixed capacity.

Carriers price that risk. A route that needs a ferry booking, a timed sailing or an island depot adds handling that a mainland trunk route never sees. The surcharge reflects the cost of serving the address, not a penalty aimed at Scottish shoppers.

Retailers in Scotland feel this on both sides. If you ship from Glasgow to the Western Isles, you buy the same surcharge your English competitor buys. If you ship from England into Scotland, the surcharge lands on your checkout and your margin.

Weather and timetable disruption matter too. A cancelled sailing can push a delivery by days, and carriers build that uncertainty into their zone rates. That is why a single national delivery table rarely survives contact with the north.

For a Scottish retailer, the local knowledge is an advantage. You know which postcodes are mainland, which are island, and which need a two-day window rather than a next-day promise. That knowledge belongs in the feed.

Carrier surcharges and postcode zones in Scotland

The first step is to stop thinking in countries and start thinking in carrier postcode zones. Every major UK carrier publishes a zone map, and the Scottish entries are the ones that change your numbers.

Most carriers split Scotland into several bands. Typical bands include the Scottish mainland, the Highlands, the offshore islands and, separately, Northern Ireland. The exact boundaries differ by carrier, so two couriers can quote different prices for the same address.

Postcode prefixes do most of the work. Areas such as IV, KW, HS, ZE, PA and KA carry different treatment depending on the carrier and the service level. Some carriers treat parts of PA and KA as mainland; others do not.

That inconsistency is the trap. If your delivery table assumes one Scottish zone, you will undercharge some addresses and overcharge others. The undercharged ones cost you money on every order.

A workable approach is to build your own zone list from the carrier maps you actually use, then store it as a reusable table. Keep the carrier name, the service, the postcode range and the surcharge in one place.

Royal Mail, Evri and DX publish separate Scottish bands for the same core postcode areas. The exact surcharge comes from your contract rate card, but the zone map itself is public.

Use the band, not a guessed figure, when you map IV, KW, HS or ZE in your feed.

Shipping overrides and delivery tables in product feed software

Shipping overrides in feed settings are how a zone table becomes real behaviour. Instead of one delivery rule for the whole United Kingdom, you create rules that match a postcode or region and apply a different price, service or exclusion.

Delivery table configuration usually works in layers. The base rule covers the standard UK rate. Overrides then sit on top for the Highlands, the islands and any address you cannot serve on the standard service.

A practical build order looks like this:

The order matters because overrides are usually matched top down. A broad rule placed above a narrow one will swallow it, and your islands surcharge never fires.

Google Merchant Centre takes delivery costs through shipping services and the shipping attribute. It can price Scotland as a region differently, but it does not accept IV, KW, HS or ZE as postcode overrides on their own.

Channable and DataFeedWatch handle this at rule level. You write a condition that tags a product or writes a shipping field for a named zone, then the shop applies the postcode match. Neither tool replaces a checkout that can test the full postcode.

This is where shopping feeds operations discipline pays off. A delivery table is not a one-off setting. It is a live rule set that needs an owner, a review date and a test before every peak.

If you are rebuilding your feed structure, a shopping feeds planning template is a zone, service and exception matrix that helps you list every rule before you touch the settings.

How surcharges change price display in UK feeds

A surcharge that appears only at checkout is a pricing problem. Google Merchant Centre expects shipping information to be supplied so that the cost shown to shoppers is accurate, as set out in Google Merchant Centre's shipping information requirements.

That means the delivery figure attached to a product can vary by destination. A Glasgow shopper and a Lerwick shopper may see different totals for the same item, and both should match what your checkout will charge.

Checkout behaviour matters as much as the feed. Google Merchant Centre's checkout requirements and best practices cover how delivery and total costs should be presented, and a mismatch between feed and checkout is a common cause of disapproval.

There is a legal layer too. The Consumer Contracts (Information, Cancellation and Additional Charges) Regulations 2013 require traders to give clear information on delivery charges before the consumer is bound, and they restrict default additional charges. You can read the full text of the Consumer Contracts Regulations 2013, SI 2013/3134, on legislation.gov.uk.

In practice, three display choices matter:

Cross-border settings add another variable. If you sell into Ireland or further afield, Google Merchant Centre's rules on supported languages and currencies affect how delivery and price data should be presented to those shoppers.

A worked example

A Scottish retailer sells a 2 kg box for £40 with free UK delivery. The feed has a base rule for mainland UK. A Highlands override matches IV, KW and PH (parts) and adds £6. An islands override matches HS, ZE, KA27-28 and PA20+ and adds £14.

A customer in EH1 matches the base rule and sees £40 delivered. A customer in IV2 matches the Highlands override and sees £46. A customer in HS9 matches the islands override and sees £54, with a two-day transit window rather than next day.

If the feed shows £40 to all three, the retailer absorbs the surcharge on two of them. If the checkout then adds £14 without warning, the customer feels misled and the order may be cancelled under the information rules.

Neither outcome is acceptable. The fix is to make the zone rule the single source of truth for both the feed and the checkout.

Testing delivery settings before peak trading

Delivery rules fail quietly. A wrong postcode range does not throw an error; it just charges the wrong price until someone notices. That is why testing belongs on the calendar, not in a crisis.

Build a test basket of real Scottish addresses across every zone you serve. Include a mainland city, a Highland town, an island address and a Northern Ireland address if you ship there.

Run each address through the feed and the checkout, then compare the two. The prices should match, the transit windows should be honest, and any excluded address should be blocked before payment.

The shopping feeds hidden costs page lists the data and sources that often go stale: carrier zone files, duplicated postcode ranges and rules nobody has reviewed since the last carrier change.

A short pre-peak checklist keeps the review honest:

Run the same test after any carrier change, warehouse move or new service launch. Peak trading exposes weak rules because volume rises and exceptions multiply.

Common questions