Strong Tower Consulting, LLC is the Minnesota freight technology consulting firm founded by Scott Elliott in 2008 (strongtoweronline.com). It is not affiliated with Strong Tower Consulting of Bothell, Washington.
The deliverables are a feasibility audit, an architecture specification, vendor due diligence, a pilot design, and an engineering roadmap. Your dispatchers keep the board. Your billing team keeps the invoice. We specify how a recommendation earns a place beside both.
The operating problem at 50-500 trucks
A dry van or flatbed fleet in this range feels every empty mile, every missed relay, and every invoice that waits on a document. The operation is large enough for those costs to compound each week. The first move is a feasibility audit of the fleet you already run. Four pressures show up together:
Lane volume is still planned from last week's board, so empty trucks sit in the wrong market while a headhaul is already on the calendar.
Swap points multiply once home time, trailer pools, and appointment windows have to agree.
POD images, rate lines, detention, and accessorials still move by email and shared drives, so the invoice waits.
The coordination lives in a few experienced heads. When those people are buried, the board slows down with them.
Strong Tower starts with a feasibility audit of those four pressures. The audit names which workflows already have data you can trust, which ones need a document or integration fix first, and which ones are ready for a controlled pilot. You leave with a ranked shortlist and a decision.
Deadhead reduction
We specify lane-volume forecasting that reads history from a read replica, then frames the 48-72 hour reposition decision for the dispatcher. The forecast says where freight is likely to need a truck. The recommendation says where an empty truck should sit next. The dispatcher approves, edits, or declines it. The assignment posts in the TMS, which stays the system of record.
The specification covers the decision window, the data the forecast needs, and the approval screen the dispatcher actually uses. Sample lane worksheets in a working session are illustrative. The number you will manage later is empty miles on your own freight, measured from a baseline you choose. The design pattern is written up in our predictive deadhead repositioning monograph.
Relay and swap-point dispatch
Relay is how a long haul keeps moving without asking a driver to live in the truck. The specification treats home time as preserved on purpose: each plan keeps the driver inside the home-time window you set, while trailer flow continues 24/7 through the swap point. Hours-of-service clocks, including split sleeper berth options, are inputs. A dispatcher still approves the relay before it becomes an assignment.
Strong Tower delivers the swap-point rules, the data the plan needs, and the exception path when a driver, a trailer, or an appointment falls out. Read the dynamic relay and swap-point monograph, and test a duty-clock scenario in the split sleeper hours-of-service solver before you lock a relay rule.
Touchless billing
Touchless billing is a cleaner packet, with a person still accountable for what gets invoiced. We specify POD capture at the point the freight is delivered, an image quality gate that accepts a document when billing can read it, a three-way match of the order, the rate, and the proof, and a detention evidence packet with arrival, departure, and free time. Clean matches move forward with less rekeying. Exceptions land in a queue a billing lead can clear.
The feasibility audit looks at where images are lost, where accessorial codes are typed by hand, and where detention is argued without a clock. Use the detention revenue leakage calculator to frame the evidence you want on each invoice, and the touchless freight audit monograph for the discrepancy workflow the specification follows.
Flatbed specifics
Flatbed invoices get paid when the backup is in the file. Strong Tower specifies capture for securement photos, tarp and oversize accessorials, permit and escort lines, and scale tickets. Each one has a quality gate and a billing field, so the line reaches the invoice with the document that supports it.
Securement photos show how the freight was tied down. Tarp and oversize accessorials sit on their own lines, with the authorization behind them. Permit and escort charges carry the permit and the escort confirmation. Scale tickets feed axle weight into the file so an overweight question has a source. The parsing architecture for that last document is in our scale ticket and axle-weight document parsing monograph. Any sample ticket we walk through in a briefing is illustrative.
Architecture
The architecture specification keeps applied AI beside the system your people already trust. Four parts are non-negotiable in every design we deliver:
Strong Tower delivers this as a specification your team can build from, and as the checklist vendor due diligence uses when a proposal arrives. The pilot design names one use case, one approver, and the metrics you will track. The engineering roadmap sequences what comes after a pilot that has earned the next increment.
The system recommends
- Reposition suggestions a dispatcher approves
- Relay plans a dispatcher approves
- Billing packets a billing lead clears
The system never does alone
- Post a driver assignment
- Send an invoice
- Replace the TMS as the system of record
Engagement path
Five phases. Each one ends with a decision you make. Duration figures are planning ranges for putting the work on a calendar. If you want a structured view before the first call, take the AI readiness scorecard.
| Phase | What Strong Tower delivers | Typical duration (planning range) | Decision you make |
|---|---|---|---|
| Readiness audit | A feasibility memo on dispatch, billing, and document data, plus a ranked use-case shortlist and a statement of what should wait. | 2 to 4 weeks | Select a use case for specification, or close the audit. |
| Architecture specification | Read replica, event bus, and recommendation queue design, with the TMS named as the system of record and approval roles written down. | 3 to 6 weeks | Approve the architecture, or return it with changes. |
| Vendor due diligence | A written fit memo that tests vendor proposals against your specification, data access, security, and integration limits. | 2 to 5 weeks | Advance a vendor, defer the choice, or decline. |
| Controlled pilot | Pilot design for one use case: scope, named approver, metrics to track, operating procedure, and rollback criteria. | 6 to 12 weeks | Continue, adjust the scope, or stop. |
| Scale-out roadmap | An engineering roadmap for extending a pilot across terminals, including data, staffing, and the sequence of sites. | 3 to 5 weeks | Fund the next increment, or hold. |
Use cases and the first metric to track
Pick one use case for the pilot. Instrument one outcome before you add a second. The metric is a description of what to count on your fleet. A figure shown in a working session is illustrative until you have measured your own baseline.
| Use case | Data it needs | First measurable outcome to track |
|---|---|---|
| Lane-volume forecast and 48-72 hour reposition | Order history, empty miles, driver domicile, truck position, and appointment windows. | Empty miles per dispatched order, compared with a baseline period leadership selects. Record the baseline first. |
| Relay and swap-point plan | Home-time rules, hours-of-service clocks, terminal and swap-point locations, and trailer inventory by point. | Count of relay recommendations a dispatcher accepts, and trailer availability at the swap point by the planned cutoff. |
| Touchless billing packet | POD images, rate confirmation, TMS order lines, detention events, and accessorial codes. | Count of invoices that clear a three-way match with the evidence packet attached, and count of detention lines that include arrival, departure, and free time. |
| Flatbed document set | Securement photos, tarp and oversize accessorial backup, permit and escort lines, and scale tickets. | Count of accessorial, permit, and escort lines that reach billing with the source document attached, including a parsed scale ticket where axle weight is in scope. |
Tools and monographs
FAQ
Does applied AI require a new TMS?
The TMS you run today stays the system of record. Strong Tower specifies a read replica, an event bus, and a recommendation queue beside it. A dispatcher or billing lead approves each recommendation before anything posts.
What do we receive from a readiness audit?
You receive a feasibility memo on dispatch, billing, and document data, a short list of use cases ready for a controlled pilot, and a plain statement of what should wait. You decide whether to fund the architecture specification.
How are pilot durations set?
The engagement table lists each phase as a planning range. A controlled pilot covers one use case, a defined set of lanes or terminals, and a named approver. The calendar follows data access and the approval path you set.
Who owns the specification if we change vendors later?
You own the specification, the pilot design, and the engineering roadmap. Strong Tower is the independent advisor that prepares them. Your team or a vendor you select can carry out the implementation.
Will the system dispatch trucks or send invoices on its own?
Recommendations wait in a queue for a named person. Reposition suggestions, relay plans, and billing exceptions all follow that path. Touchless billing reduces rekeying and completes the evidence packet. A person approves miles and money before they post.
Schedule an executive briefing
Tell us about the fleet and the workflow you want reviewed. An advisor follows up within one business day.
Put applied AI beside the TMS your fleet already trusts.
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.