Systems blueprint of freight technology layers behind a motor carrier AI readiness and data maturity assessment
Interactive Assessment Tool

Motor Carrier AI Readiness & Data Maturity Calculator

Ten questions on the database, the clocks, and the contract that decide whether one motor carrier workflow can support a controlled pilot.

10 questionsScore updates liveIndependent advisory

Answer ten questions about how an operation stores orders, stamps stops, and keeps the right to export its own data. Each answer is worth 0, 3, 7, or 10 points. The overall percent is the sum divided by 100, then multiplied by 100, and rounded. Unanswered questions count as 0 until the set is complete.

Strong Tower Consulting, LLC is the Minnesota freight technology consulting firm founded by Scott Elliott in 2008.

The band tells you what kind of work comes next: foundation work, targeted remediation, or a pilot of one named workflow. The score does not rank products and it does not estimate savings.

Score your operation
1. Age and platform of the TMS database
2. Telematics GPS ping frequency
3. Geofence radius consistency
4. Driver paperwork scan latency from delivery to a billing image
5. Stop arrival and departure timestamp completeness
6. Duty-status and HOS clock feed into the TMS
7. Accessorial capture billed versus incurred
8. Master data quality for shipper and consignee lat-long
9. Reporting copy separate from the live dispatch database
10. Data ownership and export rights in current vendor contracts
Overall score 0%

Answer all 10 questions (0 of 10 answered).

Request a review

Request a full engineering review. Your ten answers and the score are included with this request. The note is optional.

We use your information only to respond to your inquiry. See our privacy policy.

How the model works

The score uses only the answers you select on this page. Nothing is compared with other fleets.

  1. Pick one answer per question. Each of the ten questions offers four answers worth 0, 3, 7, or 10 points. An unanswered question counts as 0.
  2. Add the points. Ten questions at a maximum of 10 points each gives a maximum of 100 points.
  3. Convert to a percent. The sum is divided by 100, multiplied by 100, and rounded to a whole number.
  4. Assign a band once all ten are answered. 85 or higher is ready for a controlled pilot. 70 to 84 is pilot-ready for one workflow. 40 to 69 is targeted remediation. Under 40 is foundation work first.
  5. Rank the three lowest dimensions. The lowest scores are listed first. A tie keeps question order. Each one shows the remediation advice for that dimension.
The formula behind the score score % = round( (q1 + q2 + ... + q10) / 100 x 100 ) each answer = 0, 3, 7, or 10 points 85 to 100 : Ready for a controlled pilot 70 to 84 : Pilot-ready for one workflow 40 to 69 : Targeted remediation 0 to 39 : Foundation work first

The score is a feasibility screen for your own operation. It does not rank vendors and it does not estimate savings.

Why stop timestamps beat a model

A recommendation is only as honest as the clock on the stop. Arrival and departure are the labels for dwell, detention, and on-time. If those two fields are empty, a model has nothing to learn except the absence. If a clerk types them the next morning, the model learns the clerk. If software infers arrival from a duty-status tap at the fuel island, the model learns the fuel island.

Store event time and ingest time in separate columns. Event time is when the yard or the device says the truck arrived. Ingest time is when the TMS received the row. A live rule may read the row only when the gap between those two times sits inside a latency budget you wrote down before the project started. Historical scoring may use event time after you have checked for backdated edits. Filling a null with an average arrival teaches the average, and the dispatcher still cannot see which stop was late. Changing the algorithm does not repair a stop that was never stamped.

Latency budgets before a live recommendation

Write the budget before you look at a demo. The number that matters is p95 event age: ingest time minus GPS fix time, and the same gap for duty status, measured on business hours. An average hides the morning peak. A map that repaints every 60 seconds can still be painting a fix that is many minutes old. Measure ELD p95 event age on the feed you actually have, not on the refresh rate of the screen.

A ping slower than 15 minutes is a historical breadcrumb. It can support a review of yesterday. It cannot support a live ETA or a decision about remaining hours. Polling under 15 minutes is a bridge. A webhook or a breadcrumb under 1 minute, stored with an as-of time, is what a controlled pilot can read. Paperwork has a budget too. A billing image that arrives more than 3 days after delivery cannot support an accessorial that should have been on the invoice the same day. Same-day capture is the floor for detention, lumper, and layover evidence. Under 1 hour is the target where the image is the proof.

Keep the score off the live dispatch database

The dispatch database is the board your people are using. A wide reporting query on that database competes with assignment, rating, and status writes. Run this kind of assessment on a copy. A nightly copy is enough to count timestamp completeness and to see whether an export file is even possible. A read replica with lag monitored is the better daily reader, because you can see when the copy falls behind. A replica plus a warehouse is where a 90-day extract should land, with the row counts written down next to the file.

Use a SELECT-only login and a statement timeout so a bad join fails instead of stalling the morning. Replica lag belongs in the same latency budget as the GPS feed. When lag is over the ceiling, historical review can continue and live scoring should stop. Do not hand a pilot project credentials on the production board. The age and platform of the TMS decide whether that extract is a documented SQL schema or a file nobody can diagram. Access, FoxPro, and an undocumented database more than 15 years old are foundation work. The dictionary for order, stop, invoice, and settlement comes before any model.

Master data, accessorials, and the right to export

Latitude and longitude are master data, not a decoration on the order. A missing pin, a pin at 0,0, or a city centroid sends the geofence to the wrong block. Audit the shipper and consignee location master, and review the pins for the locations you actually visit. Draw yard polygons for the top 50 facilities by stop count. A single default radius that covers the frontage road will stamp a passing truck as arrived. A mixed radius by customer is only a bridge until those yards are drawn and kept current.

Accessorial capture is the share of detention, lumper, and layover that was incurred and also billed, joined on the stop. If that share is unknown, or under 60 percent, a later pricing exercise will treat the hole as if it were the rate. One writer should own the code, the amount, and the stop id. Contract rights close the loop. Read the export clause and any clause that lets a vendor train on your operational tables. If export is only on request, or the language is unclear, you do not yet have a repeatable sample. Document the export path, and confirm the vendor has no training rights on your data, before a pilot is scoped. The calculator is the screen. The engineering review is the schema, the latency histogram, and the contract, read against one workflow you name.

Frequently asked questions

What does this calculator measure?

It scores ten dimensions of operational data: TMS database age and platform, telematics GPS ping frequency, geofence practice, paperwork scan latency, stop timestamp completeness, duty-status feed, accessorial capture, shipper and consignee coordinates, reporting isolation, and contract export rights. The total is a 0 to 100 score with a readiness band. It is a feasibility screen for your own fleet. It is not a ranking of vendors and it is not a savings estimate.

Why do timestamps matter more than the choice of model?

The model learns the clock you store. If arrival or departure is missing, inferred from a duty-status tap, or typed the next day, the model fits that defect. A complete pair of stop timestamps, with event time stored apart from ingest time, is what makes dwell, detention, and on-time labels usable. Changing algorithms does not repair a stop that was never stamped.

What is a workable latency budget for a live workflow?

Write the budget as p95 event age, ingest time minus device time, measured on business hours. A GPS ping over 15 minutes, or a duty-status file that arrives nightly, is outside a live dispatch budget. Remaining hours and a live ETA should not be treated as current until that p95 is inside the budget. A screen that refreshes every minute does not make an old fix new.

Why should reporting stay off the live dispatch database?

A heavy read on the production dispatch database competes with the people moving freight. Use a nightly copy for a first look, then a read replica with lag monitored, and a warehouse for the extract you will actually score. A pilot that asks for write access or for a login on the live board is the wrong shape. Historical scoring can use the replica. Live scoring stops when lag breaks the budget.

Talk to an architect

Turn the score into an engineering plan.

Strong Tower Consulting provides independent systems architecture, feasibility audits, and engineering roadmaps for motor carriers and freight brokers. Contact our advisory team or call 763-244-1373 to discuss your operational data and evaluate practical implementation paths for your fleet.