A groupage carrier plans its drivers in an Excel file. One file per calendar week, on SharePoint. Over the last 60 days a converter read that file 2,878 times. 2,870 of them clean. Every time, an import file went to the TMS. No dispatcher retyped a single shift.
That is the number. The story behind it is the dispatch plan Excel TMS import as it runs in practice. Including the places where it stopped this summer. And the reason Excel stays the source.
The dispatch plan is a grid. Rows are trucks. Columns are days. The cells hold drivers and shifts, T for day, N for night. Dispatchers maintain it. Shift leads read it. Drivers work by it. It is the truth about next week.
The TMS, in this case WinSped by LIS, does not know this plan. WinSped takes orders through the LISIN interface. Also through converters for FORTRAS, IDS or IFTMIN. And through web entry. For drivers and shifts from an Excel file there is no standard channel. The rest is manual. Retype it, on every change.
This is not a single case. In November 2025 Strategy& and the BVL surveyed 115 logistics providers. 96 percent have started their digital transformation. 10 percent scale it. The BVL study Trends and Strategies from October 2025 names the reason. 54 percent of respondents see data as the biggest hurdle, availability and quality. The dispatch plan is exactly that kind of data problem. The data exists. It only sits in a cell.
We did not touch the plan. We read it.
The converter runs every 30 minutes. It pulls the current weekly file from SharePoint. Then it looks for the header row. It searches rows 1 to 8, because the file carries date rows at the top. It needs two labels in the same row: the truck column and the shift column. If it cannot find them, it stops. On purpose. An import with shifted columns is worse than no import.
Then the drivers. The plan holds names. The TMS needs personnel numbers. The converter looks up every name in the driver list, in four spellings. Last name first, first name first, with the full first name and with the first part of it. If it finds two people, it leaves the number empty. The report then says "driver ambiguous".
On 15 June the run stopped for the first time. Cause: Excel delivers the personnel number sometimes as a number, sometimes as text. 1016 and "1016" counted as two people. The fix is one line: every number gets the same type before the comparison. It sounds trivial. Without the fix the TMS would have received the number as text. (Excel is less a data format than an opinion about data.)
Since 11 June the finished import file goes by mail to an import mailbox at the customer. The TMS collects it there on its own. No network drive, no interface, one mailbox. Before sending, the script checks the age of the file. Older than 28 minutes, it does not go out. Otherwise a silent failed run would resend the old file.
On 1 July the night shift joined. An N shift starts at 22:00 and ends at 05:00. The end falls on the next day. Since then the converter writes two lines: start on the day, end on the day after. On the first day that was 37 day changes in one weekly file.
Three incidents in ten weeks. All three sit in the protocol with a timestamp.
On 23 July at 07:30 the run stopped. Error: header row not found. We compared two versions of the file. The only difference: cell B3 was missing the word "LKW". Someone had deleted the label. All data was there. Four runs stood still, until 09:00. Since then there is a fallback. If the word is missing, the converter finds the truck column by content. It sits between department and shift. It holds almost nothing but numbers. The fallback run delivered 2,230 lines, bit for bit identical to the run with an intact header.
On 27 July it stopped again. This time a date. One cell in the date row held no time but the number 6125. Excel stores dates as a count of days since 30 December 1899. The converter only knew dates and text. Two runs, then the fix: numbers within the date window get converted, nonsense gets skipped.
On 27 and 30 August the connection to SharePoint dropped. Once per day, early in the morning. The next run was green. The converter had no retry. Now it has three, with 5 and 15 seconds of pause. And a rule for series: the first failed run is a warning without mail. From two in a row, the mail goes out with a counter. Before that, the person on duty got a message for every network hiccup.
That is the balance of this phase: 7 failed runs and one warning out of 2,878. Two incidents came from the file, one from the network. Each case now has a path.
The mail dispatch happened 2,872 times in 60 days. 2,753 times without a change. 119 times with changes. Together 33,185 changed lines. The delta shows when the plan is alive.
Every week there is one big jump. Around 2,900 to 3,400 lines at once. That is the new weekly file. On top come 9 to 17 small changes per week. And every one of them falls between 08:00 and 18:00. Nobody changes the plan at night. The 30-minute cycle keeps running anyway. It costs nothing. And a silent failure in the morning would otherwise surface at noon.
An honest caveat: this is the data of one customer. One weekly plan, one TMS, one mailbox. What the delta looks like with daily planning, we will only know with a second protocol.
For dispatch, nothing. That was the condition. They open the same file and enter the same shifts. The difference sits behind the file. Every change is in the TMS within 30 minutes at most. Before, that depended on the person retyping. And on the moment they did it.
For drivers it means: the TMS knows the same shift as the plan. Including the night shift, including a swap in the afternoon. For billing: the personnel number sits on the order, as a number, not as text.
And the report is the side effect nobody had before. Every line the converter cannot assign with confidence appears there with a reason. Driver ambiguous. Shift without time. Day change. That is the list dispatch uses to clean up its own file. More on our logistics processes.
A script that reads SharePoint through a browser session. An Excel converter with header search and fallback. A driver list as lookup. A delta against the last state. A mailbox at the customer. One protocol line per run. No change to the TMS, no change to SharePoint.
Which file in your dispatch office is the truth, and who retypes it? Send me an anonymised header row. I will tell you whether the converter recognises it on the first run.
