How Do You Give Warehouse Customers KPIs Without Another Excel Report?

A customer asks for KPIs. Someone in the office works through the Load records, checks two jobs with a supervisor, looks up which invoices went out, and builds a spreadsheet.

Three weeks later, the same request arrives again.

The problem isn't the spreadsheet.

Excel is a good tool. A rate model, a one-off analysis, a scenario a customer wants costed out — a spreadsheet is often exactly the right answer. The difficulty is the loop that produces it.

Load records → a supervisor's recollection → a spreadsheet → an email → the same request three weeks later

None of those steps is difficult. All of them take time, and the answer is out of date the moment it is sent — so when the customer wants to know something on Thursday about a Load that finished on Wednesday, they call instead.

The record of the work and the customer's view of the work are two separate things, maintained by hand.

What customers are actually asking.

The request arrives as “KPIs” or “a reporting pack”. Underneath it is the same short list:

• What work did you complete for us, and when?
• How much volume did you handle?
• Has that completed work been invoiced yet?
• What do we currently owe, and is anything overdue?

Every one of those answers already exists in the operation. Nothing new has to be measured — it just has to reach the customer without a person reassembling it first.

Give them visibility from the work itself.

A customer portal is a signed-in view of one customer's own records, reading from the chain the operation already runs on:

This works only if the work is recorded as it happens — the Load, its site, its Work Type, its crew and its completed quantity. That is the same discipline behind knowing where warehouse labor hours are actually going. Here is what it produces, screen by screen.

The overview.

Gateway Dock Services runs the labor; Northgate Provision Co. is the customer looking at their own account. Example account shown with simulated data.

1. 1

   Their portal, your name — The labor provider's own branding with a Powered by FOREMAN line, and three destinations — Overview, Loads, Invoices. Built for the customer to visit a few times a month, not for an operator to live in.

2. 2

   A two-line summary — One operational sentence, one billing sentence. It draws a conclusion rather than repeating the numbers underneath it.

3. 3

   Needs your attention — The portal says what to act on instead of leaving the customer to interpret a dashboard: one invoice past due with its amount and due date, the next payment so it never becomes the first item, and completed Loads not yet invoiced, listed by ticket number.

4. 4

   Four standing questions — Is anything being worked? How much finished recently? How many invoices are open? How much do we owe? Answered on sight, without a phone call.

Operational KPIs and billing KPIs.

How much work was done, and how much of it has turned into money, are two different questions. Performance Insights keeps them apart.

1. 1

   Two kinds of KPI, side by side — Cases Handled and Average Per Load describe the work. Recent Loads Invoiced, Awaiting Invoice and Overdue describe what that work has turned into. Each figure states its own scope — “across 4 most recent completed loads” — so a sample is never read as a monthly total.

2. 2

   Cases handled per completed Load — The distribution, not one total. 2,240 cases on LD-2301 against 1,200 on LD-2309 is a full container next to a lighter trailer — a shape a single figure hides.

3. 3

   Where your balance sits — $6,310.00 overdue plus $8,420.00 due is the $14,730.00 on the Outstanding card. An accounts-receivable position without opening invoices one at a time.

Let customers ask the question.

Even a good dashboard asks something of the reader: know which number answers your question, and know where it is.

1. 1

   The questions, already written — A fixed set of what customers actually ask. No chat box, no model, nothing generated — the customer picks the question instead of hunting for the number that answers it.

2. 2

   An answer that names records — Calculated from the same figures on the page, so every sentence can be checked against the tables below it. “LD-2314 and LD-2309 are awaiting invoice” is actionable; “2 loads awaiting invoice” sends you looking.

A customer shouldn't have to understand your reports or your navigation to find out whether their work has been invoiced.

Completed work and its invoice.

The last section of the overview is two short lists — the customer's recent Loads, and their recent invoices.

1. 1

   Recent Loads — Ticket number, date, site, Work Type and status. The ticket is what both sides quote — “what happened on LD-2309?” beats “the trailer a couple of Tuesdays ago”.

2. 2

   Recent Invoices — Number, invoice date, due date, total, and a status the customer reads without translation. Drafts are never shown at all, and what the office calls Sent reads here as Due.

LD-2301 and LD-2297 were billed on INV-2026-0124, due September 7. LD-2314 and LD-2309 are finished and not billed yet — which is exactly what the attention list said at the top of the page. That connection only exists when completed work is captured against the job it belongs to, the same principle behind capturing ad-hoc warehouse work so it actually gets billed and behind keeping signed paperwork on the Load.

Work performed → completed Load → invoice → payment status, visible end to end without a phone call.

Not the same as emailing a spreadsheet.

• It doesn't go stale. A Load completed on Wednesday afternoon is in the customer's list on Wednesday afternoon. Nobody exported anything.
• Both sides read the same thing. “Nine Loads or eleven” stops being a disagreement between two reconstructions of the same events.
• The customer sees their own records only. Pay rates, crew, payouts, margins, internal notes and every other customer's work are not part of the customer-facing view.

What changes for the labor provider.

• Routine status questions have a place to be answered without an email.
• Recurring KPI requests stop requiring someone to assemble the same summary by hand.
• Billing conversations start from named invoices and named Loads.
• Completed work waiting to be invoiced is visible to both sides.

Customers will still call about exceptions, damages and scheduling. Those calls are worth having. The ones about last month's case counts are not.

Reporting should be a byproduct of the work.

Not an administrative job created afterwards, repeated on request, and out of date by the time it lands in an inbox.

A practical test: if a customer asked today which of their completed Loads haven't been invoiced yet, would the answer come from a record, or from somebody's memory?

FOREMAN keeps those records connected from the warehouse floor through to customer reporting, and the Customer Portal is the customer-facing end of that chain. The full feature workflow shows how a Load reaches crew, billing and invoicing before a customer ever sees it.

See what your customers would see.