Auto transport management platform — TMS development

An auto transport management platform built end to end

Conveya is a car shipping company, and we rebuilt the platform it runs on from the ground up. The work was a full transportation management system, built around how vehicles actually move rather than how generic freight does: per-vehicle quoting, real-time shipment tracking the customer can see, and an AI-assisted FAQ that handles the questions a support line usually fields. Idealogic delivered the whole arc as one engagement, a strategic rebrand, a redesigned platform, and a mobile app, so the product a customer meets is the same product the operations team works in.

The old setup answered almost none of the questions auto transport generates. Customers called to ask where their car was because the product gave them nowhere to look. Requesting a quote meant a back-and-forth over phone and email. And the brand had drifted out of step with the operation behind it. The rebuild closed all three gaps at once, on a transportation management core written for car shipping.

Why a car shipping company needed custom TMS development

Off-the-shelf transportation management software is built for pallets, cases, and dimensional weight. Auto transport doesn't work that way. A vehicle is priced per car, routed on a carrier's specific lanes, and tracked by VIN, not counted by pallet on a standard load. Commercial TMS platforms handle that awkwardly at best, which pushes the real work into spreadsheets and inboxes and leaves the data model fighting the business.

That mismatch is why custom TMS development made sense here. The platform needed a quoting flow that asked for vehicle details and matched them to the carrier's lane structure, not a generic freight calculator bolted onto a car-shipping workflow. It needed tracking the end customer could actually see, rather than status buried in dispatch. And it needed to absorb the steady stream of routine questions (paperwork, timing, insurance) that a car shipping operation produces every day.

There is a cost to that mismatch that does not show up on a feature list. When the system fights the work, people paper over the gap with manual effort: a quote gets retyped from an email into a tool that asked the wrong questions, a status gets relayed by phone because the customer cannot see it, a workaround becomes a habit and then a process. Every one of those is time the business spends compensating for software that was built for a different kind of freight.

Each of those was a symptom of the same root problem: the customer had no window into their own shipment. With nowhere to look, they called. Every call was a question the product should have answered. Custom TMS software gave us room to design around the actual freight mode and turn those questions into screens, so the platform does the explaining instead of the support team.

What we built on the transportation management core

We rebuilt the platform as one system, with branding, UX/UI design, and mobile development sitting on a transportation management core, rather than a design project and a build project stitched together after the fact. Navigation was reorganized around what customers do, get a quote, track a vehicle, find an answer, instead of around the org chart.

Working that way kept the seams out of the product. When the brand, the interface, and the underlying TMS logic come from one team, a decision made in the quote flow does not contradict a label in the tracking screen, and the mobile app shows the same shipment state as the web view because both read the same data. The alternative, three vendors handing artifacts to each other, is how a platform ends up with a tracking page that says one thing and a support reply that says another.

Each of those pieces solves a question the old product pushed onto a person. Tracking answers "where is my car" without a call. The quote flow turns a free-text email into a structured request operations can act on. The AI FAQ handles the paperwork-and-timing questions that arrive in volume. None of it is a bolt-on; the five surfaces share one model of a shipment, so a change in how a vehicle is tracked shows up in the quote, the app, and the FAQ at the same time.

The result is a platform where customers track their own vehicles and quotes move through a defined flow. That kind of operational fit is what you get when the data model is written for the actual freight mode instead of borrowed from a generic TMS.

Real-time shipment tracking, from dispatch to delivery

The single most expensive question in auto transport is "where is my car," and the old product could not answer it. So tracking became the spine of the rebuild. Each vehicle reports status as it moves through pickup, transit, and delivery, and that status surfaces to the customer in the app rather than living inside dispatch. The shipment tracking is tied to the specific load, so what a customer sees matches the carrier and lane actually carrying their vehicle.

Putting that visibility in the customer's hands changes who has to do the checking. A check call used to mean someone in operations stopping to look something up and relay it. Now the customer opens the app. The same tracking layer also gives dispatch a cleaner view of what is moving, so the auto transport dispatch side and the customer-facing side read from one source of truth instead of two that drift apart.

None of this required inventing a number to justify it. The win is structural: a customer who can see their shipment doesn't need to phone in to learn its status, and a dispatcher who isn't fielding those calls has time for the loads that actually need attention.

Per-vehicle quoting and an AI-assisted customer FAQ

Two parts of the platform do work that generic TMS tools and even the larger auto transport products tend to skip. The first is per-vehicle quoting. A standard freight quote asks for weight and dimensions; a car shipping quote needs the vehicle and the route, matched to a carrier's lane structure. The carriers on the other side of that match are interstate operators that the FMCSA registers and assigns a USDOT number, so the lane logic has to reason about real motor carriers rather than abstract capacity. We built the quote request as a short, structured flow that captures exactly that, so a request arrives with the details operations needs to price and assign it, instead of starting another email thread.

The second is the AI-assisted FAQ. Auto transport produces a predictable set of repeat questions: what paperwork is needed, when pickup happens, how insurance works, how long delivery takes. Rather than route every one of those to a person, the platform answers them automatically, drawing on the customer's own shipment so the answer is specific rather than generic. The support team is left with the unusual cases, which is where human attention is actually worth spending.

Together, quoting and the AI FAQ move the start of every customer conversation further along. People arrive at support having already self-served the basics, so the conversations that do happen begin with the genuinely hard questions instead of the routine ones.

Architecture of a custom auto transport platform

The platform is organized around the transportation management core, with the customer-facing surfaces (web and mobile) reading from it rather than keeping their own copies of the truth. Quoting, tracking, dispatch, and the customer FAQ are different views onto the same shipment data, which is what keeps the answer a customer reads in the app consistent with what operations sees.

Real-time tracking sits as its own layer so a vehicle's status can update independently of whoever is looking at it, and both the customer view and the dispatch view subscribe to that layer instead of polling each other. The AI-assisted FAQ is wired to the same shipment context, so its answers reflect the specific load rather than a static help page. Building it this way is what lets one system serve a shipper, a carrier, and an end customer without forking into separate products for each. The shared core does the heavy lifting, and each audience gets the view it needs on top.

Settlement is the other place the per-vehicle model earns its keep. Because each car carries its own quote, lane, and carrier assignment, the platform can price and reconcile a shipment on its own terms instead of splitting a bulk freight invoice back down to the vehicle after the fact. A load picked up, delivered, and confirmed flows straight into what the customer owes and what the carrier is paid, with the same shipment record behind both numbers. That record is also the natural anchor for carrier integration. Larger operators expect to exchange tendering and status over EDI, where the relevant ANSI ASC X12 transaction sets are the 204 load tender and the 214 shipment status message, and a core keyed to one vehicle per shipment maps onto those messages cleanly. Designing for them early means a future carrier connection is a new feed into the same model, not a parallel billing system bolted on beside it.

For a logistics or vehicle logistics operation, that separation matters in practice: the data model is written once for how cars move, and every surface (quote, track, dispatch, support) is built on it rather than around it.

It also keeps the product honest as it grows. A new screen reads from the same shipment record, so it cannot drift into showing a different version of the truth, and a change to how a vehicle is priced or tracked lands everywhere at once instead of being patched surface by surface. That is the quiet payoff of building vehicle logistics software around the freight mode: the work of keeping quote, app, and dispatch in agreement is done by the architecture, not by people remembering to update three places. For an operation that plans to add lanes, carriers, or whole service lines later, a core that already speaks the language of cars is what makes the next feature an addition rather than a rebuild.

Results for shippers, carriers, and the customers in between

The platform now does the explaining. Customers track their vehicles themselves, the AI-assisted FAQ absorbs the routine questions, and support conversations start further along, with the unusual cases rather than the basics. The rebrand reads as one product from the landing page to the app store listing, so the identity a customer meets and the platform they use are finally the same thing.

What changed most is where the work happens. Information a customer used to extract through a phone call is now something they pull themselves, the moment they want it. The same shift helps the operation behind the scenes: fewer check calls, quotes that arrive structured instead of as free-text email, and a dispatch view that lines up with what the customer can see.

Conveya is part of our custom software development practice, alongside our product development work, and sits in our logistics and supply chain portfolio. For the supply-chain product we run ourselves, see HaulBreeze; for the marketplace side of vehicle logistics, see Pikkup, where drivers find nearby car services by geolocation. We also wrote about why auto transport breaks a standard TMS.