Skip to content
GoBolt2026

Automated Rule Check

Turning each merchant’s receiving rules into checks the warehouse software could see, trust, and bill from.

Here’s how it came together

Overview

Challenge

Merchant receiving rules lived in rate cards, SOPs and people’s heads, so no one could see when a shipment broke them, and the extra work went unbilled.

Opportunity

Put each merchant’s rules into a workflow tied to the WMS at the point of receiving, and turn the answers into monitored data the business could act on.

Date of Project

2026

Role

Product Strategy & Operations Lead

Responsibilities

  • Operations research
  • Rule and process design
  • Compliance monitoring
  • Exception analysis
  • Product requirements

Tools

  • Google Sheets
  • Apps Script
  • Looker
  • BigQuery
  • Chrome extension
Facilities monitored
7
Non-compliances surfaced
1,230+
Revenue leakage identified
~$61K
Non-actionable alerts removed from the reviewed cohort
~21%

What is an ASN and why does it matter?

GoBolt is a technology-led 3PL. Merchants send inventory into its fulfilment centres, and GoBolt receives, stores and ships it. Before a truck arrives, the merchant creates an Advanced Shipping Notice (ASN): what’s coming, how it’s packed and when.

Every merchant also has a rate card: what they agreed to send, and what GoBolt charges when a shipment breaks that agreement. When the two don’t meet at the dock, extra work goes unbilled.

  1. Merchant requirement

    What the rate card promised

  2. Actual condition

    What arrived at the dock

  3. Extra work or risk

    Unloading, rework, delay

  4. Recorded exception

    Often never captured

  5. Charge or fix

    Unrecognized billing

Every inbound shipment runs through this chain. Before this work, the last two steps were rarely recorded, so the extra handling was never billed.

The warehouse saw each shipment, but not the rules it had to meet

I spent time on the floor, working pick and pack, and shadowing inbound receiving. A receiver could open an ASN in Providence, GoBolt’s WMS, and see the shipment, but not the merchant’s commitments.

So a merchant could promise single-SKU pallets and send a floor-loaded container. The team would unload it by hand, and unless someone remembered the rate card, billing never knew.

Before

  1. Rate card, SOP, account knowledge

  2. An experienced person interprets it

  3. An associate receives the shipment

  4. The issue may or may not be remembered

  5. Billing may never be recognized

After

  1. Merchant rule registry

  2. A check inside the WMS, at the dock

  3. A structured observation

  4. Exception logic

  5. An actionable record for billing, accounts, and analytics

Before this work, receiving rules lived in documents and individual memory. Now they travel with every shipment and produce a record billing can act on.

From a sentence in a contract to a checkable system rule

A policy like “shipments must be palletized” isn’t a requirement until you define where it applies, how it’s detected, what counts as compliant, and what happens when it fails.

I built on an early proof of concept that I inherited, a Chrome extension and Apps Script that surfaced rules inside Providence. I worked each merchant’s commitments into a rule registry: the merchant, the rule, the question to ask, the expected answer and the action on a mismatch.

Illustrative: one merchant rule written so a system can check it, including the approved exception.

Putting the rule at the point of work

When a receiver opens an ASN, an expectation check asks only the questions that apply to that merchant: was the dock appointment booked, did it arrive on time, did unexpected products show up, does the ASN match the truck.

Each answer is written to an inbound log with the ASN, merchant, site, user and time. An observation that used to disappear when the truck left became durable data.

Inbound log

  • ASN-40213Flagged

    Merchant A · Floor-loaded container

  • ASN-40211Clear

    Merchant C · All checks passed

  • ASN-40208Flagged

    Merchant D · No dock appointment

Illustrative reconstruction of the expectation check and the inbound log it writes to. Merchant names are placeholders.

Monitoring across seven facilities

I took the workflow from a proof of concept to an automated monitor across seven facilities, with Google Sheets and Apps Script running the workflow and Looker on BigQuery for the data.

Comparing each answer with the expected one turned every mismatch into a candidate non-compliance. The feed surfaced 1,230+ of them, about $61K of revenue leakage that would otherwise have gone unseen.

  1. 1

    Merchant rule source

    Requirements from rate cards and SOPs, structured per merchant

    Proof of concept, operationalized

  2. 2

    Guidance in the WMS

    A browser extension shows the rule inside Providence

    Proof of concept, inherited

  3. 3

    Expectation check

    Only the questions that apply to this merchant

    Proof of concept, operationalized

  4. 4

    Inbound log

    ASN, merchant, site, user, time and answers

    Proof of concept, operationalized

  5. 5

    Expected vs actual

    A mismatch becomes a candidate non-compliance

    Automated across 7 facilities

  6. 6

    Non-compliance action

    Billing review, account follow-up, coaching

    Automated across 7 facilities

  7. 7

    Exception logic

    Approved patterns stop firing; other violations still count

    Designed from the cohort review

The system layer by layer, and which parts were inherited, operationalized, automated or designed.

A correct rule can still produce bad alerts

One rule, one ASN per truck, was right as a standard but fired on merchants whose way of shipping was legitimate. A feed full of false alarms gets ignored, and a wrong flag can mean an unfair charge.

So I pulled an eligible merchant cohort and reviewed all 95 flagged ASNs. 75 had other real violations. 20 broke only the ASN rule and were legitimate exceptions.

75 with other real violations 20 broke only the ASN rule

95 alerts in the reviewed cohort

The 95 flagged ASNs. Applying the exception logic removes the 20 legitimate exceptions, about 21% of the cohort, and keeps all 75 real violations.

Encode the exceptions, don’t weaken the rule

Option A

Keep the blanket rule

Catches everything.

Keeps the false alarms: alert fatigue, unfair charges, lost trust.

Option B

Exempt those merchants

No more false alarms for them.

Also hides their other, real violations.

Option C

Targeted exception logic

Chosen

Suppress only the known legitimate pattern and keep checking everything else.

Exceptions need an owner and a periodic review.

Making the case for a native rules engine

The extension proved the need quickly, but it read Providence’s pages, so any change to the interface could break it. I wrote up what a native inbound rules engine would need: rules configured, not coded, scoped by merchant and facility, versioned by date, with conditional exceptions that keep other violations, evidence for disputes and a path into billing.

  1. Warehouse

    Captures the condition once, at the dock

  2. Data

    Trends by merchant, site and rule

  3. Billing and accounts

    Evidence for charges and conversations

  4. Merchant

    Sees the impact, adjusts how it ships

  5. Better inbound

    Less rework at the dock

and back to the warehouse

Where the data goes: captured once at the dock, used by billing and account teams, and shared with the merchant, so the next shipment arrives right.

What it changed

  1. 1,230+ inbound non-compliances surfaced across 7 facilities
  2. ~$61K in revenue leakage identified
  3. ~21% fewer non-actionable alerts in the reviewed cohort, with every real violation kept
  4. Receivers could follow each merchant’s rules without the one person who knew them
  5. Requirements for a configurable rules engine handed to Product and Engineering

What did I learn?

Key takeaways

  • Automation wasn’t the hard part. Precision was.
  • Design for exceptions from the start. A rules engine without them only works in a uniform world.
  • Capture the evidence once, at the dock, and reuse it in billing, accounts and analytics.

Next time

  • Define the exception taxonomy before building the first automated rule set.
  • Agree who owns and reviews each exception, so today’s valid exception doesn’t become tomorrow’s loophole.

Next project

Data Feeds

TMX Group · 2025–26