Custom Simacan Control Tower API integration
A control tower shows you where your shipments are and whether they will arrive on time, even when they are carried by different carriers. It gives you visibility you cannot build yourself. But it only delivers value if the planned routes you feed into it are accurate, and if someone acts on a deviation.
What a control tower does and does not solve
The problem a control tower addresses is fragmentation. Your goods travel with several carriers, each with its own system and its own way of reporting status. The receiving location, whether a shop, a distribution centre or a customer, wants one answer to one question: when will it arrive. No single carrier can give that answer alone.
A control tower brings together planned routes and actual positions and calculates an expected arrival time. That is valuable, and it is also exactly where expectations go wrong: the quality of that expectation depends on what you put into it. A plan in which the stops are in the wrong order, or in which loading and unloading times are assumptions, produces a precise-looking ETA that is consistently off.
The second point is what happens when something deviates. A notification that a route is running twenty minutes late is information; it only becomes value when someone calls a store, shifts a time window or changes a sequence. In most integrations we come across, the technology isn't the bottleneck; the question is who reads the alerts and what they are allowed to decide. For what applies to transport data where personal data is involved, see the Dutch Data Protection Authority (Autoriteit Persoonsgegevens).
How we build this
The starting point is the route as it originates with you, and the question of who will respond to a deviation later on. Without that second answer, you are building a dashboard.
Where the plan comes from, how complete it is, and what is an assumption: stop sequence, loading and unloading times, time windows at the receiver. This determines the quality of everything that follows.
Who sees a notification, what they are allowed to decide, and who informs the receiving location. This is an organisational question, and we answer it before we build, not after.
Every sprint ends with something you can verify yourself, and we start with delivering planned routes and retrieving status. Passing this through to your own systems comes after that.
We compare predicted arrival times with actual ones over a real week. Where they consistently diverge, the cause almost always lies in the planning rather than the prediction.
What the integration actually does
Exchanging routes and statuses is the foundation. What you do with a deviation afterwards determines whether the rest has value.
Supplying planned routes
Routes with stops, sequence and time windows from your own planning or TMS, in the format the control tower expects. Exactly what can be exchanged is established during discovery; we don't promise an integration before we have seen the interface.
Progress and expected return arrival
Status per stop and an expected arrival time sent back into your own systems, so your customer service team and your sites don't need to look at a second screen.
Deviations with an owner
An overrun or a missed stop becomes an alert with a person responsible and an expected response, not a line in a report. Without that step it stays a dashboard that nobody opens after three weeks.
Translation for the receiving site
A store or customer doesn't want route information, they want a time. That translation, including what you do and don't communicate when a delay occurs, is a decision you make and that we document.
Feedback to planning
Making structural deviations per stop or per location visible, so loading and unloading times are adjusted to what actually happens. That is where accuracy over time comes from.
History kept per route
What was planned, what happened and when who was informed. In a dispute with a carrier or a customer, that is the only usable source.
Who we build for
Your position determines whether you hold the planning in your own hands or receive it delivered. Four situations.
Retail with own distribution
Fixed store routes with tight delivery windows and staff waiting for the delivery. Here a reliable arrival time directly saves labour hours. If you also drive the final kilometres yourself, see last-mile delivery software.
Shippers with multiple carriers
Your goods travel with different parties using different systems. Bringing it together is the whole value, and it is exactly what you don't want to build yourself. The planning itself often runs through a WMS or your ERP.
Producers with inbound flows
Not only outbound but also inbound: when does the raw material arrive at the gate. If a weighbridge or site access is involved, that belongs in the same flow; see access control and weighbridge.
Carriers reporting to shippers
You supply the data and are measured on it. Your interest is that what you pass on matches what your own systems say, because otherwise you argue about figures instead of performance.
Technology and integrations
Position data arrives continuously, so this is a stream and not a daily batch. The data concerns vehicles driven by people, which makes the privacy side weigh more heavily than in an ordinary integration.
Why Appfront
The forecast is only as good as your planning
An accurate-looking arrival time based on the wrong stop sequence is misleading. We start with the quality of what you supply.
An alert without an owner is a dashboard
Visibility only delivers value when someone is allowed to intervene. We answer that question before building.
The recipient wants a time, not a route
What you see internally is not what a store or customer needs. The translation is a design choice of its own, not a by-product.
Honest about what we don't know
There is no partner relationship with the supplier. What is possible via the interface is established during the discovery phase, and we don't promise anything we haven't seen.
Security and privacy
Trip data may look like business data, but it isn't entirely so. A vehicle is driven by a driver, and continuous position data also reveals where that person is, how long they stop somewhere and how they drive. That makes it personal data, even if that isn't your purpose. We therefore separate the operational view from anything that can be traced back to individual behaviour, and keep the retention period for raw positions short.
If you work with a works council or with employed drivers, introduction is something to discuss in advance, as tracking systems touch on the monitoring of employees. With contracted carriers, confidentiality between parties comes into play: one carrier should not be able to see how a competitor performs on the same route. Separation per party is therefore a design requirement. We also keep, per trip, what was planned, what happened and when who was informed, because in a dispute over a missed delivery that is the only usable source. How we handle security ourselves is set out in our information security policy; reports from outside come through our vulnerability disclosure policy.
Frequently asked questions about a control tower integration
Your TMS knows your own planning; a control tower brings together trips from multiple carriers and calculates a single arrival estimate from them. If everything runs with one carrier in one system, the added value is limited. If your goods travel with four parties that each report differently, bringing them together is exactly what you don't want to build yourself.
Usually not because of the forecast, but because of the input. A stop sequence that differs in reality, or loading and unloading times that are assumptions rather than measurements, produce a precise-looking time that is structurally off. That's why we build the feedback loop: actual times per location feed back into the planning.
That depends on the interface available for your situation and your contract. We are not a partner of the supplier and won't promise an integration before we've established what is possible. That assessment is the first step; contact with the supplier runs through you, as you hold the contract.
That is the most important question, and it is organisational rather than technical. A deviation nobody reads changes nothing. We therefore build notifications with an owner and an expected response, and agree in advance who informs the receiving location. Without that, it becomes a dashboard nobody opens after three weeks.
Yes, but not in the same form. A store wants a time, not trip information. Passing it on is a design choice in its own right: what you communicate when there is a delay, from which deviation onwards, and what you keep internal. Those choices determine whether it builds trust or simply generates more phone calls.
Continuous position data is personal data, even if your interest lies in the shipment. We separate the operational view from anything that can be traced back to individual driving behaviour, and keep the retention period for raw positions short. For employed drivers, this is also a matter for your works council.
Then that stream drops out of your view and you have a partial overview, which is sometimes worse than none. This is a procurement conversation rather than a technical problem: supplying trip data belongs in your transport agreements. We do make visible which part of your volume is and isn't covered, so you know where you are blind.
That depends on the number of carriers, the quality of your planning, and whether the information needs to be passed on to stores or customers. Exchanging trips and statuses is usually the smallest part; feeding back into planning and customer communication cost more. We provide a reasoned estimate after the discovery phase. Connecting to your TMS is done via integrations.
Ready to build a control tower integration?
Tell us how many carriers move your goods and who gets called when a delivery is late. The second answer usually reveals the real project. We build this as part of a broader custom software development project or through smart API integrations.