Why it exists

This dashboard measures people, and that changes how it had to be built. The evaluation already existed, but it was put together by hand and arrived as a number with no backing: neither side could argue it either way.

Every shipment is scored from 0 to 100 across three dimensions, and an operator's score is the average of their gradeable shipments — the ones that already have a recorded delivery or are already closed. Ones still in transit show as N/A: grading something that hasn't finished yet doesn't measure anyone.

• Closing time (50%). Days between the actual delivery and the shipment's close. The target is 6 days: closing on time scores 100 and going past ten days scores 0, with a stepped scale in between.
• Compliance (30%). The corrections their work required afterward — invoice reversals and reopenings —, classified by reason and weighted by how much damage was done. Touching an invoice on an already-closed shipment costs one-and-a-half times as much, and the penalty is capped: one bad month doesn't send the score to zero forever.
• Data-entry quality (20%). How complete the information ended up in the ERP. Between 11 and 15 key fields are checked depending on the mode of transport, because an air shipment requires an air waybill and a consolidation and a ground shipment doesn't.

The design rule that governs everything else: the number never lands without an explanation. Every point deducted can be traced back to the shipment that caused it. A score that can't be audited can't be defended in a performance conversation.

Where the data comes from

Two sources: the shipment feed, which gives volume, status, and how complete the dates are, and the correction requests that the compliance area logs in Airtable. They're joined by shipment ID.

That second endpoint has a catch worth documenting because it's easy to reuse the wrong way: it doesn't return every request, only the penalizable ones — it drops invoicing errors and anything that didn't reach "processed" in both systems. That's correct for this dashboard, which is what it was built for, and wrong for anything else: it hides one in three. Anyone who needs the full set has a different endpoint.

Build decisions

• Penalty weights live in the dashboard, not the endpoint. The endpoint says what happened; how much each thing costs is a business rule that gets tuned without touching the integration.
• Some operators fall outside the measurement. Anyone who no longer operates doesn't feed any indicator, so holding them to a date requirement only inflated everyone's pending count. They're not hidden from the dashboard: they simply stop counting, and the cell says so.
• Archived shipments don't require dates. They're closed for good; penalizing them changes nothing operationally, unlike the ones that can still be corrected.
• A date captured in the wrong field is flagged differently from a missing date. It isn't missing: it needs to be moved. Treating them the same led to people capturing it twice.

What's different in this demo

It's the same file that runs in production, with the data layer swapped out. The score calculation, the weights, and the breakdown are the real ones.

• Operators are fictional, with made-up initials. Publishing a real person's performance evaluation under their own name isn't an option, even with fake numbers.
• The correction reasons are the real catalog, because they're part of how the model works.
• Exporting to Excel is disabled: the viewer doesn't grant download permission.