We build a layer that plans the shipment, assigns the vehicle and the route, compares carriers and freight rates, issues the e-waybill and collects proof of delivery from the field. If you run your own fleet, fuel, maintenance and document costs accumulate in the same system; if you work with hauliers, a record is kept of which job went to whom and at what price.
In most factories, dispatch is work that begins where production ends but has no full counterpart in any system. When an order is ready, someone picks up the phone, calls the hauliers they know, asks for a price and arranges a vehicle. Which job went to whom and for how much sits in an Excel file, sometimes only in that person's notebook. When the vehicle arrives the waybill is written by hand, the goods are loaded, and from that moment the shipment becomes invisible; when the customer calls to ask, the answer is again found by telephone, by ringing the driver. At the end of the year, the answer to how much was paid for transport is the sum of the invoices in accounting. Nobody can break down how much transport cost was carried by which customer, which route and which product. Yet transport is a visible line in the unit cost of most products, and when a price is quoted it is glossed over with a guess.
In this area two separate jobs are often called by the same name and get confused. Transport management, that is TMS (Transportation Management System), manages the haulage itself: which orders will be consolidated onto the same vehicle, which carrier will take which job at which freight rate, when the vehicle will be loaded, on which day the goods will be delivered. Fleet management, by contrast, is about running your own vehicles: fuel consumption, maintenance and tyres, inspection and insurance dates, driver licences and cost per vehicle. A company without vehicles of its own does not need fleet management but does need a TMS; a company that distributes with its own fleet needs both. We design these two sides as a single system, but keep them separated so that they can be rolled out independently.
The layer we build does not replace your existing ERP; it begins where that ends. Order, stock and invoice records stay in Logo, Mikro, Netsis (Turkish ERP and accounting products) or whichever system you use. The TMS layer reads those orders, turns them into dispatch orders, produces the vehicle and route plan, assigns the job to a carrier and writes the delivery result back to its source. On the driver's side there is a mobile screen: loading, delivery, signature, photograph and the reason for a failed delivery are entered there. That record lands in the system as proof of delivery, that is POD (Proof of Delivery). So whether the goods were delivered is answered from a screen rather than by telephone, and in disputed deliveries you hold a dated, signed, photographed record. Picking and packing inside the warehouse sits outside this; the TMS manages what happens outside the gate.
Expectations need to be set in the right place from the start. Route optimisation is the most overhyped heading in this field: the system can produce a mathematically good sequence, but it cannot fully model traffic, a vehicle waiting at the gate, the customer's goods-in hours or the driver's knowledge of the ground. We therefore set optimisation up as a suggestion rather than an instruction; we ask the planner to intervene in the plan and to record the reason for intervening. The second reality is address data. In Türkiye a significant share of customer addresses is held as free text and does not land on the right point on the map; address cleansing is the invisible but longest-running part of the work in most projects. The third is acceptance on the driver's side: a driver who does not use the mobile screen can render the whole system useless on his own.
Companies sending goods to dealers, branches and end customers in their own trucks, lorries and vans. In these businesses the real loss accumulates in vehicle fill and empty return legs; fuel, maintenance and document expiry dates, meanwhile, are usually tracked in places that know nothing of each other. Being able to calculate cost per trip and to see where a vehicle is during the day are the first two things these companies look for.
Businesses with no vehicles of their own, calling hauliers and asking for a price for every shipment. Here the gain starts with putting the carrier pool, agreed route tariffs and the jobs awarded on record; whether the freight invoice matches the price quoted becomes possible to check regularly for the first time. Choosing a haulier stops being something held in one person's memory, and price history accumulates in the organisation.
Food, packaging, building materials and distribution companies that repeat the same routes several times a week. On repeating routes the plan can be tied to a template, delivery times can be measured and it becomes possible to see at which stop the delay occurred. Whether the delivery promise given to the customer is kept is the thing sales argues about most often in these companies, and it can only be settled with records.
Haulage and logistics businesses that sell transport to their own customers. In these companies, when the job order, the vehicle assignment, the subcontractor cost and the price charged to the customer do not meet in the same record, profitability per trip cannot be calculated. The system's first concrete benefit is seeing which customer and which route actually make money; the second is being able to give the customer proof of delivery without hunting through files.
Ready orders turn into dispatch orders; loads going to the same region are combined onto a single vehicle within weight, volume and pallet constraints. The planner sees vehicle fill on screen before loading. Urgent jobs are separated from jobs that can wait, so the decision to send out a half-full vehicle is made knowingly rather than by guesswork. Different orders going to the same customer are gathered into a single shipment.
Stops are sequenced on the map, distance and estimated duration are calculated, and the customer's goods-in hours are defined as constraints. The system proposes a sequence; the planner can change it and the reason for the change is recorded. We do not make the proposal binding, because the person who knows the ground is usually right. As the record of which proposal was changed and why builds up over time, the rules are corrected against the real field.
The hauliers you work with, agreed route-based tariffs and one-off spot price requests are held in one place. The prices received for a shipment are compared, the job is assigned, and the freight invoice that arrives later is matched against the price quoted. Amounts that do not match are put in front of you as a list. A history of delays, damage and cancellations accumulates per carrier; performance enters the decision alongside price.
A waybill is produced from the dispatch order; if you use e-waybills it is connected to the GİB (Turkish Revenue Administration) flow. Vehicle, driver and number plate details are carried onto the document. On multi-drop deliveries the record holds which waybill belongs to which stop, so the returning paperwork does not get mixed up. Additional documents required on export shipments are added to the flow, and a vehicle leaving with a missing document raises a warning. The waybill number is tied to the dispatch record and can be searched later.
The driver sees the day's stops in order on his phone; at each stop he marks delivery, partial delivery or the reason for a failed delivery, and attaches a signature and a photograph. The app works offline and sends the data once it is back in coverage. Proof of delivery, that is POD, is linked to the order record and becomes searchable afterwards. In disputed deliveries the date, time, location and signature sit in the same record.
If you have an existing GPS or telematics device, its location data is connected to the system; if not, the driver's mobile app produces status information. The customer can be told that the shipment has left and given an estimated arrival window. This notification directly reduces the where-are-my-goods calls reaching sales and customer service. Which channel a notification goes out on and which customer receives it are defined separately.
Fuel, maintenance, tyre, insurance and repair records accumulate per vehicle; advance reminders are raised for inspection, insurance and driving licence expiry dates. Cost per kilometre and per trip is reported. As a result, whether hauling with your own vehicle or buying it in is cheaper is argued with data rather than guesswork; the vehicle renewal decision rests on the same record.
We follow step by step what happens once an order is ready: who plans, how a vehicle is found, where the waybill is issued, how delivery is confirmed. The split between your own fleet and external hauliers becomes clear. Scope is narrowed in this meeting; rather than building everything at once, we start with the link that hurts most.
Vehicle, driver, carrier and tariff lists are put in order; customer addresses are verified on the map and delivery hours are recorded. This step takes longer than expected in most projects and generally runs to between two and four weeks. No route plan made before the address data is corrected will be reliable, which is why we do not recommend cutting this part short.
Dispatch orders, load consolidation, route proposals, carrier assignment and freight records go live. The ERP connection is set up and the waybill flow is connected. For a period the planner works both the old way and with the system; the difference between the two outputs is examined one by one and the rules are corrected against those differences. If this parallel period is skipped, the team will not trust the system.
The mobile app goes into the field with a limited number of vehicles and on a single route. The screen is simplified together with the drivers; offline behaviour is tested under real coverage conditions. The pilot generally lasts three to six weeks, and by the end of that period it is clear whether the proof-of-delivery flow is reliable. If the result is not good, scope is not widened.
The remaining vehicles and routes are brought on in stages; freight reconciliation, fleet cost and delivery performance reports are opened up. Handover to your team takes place and what to do in which situation is left in writing. Afterwards monitoring continues under maintenance; as the process or the routes change, the rules are updated together. Adding new vehicles and carriers is left as a job your own team can do.
It can, but we will not quote a figure in advance, and we suggest you treat with caution any proposal that does. The gain depends on how good your planning is today; on routes built by hand by an experienced planner the improvement may be limited. On the other hand, being able to measure vehicle fill, empty return legs and cost per trip for the first time produces a gain in almost every company. We suggest you set optimisation up not as a savings tool in its own right, but as a measurable planning discipline.
Yes, and in fact the benefit shows up faster in that case. Without opening the fleet management side at all, we set up transport management only: the carrier pool, route tariffs, requesting and comparing prices, assigning jobs, delivery tracking and freight invoice matching. In most companies the first concrete result is seeing that different prices were paid for the same route at different times. If you buy your own vehicles later, the fleet side is added on top of the same system.
No. This layer does not replace the ERP, it works alongside it. Order, stock, account and invoice records stay in the system you use; we read the orders that turn into shipments, run the planning and field side, and write the delivery result back. We connect directly to systems that have an API; for those that do not, we decide together during discovery between file transfer and database-level integration methods. Fixing the dispatch side on its own, without embarking on something as large as an ERP replacement, is possible in most companies and produces results faster.
This is the most real risk in the project, and it is not a technical one. That is why we keep the driver screen to a minimum: a few taps at most during the day, large buttons, no obligation to type, offline working. We run the pilot together with the drivers and simplify the screen according to their objections. On devices, either a company phone or installation on the driver's own phone is possible. An app that is not used does not count as delivered.
No, it does not, and we say so plainly. Operating licences, U-ETDS (the Turkish transport tracking and inspection system) reporting obligations, dangerous goods (ADR) rules, tachographs and driving-time enforcement are matters that carry legal liability and are the company's own obligation. What we do is hold the data these processes need in an orderly, exportable form and raise reminders for document expiry dates. Interpretation of the regulations and liability in the face of an inspection do not pass to us; in this area you need to work with a specialist in the subject.
A planning screen with dispatch orders and load consolidation; route proposals and delivery sequencing; a carrier pool, tariffs and freight invoice matching; the waybill and e-waybill flow; a driver app that works offline, with signed and photographed proof of delivery; if you have your own fleet, fuel, maintenance and document tracking; cost reports by trip and by route. Everything, including the source code, the documentation and the dispatch data that accumulates, belongs to you.
In a 30-minute discovery call we listen to what you need and tell you honestly whether custom development or an off-the-shelf product is the better answer.
We gather orders from your e-commerce site, marketplaces, the B2B dealer portal, the showroom and the telephone into a single pool. Stock is promised from one source rather than divided up channel by channel; the allocated quantity comes off it, and cancellations and returns come back into it. The aim is not to sell the same item twice, and to see where an order stands from a single screen.
Details →We gather all of a product's attributes, descriptions and translated texts in one centre, and produce the enriched version for each sales channel's own template from there. A field that is missing or breaks a rule is caught before the product goes out to the channel. Product data no longer lives in a file on somebody's desktop.
Details →We bring photographs, video, catalogues and design files together in a single archive, and record which product each file belongs to, which version is approved and where it may be used. The sizes and formats each channel asks for are derived automatically from the original, so nobody spends their time resizing files.
Details →We bring the store's till, stock, promotions and shift handover together in a single system. The POS here is not the virtual POS on your website; it is the real till on the counter. In multi-branch structures, prices and promotions are managed centrally and the day closes with the same discipline in every branch.
Details →We turn the production plan into a sequence at machine and line level: tooling and set-up times, bottleneck capacity, the date material will be ready and priority rules are calculated together. The result is a schedule that can genuinely be applied on the shop floor and a defensible due date that can be given to the customer.
Details →We bring production, quality, maintenance and inventory operations together in a shared data model. The same stoppage, the same lot and the same shift meet in one record instead of four separate places; shift handover is put in writing, and management looks at a single set of indicators.
Details →
