The demo ends on a map of India with two hundred green dots crawling along the highways. The VP supply chain nods. Then the plant logistics manager asks one quiet question: what happens when a carrier sends its trip file in a different format next week? The room goes still, and the presenter promises to check with the product team.
Supply chain control tower software should be judged by what it does with messy inputs and disputed numbers, not by how good its map looks on a clean demo dataset.
We build a control tower ourselves, so read this with that in mind. We have tried to write the checklist we would want a buyer to use on us, and it is fair to every approach: a packaged product, a custom build on your data platform, or a careful extension of your TMS.
The KPI definitions matter more than the screens
Most control tower projects stall on one argument: transport says OTIF is 96 and sales says 81. Both are right by their own spreadsheet. A tower that adds a third number makes the meeting worse.
Ask the vendor to show the written rule for each headline KPI. When is a trip on time: by the hour, or by calendar day? What counts as a delay versus a severe delay? If a truck has not arrived yet, is the arrival projected, and from what speed? A good answer fits on one card per KPI and is applied the same way to every trip, for the company, the 3PL and the carrier alike. Our logistics KPI dictionary is a reasonable template for that card.
Data intake is where most towers quietly fail
Carriers will not change how they work for your software. They send MIS files in their own templates, their trucks carry different GPS boxes or none, and the ERP dispatch sheet has its own quirks. The tower has to read all of it as it arrives.
- Several location sources. GPS alone leaves gaps. Ask whether SIM-based location, FASTag toll reads, carrier APIs and manual updates can all feed the same trip.
- Staged file uploads. A carrier file in a new template should be staged and reviewed, never written straight into live numbers.
- Conflicts wait for a person. When a file disagrees with what is already recorded, someone decides, and the system remembers the decision next time.
- Trip windows. A truck reused for another customer must not pollute your map with pings from a different trip.
A ranked list beats a beautiful map
A map tells you where trucks are. It does not tell you which of the two hundred needs a phone call in the next hour. The useful output is a ranked list of exceptions: late trucks, temperature excursions, placement breaches and short-dated stock, each with its owner and the action that fixes it.
Ask how the ranking works. A truck four hours late to a depot with nine days of cover matters less than one an hour late to a depot with one and a half days. If the software cannot weigh delay against stock cover at the receiving end, the team will go back to sorting by delay and phoning the depots.
A worked example: scoring three shortlisted tools
Here is an illustrative scorecard, not a real evaluation. Say a manufacturer with three plants and six RDCs shortlists three options and scores each criterion from 0 to 5, with weights that add to 100.
| Criterion | Weight | Option A | Option B | Option C |
|---|---|---|---|---|
| Written KPI rules | 25 | 5 | 2 | 4 |
| Messy data intake | 25 | 4 | 3 | 2 |
| Ranked exceptions | 20 | 4 | 5 | 3 |
| Scoped access by role | 15 | 5 | 2 | 4 |
| Time to first value | 15 | 3 | 5 | 2 |
Option A scores (25×5 + 25×4 + 20×4 + 15×5 + 15×3) ÷ 5 = (125 + 100 + 80 + 75 + 45) ÷ 5 = 85 out of 100. Option B scores (50 + 75 + 100 + 30 + 75) ÷ 5 = 66. Option C scores (100 + 50 + 60 + 60 + 30) ÷ 5 = 60. Option B had the best demo and the fastest start, and still finishes second because its KPI rules were vague. That pattern is common enough to plan for.
A control tower that adds a third OTIF number to the meeting has made the meeting longer, not shorter.
Each party should see only its slice
A control tower is shared by people with competing interests. Carriers should see their own trucks and scores, never another carrier’s. An RDC should see what is coming to it. A customer may need a read-only link for one shipment without a login.
Ask where the scoping is enforced. If the vendor says the other rows are “hidden in the interface”, that is not enough. Role should decide which rows come back from the server, so an exported report or an API call cannot leak them.
The case for extending what you already have
The strongest objection is simple: you already own an ERP and perhaps a TMS, so why buy another screen? For a single plant with a handful of dedicated carriers, that is often right. A well-built report on top of the TMS, with written KPI rules, may be all you need.
The case weakens as the network grows. Once you have many carriers with different data habits, several RDCs and a cold chain, the work is less about displaying data and more about reconciling it. That is the job a control tower exists for. Our comparison of control tower, TMS and yard management covers where each one stops.
For our own part, SCM for Manufacturers is built on a gate-to-proof-of-delivery module that is already live in production, with eight timestamped gate stages per truck and written rules for TAT, ETA and on-time verdicts. We would still ask you to test us on your messiest carrier file, not on our demo data.
What to do this week
- Write one card per headline KPI, including the on-time rule, and send it to every shortlisted vendor.
- Pick your two worst carrier MIS files and ask each vendor to load them during the evaluation.
- Ask each vendor to show a carrier login and prove it cannot see another carrier’s trucks.
- Agree the weights for your scorecard before anyone sees a demo.
A tower earns its place on the day two departments disagree about a number and the disagreement ends in minutes. More checklists and guides on the problem sit in our SCM for Manufacturers guides.