Latency & performance
A TMS has two latencies. Vendors publish neither.
The first latency is data freshness: how far behind reality the board is. The second is interface speed: how long the screen takes to answer a question your dispatcher asks fifty times a day. Both cost real money — one in demurrage, the other in payroll. Both are architecture decisions, made long before any demo you'll see.
Latency 1 — the data
How far behind reality is the board?
Continuous collection, not refresh buttons
Sources are watched around the clock on schedules appropriate to each provider. Nobody on your desk re-checks a terminal website to make the board current.
Live updates patch the open screen
When a container's status changes, the view you already have open updates in place. No reload, no export, no 'data as of this morning.'
Freshness you can see
Every data point shows its source, and staleness is monitored platform-wide — a source that stops updating is an alert to us before it is a surprise to you.
Cost deadlines computed ahead of time
Last free days and per-diem exposure are calculated continuously from your carrier terms, so the most expensive kind of latency — learning about a deadline after it passed — is designed out.
The contrast to watch for: systems built on portal refreshes, nightly batch cycles, or a single scraped feed carry data latency you can't see — the screen looks current whether or not it is. A system that cross-checks independent sources makes staleness visible instead of silent.
Latency 2 — the interface
How long does the screen take to answer?
Your working set lives with you
The containers you operate on are kept close to the browser. Filtering, sorting, and paging resolve locally — repeat questions don't wait on a server round trip.
No skeleton parade
Detail views open with content, not gray placeholder bars. The interface is designed so the second look at anything is instant.
Built for the dispatch tempo
A dispatcher checks the same handful of views dozens of times a day. Shaving seconds off each look is hours a week; that arithmetic drove the architecture.
Legacy TMS platforms carry two decades of interface debt: desktop clients mid-migration to the web, grids that reload on every filter, reports that finish in a spreadsheet. That debt is paid in your dispatchers' hours, every day, forever.
Take this to every demo
Five latency questions for any TMS vendor.
- 01
How old is the terminal data on this screen right now, and how would I know?
- 02
When the terminal website changes its layout, how long until you notice — and how long until I do?
- 03
What happens to the board while a 500-container customer uploads orders?
- 04
Show me the same filter applied twice. Does the second one hit your server?
- 05
When a hold lands at 6 a.m., what time does my dispatcher find out, and in which screen?
Ask us the same five. The answers are the demo.
Related
Keep comparing.
Next step
Time it on your own containers.
Send us a few container numbers and put a stopwatch on both systems: how current the data is, and how fast the screen answers.