This is a management system built for a distribution business and now in daily use. A screenshot of its dashboard appears in the solutions section on the home page. This article covers the design decisions — the part that rarely appears in a brochure but decides whether a system is usable.
How things worked before
Everything ran on spreadsheets and messages. Quotes drafted in Word, orders confirmed in a chat group, stock in a paper ledger, receivables in one Excel file held by one person. Every link worked; the problem was they were not joined, so nobody could answer three questions quickly:
- Did last week’s quote turn into an order, or is it sitting still?
- Has this order been delivered in full, invoiced, and paid?
- What did we actually earn this month after discounts and returns?
Decision 1: build the whole chain, not separate pieces
The original request was "build order management software". But the survey showed that with orders alone, stock would stay on paper, receivables would stay in Excel, and staff would still enter everything twice — leaving the root cause untouched.
So the scope widened into one unbroken chain: quote → order confirmation → stock issue → delivery → invoice → receivables. Each step produces the data for the next, with no re-entry. In exchange, the chain was cut into two-week milestones so the business had something usable early rather than waiting until the end.
Decision 2: states are the backbone
The core of the system is not the screens but the state model of each document. An order moves through defined states, and every transition has a condition:
| Transition | Condition | Automatic consequence |
|---|---|---|
| Quote → Order | Customer confirms, credit limit available | Reserves the stock |
| Order → Stock issue | Physical stock available; approval if over limit | Deducts stock, creates a delivery note |
| Stock issue → Delivered | Receipt confirmed by the recipient | Allows invoicing |
| Delivered → Invoice | Quantity actually delivered, less returns | Posts the receivable |
The right-hand column is where the system pays for itself: nobody has to remember "after issuing stock, remember to record the receivable". It simply happens, and so it does not get forgotten on a busy day.
The part that nearly broke: short deliveries
The first design assumed goods delivered equalled goods issued. In reality they do not: a customer receives a few cases short because of damage, or accepts everything and returns some at the door.
If the system only allows "delivered" or "not delivered", staff pick "delivered" and correct it by hand somewhere else — and the whole automated chain behind it goes wrong. This part was rebuilt: the quantity actually delivered is recorded at the point of delivery, and the difference automatically raises a stock return and adjusts the invoice value.
The dashboard: the first four tiles
The overview screen is deliberately sparse. Four figures on the top row — revenue this month, orders in progress, items at their stock alert threshold, and unpaid receivables — alongside a "waiting for approval" block listing the quotes and invoices needing someone with authority to look.
That approval block is the most used part of the day, though it is not the most impressive-looking. It is a clean example of the principle in Management dashboards: what belongs at the top is what leads to an action, not what looks best.
Data migration and running in parallel
The old product catalogue had many duplicate rows, added by different people over the years. Merging codes and settling units of measure took most of the migration phase — more than loading the figures did.
Opening balances came from a physical stock count rather than the old file; receivables were reconciled with each customer before loading. Both systems ran in parallel for several weeks with a weekly reconciliation, and Excel was only retired once the numbers matched consistently.
What we took away
- 1Too narrow a scope leaves the root cause in place; a wide scope has to be cut into short milestones to stay under control.
- 2State design matters more than interface design. An interface can be changed in a day; a wrong state model takes weeks.
- 3Exceptions have to be designed in from the start, not left for later — because if users cannot record the truth in the system, they will record something else.
Want to talk specifics?
SealCore surveys at your premises and sends a fixed quote after the first session — including when the conclusion is that you do not need custom software.
