What do people actually mean when they search for an 'AI platform for transport'?
The term is broad. Some companies are looking for a tool that automatically processes emails containing transport orders. Others want planning optimization on top of their existing TMS. Still others have had enough of their legacy system and want to rebuild everything from scratch. In practice, most questions fall into four categories: automated order entry (capturing orders from email, PDF, or portal without manual retyping), planning support (optimizing route planning based on time windows, capacity, and costs), document processing (reading and processing CMR documents, waybills, packing lists, and customs documents), and invoicing (automatically matching trips to rate agreements and preparing invoices). A platform that combines all these functions exists. But the question is whether such a generic platform fits your specific operation, or whether you are better off selecting standalone components or having custom software built.
Three architecture choices for AI in transport
The first option is standalone point solutions: a separate AI tool for email processing, a separate tool for planning optimization, and so on. Advantage: you can get started quickly. Disadvantage: you end up building a patchwork of integrations, and data does not flow automatically from one system to another. Every integration is a potential failure point. The second option is an integrated SaaS AI platform, such as the broader TMS suites that offer planning and document modules. Advantage: one vendor, one interface. Disadvantage: you adapt your operation to the system rather than the other way around, and the AI is built generically, not for your rate structure, your customer base, or your exceptions. The third option is custom development: a core system built specifically for your operation, with AI embedded at the core. This costs more upfront, but you get exactly what you need, you own the code rather than a license, and you are not dependent on a vendor's roadmap.
When is a standard AI platform for transport good enough?
A standard platform works when your operation is relatively uniform: standardised orders, few exceptions, standard rate structures. To be fair, a SaaS package has real advantages. You are live quickly, sometimes within weeks. There is no large upfront investment. Updates, security and hosting sit with the vendor, and costs are predictable. For a transport company that runs standard trips, invoices in a standard way and needs no unusual integrations, that is often the smartest choice. If you already have a recent and stable TMS, you do not even have to replace anything: AI Workers around that system automate the repetitive work without touching the foundation. Only when exceptions become the norm, when rate agreements vary widely per customer, when document flows are complex, or when your TMS is so old that every integration is a project in itself, does custom development become more attractive.
When does custom development fit better than a standard AI platform?
There are three signals that point toward custom development. First: your current system is more than ten years old and AI tool vendors can barely connect to it without workarounds. Second: your processes structurally deviate from what a standard package assumes, for example because you manage combined modalities or because your customers provide widely varying instructions per shipment. Third: you want to own your data and logic, rather than depending on a vendor who may scale back a module or raise prices. In those cases, it is wiser to have the core system rebuilt from scratch with AI embedded at the core than to keep stacking integrations on a failing foundation year after year. That costs more upfront than a subscription. In return, there is no licence that grows with your fleet or revenue, and you decide what gets built.
Where a generic AI platform runs into trouble in the Netherlands
The Dutch transport market has a few characteristics you should check with every international platform. Cabotage: after an international trip, a foreign haulier may carry out at most three domestic operations within seven days, followed by a four-day cooling-off period for the same vehicle in the same country. If you work with foreign trucks or charters, you want to see that reflected in planning. The truck levy: since 1 July 2026, trucks heavier than 3,500 kilos pay per kilometre driven on motorways and on some provincial and municipal roads. You want to be able to pass those costs through per trip in your rates. eFTI: the European regulation for electronic freight transport information. From 9 July 2027, authorities must accept freight data shared through a certified eFTI platform, which makes the paper consignment note redundant step by step. That calls for a data model that holds freight data in a structured way. And driver communication in the Netherlands runs through a mix of apps, portals and messages, depending on the customer. A platform that cannot handle that mix means dispatchers still switch manually. These are not edge cases; this is the daily operation. So ask how a platform handles each point before you sign.
What AI around your existing TMS actually solves
Many transport companies run on a TMS bought five or ten years ago. The system works, but input is manual: orders arrive by email, someone retypes them, consignment notes are scanned and stored without further processing. That is exactly where the gains are. Processing orders from unstructured emails and routing them to the right planner. Reading CMRs, packing lists and customs papers automatically. Flagging deviations in trip planning or weight. Targeted AI Workers do this alongside the existing system, without a migration. The fit is good when the TMS itself still does the job and the bottleneck is the manual work around it. If you want to change planning rules or rate structures that the current system structurally cannot handle, this does not solve the underlying problem.
Ownership: do you rent your software or own it?
The choice between a package and custom development ultimately comes down to ownership and dependency. With SaaS you rent software: the vendor decides the roadmap, the price and what changes. That is fine as long as their interests and yours stay aligned. With custom development you are the client and owner of the code, data and logic. That asks more of your organisation: involvement during the build and responsibility afterwards. It also gives something back: a system that sets you apart, rather than something your competitors use too. Whichever route you choose, check one thing: does your operational data stay yours, and can you always export it? That applies to a SaaS TMS just as much as to custom development.
What does an 'AI platform' mean in practice for day-to-day transport operations?
In practice, it means a planner no longer has to work through a pile of emails every morning to enter orders: the AI retrieves the order, reads the address, time windows, and weights, and places it ready in the planning system. The planner reviews and approves. For documents, it means a driver takes a photo of the signed CMR document, and the system automatically matches it to the trip and prepares the invoice data. People decide on exceptions: a damaged package, a weight discrepancy, a customer complaint. AI handles the data entry and preparation work, while the employee retains control. That is the model that works, and that is precisely the difference from systems that claim to run fully autonomously but in practice still require a full-time administrator.
Decision framework: which approach fits your transport operation?
Ask yourself three questions. One: how much of my operation fits a standard template? If almost everything fits, a SaaS platform or SaaS TMS is probably enough. Two: where is time lost every day? If it is in manual steps around a TMS that otherwise works fine, such as order entry, documents and driver communication, then AI around your existing system is the quickest win. Three: are my planning logic, rate structure or data model so specific that standard packages structurally fall short, and do I want to decide for myself how my system develops over the next five years? Then custom development is the route. The key question is not which platform has the most features, but which processes in your operation are distinctive enough that they should not be squeezed into a generic system.
Which routes does Bonsai offer, and what do they cost?
Bonsai builds all three routes; which one fits depends on your operation. Samurai TMS is the SaaS route: the Bonsai TMS for road transport, with AI running through the whole system. It reads orders from your mailbox, builds the quotation, matches your charter invoices and invoices the trip. Automated planning is being built. You pay a one-off onboarding fee and then from €30 per active truck per month. Samurai is made for hauliers and forwarders with roughly ten to two hundred trucks; above a hundred trucks we agree separate pricing. Bonsai AI Workers are the route if you keep your current TMS: they take over order entry, documents and other repetitive work around your existing systems, from €5K. Bonsai AI Digital Twin is the custom route: a new core system that follows your processes exactly, from €50K with a lead time of four to six months, and you own the code, the data and the system. If you do not yet know which route fits, that is exactly what a first conversation is for.