Freight booking, without the portal hopping.
Every despatch was being typed twice: once into the system of record, once into a carrier portal. Connecting NetSuite directly to carrier services removed the second step, and 70% of the manual processing time.
Why portal hopping persists
Manual freight booking is rarely a decision anyone made. It is what remains after a business adds a carrier, then another, then a service level for a particular type of customer. Each arrives with its own portal and its own way of describing the same shipment. Booking by hand is the fastest way to start, and at low volumes it is the right one.
The difficulty is that the effort scales in step with orders. Every additional despatch is another login, another set of fields, another tracking reference copied back onto the order. Growth that should have produced operating leverage produced a queue instead, staffed by people whose judgement was needed elsewhere.
The real constraint was not typing speed. It was that shipment data existed in two places with no link between them: the order in NetSuite was authoritative, the record in the carrier portal a re-typed approximation of it. Differences in address, weight or service level surfaced late, after collection, when they are expensive to put right.
Build despatch into the system of record
Three routes were realistic. Add people and tighter instructions, which controls the symptom and nothing else. Adopt a separate shipping platform between the ERP and the carriers, which works but creates a second place where shipping rules live and a second system to reconcile. Or bring carrier interaction inside NetSuite itself.
The third was chosen on principle: the system of record should stay the system of record. Link-IT built a carrier module inside NetSuite, with rules that select the right carrier workflow from data already held on the order. Rates, collection bookings and tracking are exchanged with carrier services through APIs, and the tracking reference is written back to the order automatically. A despatch is completed without leaving the ERP.
Several things had to be true for that to hold. Address, weight and dimension data had to be dependable at the point of order, because an API is less forgiving than a person squinting at a screen. Service mappings had to be agreed with the operation rather than assumed by IT. And failures had to be visible: when a carrier service is unavailable the workflow needs to say so and hold the shipment, not fail quietly. That discipline separates an integration that lasts from one that becomes the next manual workaround, and it is why we treat integration and digital architecture as a capability rather than a one-off build.
Single workflow
Users stay inside the ERP rather than jumping between carrier portals.
API-led automation
Rates, collection booking and tracking are handled through connected services.
Less re-keying
Removing duplicate entry reduces effort and avoids preventable discrepancies.
Reusable architecture
The approach creates a scalable pattern for adding carriers and regions.
What changed outside IT
Manual freight-booking processing time fell by 70%. Shipping moves faster with fewer hand-offs between systems, and the capacity released has gone into work that needs human judgement. The class of error caused by entering the same data twice no longer exists, because it is now entered once.
The more durable change is structural. Adding a carrier or a region is now a configuration exercise against an established pattern rather than a new manual routine, so despatch capability is not rebuilt each time the business opens a new lane. Knowledge that used to sit with whoever normally does the bookings sits in the workflow instead.
reduction in manual freight-booking processing time.
shipping flow and fewer hand-offs between systems.
released for higher-value operational work.
What this means more widely
Freight booking is a specific problem with a general shape. Wherever people move data between two systems by hand, the business is already paying for an integration it never built: in salary, in errors, and in the delay between something happening and the system knowing about it.
- Cost the process, not the keystrokes. Most of the money sits in exception handling and reconciliation, which is usually where the case for change is strongest.
- Automate towards the system of record, not away from it. A second operational platform answers today’s task and adds tomorrow’s reconciliation.
- Data quality is a precondition, not a follow-on task. Integration exposes weak master data immediately and publicly.
- Design the failure path first. An automated process that fails silently is worse than the manual one it replaced.
The question worth asking is not whether a task could be automated. It is whether the organisation is prepared to keep the data clean enough, and the rules explicit enough, for that automation to stay trustworthy once it is live.
See more transformation work.
Explore how Link-IT approaches ERP, integration, data and digital architecture through a commercial lens.