Client Order Portal

What it is

A client-facing order and shipment tracker: their orders, statuses, and tracking links in one branded page that updates itself from the source systems.

How it works

A curated, client-safe view generated from operational data, so the client sees progress while costs, suppliers, and internals stay invisible.

Development to deployment

Shipped for a first client who asked "where are we on everything?" one time too many. The portal answers that question all day so nobody has to.

The most expensive question in a service business

Where are we on everything. It arrives by email, by text, and on a call you were not planning to take. Each individual instance costs a few minutes of looking things up and a short reply. It feels like customer service, so nobody counts it.

Then you scale. Ten active jobs across four clients becomes forty across fifteen, and the status update work grows faster than the revenue does, because it scales with the number of jobs and the anxiety of the people who own them. At some point a meaningful share of a week is spent telling people things the systems already know.

What makes it worse is that the question is usually a symptom of low confidence rather than genuine need. A client who can see progress asks far less often than a client who has to trust you and wait. So the fix is not faster replies. It is visibility.

Two views of one dataset

The architecture is simple to describe and is the part people get wrong. There is one operational dataset, and the client sees a curated projection of it rather than a copy.

A copy is the wrong answer because copies drift. The moment there is a client facing version that somebody has to sync, you have added a second thing to maintain and a new way to be embarrassingly out of date in front of a customer. A projection updates because the underlying record updated. There is no sync step to forget.

The internal view carries everything: supplier, cost, margin, the note about the artwork problem, the internal deadline that is two days earlier than the one you told the client. The client view carries status, dates, tracking, and the things they are genuinely allowed to see. Same record, different lens, one source of truth.

What the client never sees, and why that has to be structural

Costs, supplier identities, internal margins, and internal notes never cross into the client view. That separation is enforced at the data layer rather than by remembering to hide a column, because a permission you have to remember is a leak with a delay on it.

This is the single most common way home grown client portals fail. Somebody builds it as a filtered view, ships it, and eight months later a new field gets added upstream and quietly appears on the client side. By the time anyone notices, a customer has seen your supplier list.

Building it the other way round, where fields are private by default and must be explicitly published, is slightly more work up front and removes an entire class of future incident. It is the same reasoning as the internal flag on a job note: the safe default has to be the lazy default, or it will not hold.

Access without building an account system

Clients will not create an account to check on an order. If the first thing they hit is a signup form, you have built something nobody uses and you will go back to answering the emails.

So access is a link, scoped to that client, plus a shared secret for the company. Nothing to install, nothing to remember, works on a phone in a truck. The security model is proportionate to the sensitivity: this is order status, not banking, and pretending otherwise buys you nothing except abandonment.

The measurable outcome is that the update emails slow down and then mostly stop. The relationship gets calmer as volume goes up, which is the opposite of what normally happens, and it is the thing clients actually remember at renewal time.

Common questions