How Two Global Logistics Leaders Built Scalable Operating Models

How SFL helped a North American customs brokerage leader and a global LCL consolidator redesign complex operations around CargoWise, using two very different transformation paths.

For large logistics organisations, implementing CargoWise is rarely a matter of replacing one system with another.

The platform has to enter an operating environment that is already moving freight, processing customs, managing finance, calculating rates, serving customers and exchanging data across other applications. Years of regional processes, internal controls, external integrations and local regulatory requirements already sit around those operations. Changing the technology therefore means changing part of the operating model that supports the business.

That was the common challenge facing two very different logistics organisations that engaged SFL Tech. Both organisations were trying to achieve a similar outcome: a more connected, controlled and scalable CargoWise environment.

But getting there required two very different transformation paths.

The Same Platform Does Not Mean the Same Implementation

Enterprise CargoWise implementation is as much a sequencing decision as it is a technology decision.

A business can know exactly where it wants to end up and still make the wrong move by starting in the wrong place. Moving too quickly into configuration can reproduce years of inconsistent processes inside a new environment. Trying to redesign everything before addressing an urgent operating dependency can create a different problem: the business waits for the perfect future state while a live financial, compliance or integration requirement continues to constrain it.

SFL’s role in both engagements was therefore broader than configuring CargoWise.

It was to understand what the business was trying to control, where the real dependencies sat, what needed to be standardised, what needed to remain connected to external systems, and in what order the change could safely happen.

That delivery thinking is now formalised in SFL’s five-stage methodology: Discover, Define, Design, Enable and Stabilise. Discovery establishes what is genuinely running today. Definition turns that into an agreed scope, measures and governance model. Design creates the future-state workflows, finance logic, rate structures and integration architecture. Enablement moves the design through configuration, validation, training and go-live. Stabilisation measures what happens after launch and creates the path for continued optimisation. The discipline remains consistent; the depth and scope change with the operation.

These two projects show why that matters.

Client Story One: Scaling CargoWise Across a Complex North American Customs Operation

Founded in 1945, the organisation had grown into one of North America’s major customs brokerage and trade-compliance businesses, with freight-forwarding operations alongside its core customs capability. Its U.S. headquarters sits in Chicago, with air and ocean hubs in Los Angeles, New York and Norfolk, and the business operates across more than 100 strategic border points, seaports, airports and other locations.

At that scale, implementing CargoWise across forwarding could never be treated as a simple system rollout.

The business was using multiple applications around its import and export air and ocean operations. Rates and tariffs needed to be brought under tighter control. Credit checks needed to sit more naturally within the CargoWise process. Operational activity needed greater consistency across divisions. And the wider technology environment still needed to exchange information with CargoWise once the platform was deployed.

The original requirement therefore contained several projects inside one: implementation, process standardisation, rate management, credit control and integration architecture.

Before the Rollout, SFL Challenged the Sequence

The client initially wanted to progress into the implementation stages.

SFL recommended that the programme first go deeper into the existing environment.

For a smaller operation, an incorrect workflow or configuration decision may affect one team. Across a large network, the same decision can become the template replicated across branches, divisions and thousands of transactions. Correcting it later becomes considerably harder because by then it has stopped looking like a configuration choice and started looking like “the way we work.”

SFL therefore advised the client not to bypass the upfront gap analysis and solution-design work. Instead, the programme was broken into controlled minimum viable releases, allowing the business to introduce capability progressively while protecting continuity.

The important point was not simply that the rollout became phased. It was what the phasing allowed SFL and the client to decide before scale took over.

Which workflows should be common across the network? Which controls belonged inside CargoWise rather than another application? Which capabilities were mature enough to move first? What needed to be designed now so the client’s own development team could extend the environment later?

The implementation began to move from a software project towards an operating-model programme.

Creating Greater Consistency Inside the Job

One of the opportunities SFL identified was the way work moved between teams.

The client’s existing environment did not use an equivalent to CargoWise Tasks and Milestones consistently across its divisions. SFL recommended building these more deliberately into the new operating model.

That mattered because at enterprise scale, a milestone is not merely a status marker.

The right milestone architecture determines when work should happen, which team owns the next action, when a shipment has moved outside the expected process, and what information can be trusted by operations, management and customers.

Tasks and Milestones therefore provided a mechanism for introducing greater consistency into the way the operation progressed through CargoWise.

The objective was not to make every branch identical. It was to create a common execution structure where variation was no longer happening simply because each area had developed its own way of working.

Rates Needed to Move Closer to the Operation

The client also wanted to streamline air and ocean rate management.

SFL incorporated Cargoguide for air rates and CargoSphere for ocean rates into the wider design. Both platforms are specialist rate-management solutions acquired by WiseTech Global; today, their rate data also sits within the broader WiseTech rate-management ecosystem.

Rates sit upstream of quotation, margin and shipment execution. When the rate-management process operates separately from the environment where freight is ultimately executed, the business creates another hand-off between commercial decisions and operations.

Bringing that process closer to CargoWise allowed the client to build a more connected route from rate selection into quotation and execution, while reducing the dependence on separate tools surrounding the shipment process.

Credit-control requirements followed the same design principle. Where a financial control affected whether operational work should proceed, the control needed to sit close enough to the workflow to influence the decision at the right point — not become a downstream check after work had already progressed.

Integration Was Designed as Architecture, Not an Afterthought

CargoWise was also not going to operate alone. The organisation had existing technology that needed to remain part of the environment, and the client wanted its internal development team to undertake elements of the integration work.

SFL’s role was therefore to create the integration blueprint the internal team could build against.

A large organisation does not always need an external partner to own every line of development. It does need clarity on how CargoWise should participate in the wider architecture: what information originates in CargoWise, what returns to it, which system owns which data, where validation occurs, how exceptions are handled and what should happen when a connected system fails.

By designing that layer before handing development forward, SFL helped prevent the surrounding integrations from becoming a collection of point solutions built independently of the operating model.

The Outcome: Scale Without Replicating the Old Complexity

The programme moved forward through controlled releases rather than one enterprise-wide switch.

CargoWise became the foundation for more consistent operational milestones, tighter rate-management processes and greater control over important commercial and financial decisions. The client also had a defined integration architecture its own technical teams could continue to develop against.

The real achievement was therefore not simply deployment. It was creating a structure capable of expanding across the network without allowing every new branch or business unit to reinterpret how the platform should work.

That is the difference between scaling software and scaling an operating model.

Client Story Two: Connecting CargoWise Across a Multi-Country LATAM Finance Environment

The second client arrived with almost the reverse constraint. There was no room to wait until the entire future state had been redesigned.

Founded in Hong Kong in 1998, the business had built a global reputation around neutral LCL ocean consolidation. Today it operates more than 40 international locations, employs more than 1,500 people and is supported by over 200 agent partners worldwide. Its strategy remains deliberately concentrated around LCL, with a substantial presence across major trading economies including Latin America.

That operating model makes network consistency particularly important. An LCL consolidator is coordinating high volumes of shipments and partners through a service in which multiple consignments share the same container movement. As the network expands, financial and regulatory differences do not disappear; they accumulate around a common operational core.

That was what SFL encountered across the client’s Latin American business.

Operations spanning Chile, Brazil, Peru, Ecuador, Costa Rica, Guatemala, Mexico, Uruguay, Paraguay and Argentina needed CargoWise to coexist with existing financial systems and country-specific electronic-invoicing requirements. The client also wanted to remove repeated master-data entry between CargoWise and its finance environment.

This time, the greatest risk was waiting too long.

The Immediate Problem Was Financial Control

Electronic invoicing requirements were already part of the operating environment. Finance needed information to move correctly between systems. Master data was being handled across multiple applications. The client needed a workable regional solution before it needed a perfect enterprise end state.

SFL therefore reduced the first problem to the controls that mattered most immediately.

The priority became connecting CargoWise into the existing finance landscape, reducing unnecessary duplication of master data and establishing workable electronic-invoicing paths across the countries in scope.

This was defining the right first scope. An enterprise programme becomes safer when the first phase solves a clearly bounded business problem rather than trying to prove progress by touching everything at once.

One Region Did Not Mean One Regulatory Design

The complexity became clearest around electronic invoicing.

The client operated across multiple Latin American jurisdictions, but the technical requirement could not be solved by designing one “LATAM e-invoicing” connection and reproducing it everywhere.

Each country brought its own regulatory environment.

SFL therefore approached the requirement at country level while protecting a common CargoWise operating foundation.

According to the original engagement material, CargoWise functionality was used where the relevant market requirement could be addressed directly. In Argentina, for example, SFL configured the available CargoWise e-invoicing capability. For other requirements across Brazil, Paraguay and Uruguay, SFL applied existing solution components to bridge the local requirement.

The architecture had to accommodate local variation without allowing every country to become an entirely separate systems project.

That is a much harder problem than simply connecting two applications.

It requires the team to decide what should remain standard across the region and where local compliance genuinely requires a different path.

The Finance Integration Needed a Clear Data Owner

The second part of the problem sat between CargoWise and the client’s financial software.

The stated goal was simple: master data should not have to be recreated manually in multiple systems. But reliable integration requires more than moving the same information from one database to another.

Customer records, vendor records, financial codes and other master information influence everything that happens downstream. If two systems can independently alter the same record, the business quickly loses certainty over which version should govern the transaction.

The architecture therefore needed a clear rule for where information originated, where it was consumed and how changes moved between systems. For this client, reducing duplicate data entry was therefore only the visible benefit.

Solving the Immediate Constraint Changed the Next Question

Once SFL had helped the business address the immediate integration and electronic-invoicing requirements, the client did not stop at the local fix. It decided to step back and assess its broader CargoWise environment from the ground up.

At the beginning, the business needed to know: How do we make these critical financial and compliance processes work now? Once that pressure had been reduced, it could ask the larger question: How should the whole CargoWise environment work if we design it properly?

That progression is what makes this much more than an integration story.

The urgent work created enough operational stability for the organisation to move from solving individual constraints toward examining the operating model as a whole.

Two Different Starting Points. One Transformation Principle.

Placed beside each other, the projects look very different.

The North American customs broker had a wide enterprise scope and needed SFL to slow the programme down at the beginning — not because the business lacked urgency, but because design decisions made before a large rollout become extremely expensive to reverse once they are embedded across the network.

The LCL consolidator faced the opposite pressure. Its Latin American operation had live finance and regulatory dependencies that could not wait for the whole environment to be reconsidered. SFL therefore narrowed the immediate scope, solved the highest-priority control problem and then created room for the broader transformation to follow.

But underneath both engagements, the same principle was operating.

Do not let the size of the technology determine the sequence of the transformation. Let the operating reality determine it.

That is also the logic behind SFL’s current 5D methodology.

• Discover before assuming.  

• Define the scope that genuinely needs to move.  

• Design the operating model and the integrations around it.  

• Enable the change through configuration, validation and the people who will actually run it.  

• Stabilise what has gone live before assuming the programme is finished.

For one client, that meant widening the work before deployment. For the other, it meant deliberately narrowing the first problem before widening the transformation.

The methodology provides discipline. It should never remove judgement.

Why SFL Tech

SFL Tech works specifically within the CargoWise ecosystem, across implementation and optimisation, integrations, supply-chain transformation and post-go-live managed support. That breadth matters because large CargoWise programmes rarely stay inside the boundary where they first appear.

A forwarding implementation exposes a finance dependency. A rate-management project affects margin governance. An integration requirement becomes a data-ownership problem. A country rollout introduces a local compliance requirement. A successful go-live exposes the next layer of optimisation.

SFL brings those decisions together instead of treating them as separate technology projects.

The current delivery model formalises that through one operating-model methodology that scales from individual module or entity engagements through to multi-country and global programmes.

For the North American customs broker, that meant protecting a large rollout from becoming large-scale inconsistency. For the global LCL consolidator, it meant protecting an urgent regional requirement from becoming the architecture the business was forced to live with forever.

Different pressures. Different sequence. The same objective: make CargoWise work as part of the business, not merely inside the business.

Building or Reworking a CargoWise Environment?

Whether the priority is a new CargoWise implementation, a multi-country rollout, finance and rate alignment, ERP integration, electronic invoicing or an environment that has grown beyond its original design, the strongest starting point is rarely another configuration request.

It is understanding what the operation needs the platform to carry.

Talk to SFL Tech about your CargoWise operating model →

FAQs

What is SFL Tech’s approach to CargoWise implementation?

SFL structures implementation around five stages: Discover, Define, Design, Enable and Stabilise. The process begins with the existing operating environment and success criteria before moving into future-state architecture, configuration, validation, role-based enablement, go-live and continued optimisation. The depth of the process scales with the complexity of the business.

Can SFL integrate CargoWise with existing finance and external systems?

Yes. SFL’s integration work spans external finance and ERP platforms, APIs, EDI, middleware and other connected environments. The important design decision is not simply whether two systems can exchange data, but which system owns each data type, what validation is required, how exceptions are handled and where the information should influence the CargoWise workflow.

Does an enterprise CargoWise rollout need to happen all at once?

No. For large or complex organisations, a phased approach can reduce operational risk and allow the business to prove the design before extending it further. The North American engagement in this case was deliberately structured around controlled releases rather than trying to satisfy the full enterprise scope in one movement.

What happens after CargoWise goes live?

Go-live is not treated as the end of the implementation. SFL’s current methodology includes a Stabilise phase focused on adoption, issue resolution, KPI measurement, continuous improvement and the roadmap for the next stage of the environment.