Business operations Integrations Laravel

Paper and spreadsheets to one order workflow

TGPCB, an electronics components distributor in Vietnam, ran every order on paper forms and a shared Excel file: quotes, supplier purchases, goods arriving, payments owed. We replaced that with one system the office, the warehouse and the customers all read from — and stayed on to keep improving it.

TGPCB operations dashboard: order counts by state, revenue, customers, suppliers and payments awaiting approval

4Supplier price APIs connected

8Order states, derived — never typed

6Staff guides, written in Vietnamese

Mar 2026First commit; still improving

The problem

A customer order for electronic parts is rarely one purchase. Lines are bought from different suppliers abroad, arrive in separate parcels on separate days, and are paid for in instalments. On paper and in Excel, the state of an order lived in someone’s head: which lines were bought, which had landed, what was still owed. Every status question from a customer was a phone call, and every answer depended on who picked up.

What we did

We built around one rule: status is derived, not typed. Staff record what physically happened — a supplier order placed, a barcode scanned at goods-in, a payment approved — and the system works out where every line and every order stands. An order cannot be marked shipped by hand; it becomes shipped when every line has a tracking number. It cannot be edited after that, which ended a category of disputes.

Purchasing got live prices from four component suppliers so quotes stop depending on browser tabs. Goods-in got a barcode flow so a parcel is booked against the right line in seconds. Finance got a payment approval step and a per-customer balance that turns overpayments into credit instead of a note in the margin.

What we deliberately left alone

Excel did not disappear on day one. The system imports the order sheets the team already knew how to fill in, and exports the same shapes back out, so the business could move one process at a time instead of stopping for a migration. The accounting package stayed. So did the suppliers’ own portals — we connected to them rather than replacing them.

Since launch

The work has continued in small, dated design specs — fifty-one at the time of writing — each one a change the team asked for after using the previous version: a customer portal so clients check their own orders, a Telegram bot for the sales team, goods inspection before shipping, and a workload view so the owner can see where the week went. Every change ships with a written procedure for the staff who will use it.

Engagement

ClientTGPCB — components distributor, Vietnam

BeforePaper forms and Excel

StartedMarch 2026

Design specs51

Automated tests235 files

StatusIn use daily, still improving

What the staff received

Six plain-language guides, one per job, that never mention code:

What an order is, and what each status means From creating an order to completing it Payments, approvals and customer balance Goods-in by barcode, and by hand When an order can be edited, cancelled or shipped Reading an order’s change history

Evidence status

Screens below are TGPCB’s own system running on a demonstration database: every customer, order and staff name is fictional, so no real customer data is shown. Outcome figures are being agreed with TGPCB and will be added only once approved.

The system

Four screens, one rule

Each screen shows a status the system worked out from what staff actually recorded. Nobody types “shipped”.

Order list with derived order status and payment status per row, quantities ordered, bought and received, and outstanding balance — **Orders.** Order status, payment status and outstanding balance are all computed. Quantities ordered, bought and received sit side by side so a gap is visible before a customer notices it.

Order detail with three lines in different states: partly received, fully received, and bought but not yet arrived — **One order, three lines, three states.** Each line is tracked to its own supplier purchase and its own parcel. The order’s status is the roll-up of its lines — partly received, here, because one line has not landed.

Goods-in log listing each barcode scan or manual receipt with supplier order, part number, quantity and who recorded it — **Goods-in.** A parcel is scanned against the supplier order it came from. Every receipt is a log line with a quantity and a name, and can be reversed within a window if the count was wrong.

Customer portal showing the customer's own orders with status, payment state, quantities and outstanding balance — **The customer’s view.** A private link shows a customer their own orders, nothing else. The same derived statuses, so the answer they see is the answer the office sees.

Decisions

Three calls that shaped it

Derive status; refuse the edits that caused disputes Shipped and completed orders are locked at the model layer, not just hidden in the UI. Cheaper than adjudicating who changed what.

Keep Excel as a door, not a floor Import the sheets staff already used; export the same shapes. The process moved one step at a time, with nothing to un-learn on day one.

Write the procedures, in Vietnamese, before calling it done A system nobody trusts is a spreadsheet with extra steps. Each guide is written for one role and reads on its own.

Still running the business on spreadsheets? Start with a Blueprint and find out which three processes are actually costing you money.

Book a call →