Burak Köken

A veteran developer's honest ledger.

One Application, One Dispatcher

Published

The desk, digitised

I talked about how calls from customers for package pickups were handled in The world before the handhelds. The room with four ladies, small note papers piling on the corners of the desks and the Dispatcher aka D-guy walking around to pick them up. This piece is about him, who ran the business using them and with a wireless to direct the drivers where they were needed, uplifted by me (by the application I developed for him, actually)

A few things happened all at once as the company received the call for a pick-up from a customer. Depending on whether it is a returning customer or a new one, either enough information to go and actually pick-up a package is recorded in the Customer database for the new customer and the details of the call attached, or for a returning customer only the call details were recorded. One small magic happened after that step: Since the address of the customer is known at that point, the system used its knowledge of zones and drivers assigned to these zones and recorded a “candidate” assignment, to ease the D-guy’s job. That is the first of many parts I was trying to help him with. He no longer had to rely on his “memory” for driver assignments, he starts with a pretty good suggestion and accepts or rejects it when it is in front of him.

The Christmas Tree

I was at a Naval Submarine Base during my military service. It was pure luck: I was very interested in submarines and still am. I have a shelf dedicated to fiction and non-fiction books about them, I collect movies about them. When I was designing the UI in front of D-guy, I was inspired by the “Christmas Tree” board on a World War II submarine. It was an indicator light panel in the Control Room that shows whether hatches, vents, and valves are open or closed. The panel earned its festive nickname because it lit up with glowing red and green bulbs like a holiday tree; before the submarine could submerge, every red light had to turn green. D-guy should see the city and the drivers on his Christmas Tree, glowing green and red, so he can intervene.

It worked like this: Every zone was a cell in a grid in the application. The drivers were stacked in the cell (various sections of the submarine were grouped together). For a driver with no assignment, the color for him was Teal. If he had assignments, the color was Maroon and numbers appeared, how many he visited yet, how many more, etc. The color changed to red if he missed a timed visit.

You can imagine, you cannot fit all you want to say about a zone with many drivers in a mere cell. That required a wider space. Another part of the UI supplied that. For example, there were three timestamps for each assignment: The time that the call was assigned to the driver, the time it was pushed to his handheld terminal and the time he acknowledged the assignment. The last part was actually “Okundu”, read in English. The driver was not always looking at the screen: he may be driving, he may be delivering, he may be on a lunch break. He had to tap the assignment and actively mark it “read” so D-guy knows the driver is aware. That also helped to understand if the driver is stuck somewhere away from his terminal, for a long time.

Every pipeline needs its fallbacks. Assume the handheld’s battery drained or it malfunctioned in the field or accounting forgot to pay for the cellular plan. So the driver reached D-guy, and got the assignments on the phone. Somehow, D-guy must clear his board, managing the reds. There was a way he could do just that. He was able to mark assignments “read” by manually flipping their state, himself.

May I have your Attention, please

D-guy had a lot to say, he was running the city after all. It is like he was replacing the two big wireless antennas at the top of the HQ himself. Sending a message to handhelds was different than shouting from a roof top with wireless. He had options.

Message size was capped at 250 characters, text only. When Twitter came, later, it was 140.

Everybody had to respond: The acknowledge came in two pieces. The timestamp it was marked “read” and the ID of the reader, obtained from the login credentials to the device. It was necessary, handhelds can change hands (sorry for the pun). If you wanted to have proper logs dating a while back, who marked that particular message as “read” was important.

Let Me Update you with the Latest

The Diving Officer’s Christmas Tree in the submarine was mechanical, nobody had to push buttons or pull levers to update the lights. D-guys Christmas Tree was different, in fact different from most Dashboards you use today that refresh themselves periodically. The application I built had one and only one timer. It displayed the time elapsed since you last refreshed the view, manually. It was a “count up”. It showed how stale D-guy’s view was. Very simple reason and you probably thought of it, too. D-guy was working the tree, watching the state, sending messages. Maybe having conversations with drivers on the phone when 250 characters could not hold a proper conversation. He needed the static board he could analyze at will, not a quicksand of blinking colors on so many cells. The view was frozen in time until the point he needed a refresh, not a moment too soon. He watched the count up tick until the urge to press F8, the manual refresh button, became unbearable.

The application did more with time. It checked the time on the SQL Server it is connected with against the host clock. Just to be sure. Because handhelds did the same thing, too. Whenever they communicated with the backend servers, they made sure they are in sync. Another trick: The application had a hook to WMTimeChange message from the operating system. If a “his intentions were not malicious” user tried to change the host clock to timestamp something, ehem, “differently”, it was not blocked but detected and logged. Our job was to keep you honest, thank you.

The Driver had Rights, too

Yes, he could reject an assignment. Maybe it was not in his area of responsibility, addresses did mix up. Maybe the load was so high, he could not visit on time and it was better to re-direct someone else rather than have a “not so pleasant” discussion with the customer. Whatever the reason, the driver had the option to send the assignment back to D-guy, with a reason AND a suggestion for another driver. All there.

It followed protocol. Two “Are you sure?” on D-guy’s side. The count of a call “redirected”, logged. The driver could, in fact, just ask the D-guy with another means, maybe a mobile phone, for an assignment revoked so it disappeared from his work load list. It was D-guy, he could do all this and in extreme cases, he could cancel the call completely.

The driver had his moments, too. The customer called and booked a pickup at 16:00. She called again at 15:30 and said, “I can’t have the package ready, let’s push it to 18:00”. Then called again, “Make it tomorrow at 10:00”. All this was reflected on the driver’s handheld until the time crossed the midnight line. At that point it disappeared and reappeared the next day, in front of whoever was responsible for it. The application NEVER deleted and created a call with changed info. It was designed so that the unique ID it was given the moment it came to life stayed the same no matter what and only the bits, the timestamps that govern the flow changed. Unlimited rounds: A package could stay in this imaginary (because no one has seen it yet, until the customer actually handed it over to the driver) flow for days, if needed.

Sorry, We did Everything We could

Obviously there were times when the system cannot reliably assign a call. Various reasons. A mismatch between the typed in address and the actual “zone map” of the city in the database. It was D-guy’s skill that filled the gap and the application helped in every way it could. Displayed the zones, the addresses, he only scanned and picked. There was a list of calls in zones with no active handhelds at the moment. A new zone, a driver in orientation, no handhelds, or it was broken or lost or stolen. The drivers had 5 digit numerical IDs, when I started with the company, the first two were the license plate number of the city: Istanbul was 34, my ID was 34999. The guy where everything ended, the last say in development. I am joking, I did pick up an ID for myself to make my test rows in the database stand out and if I am remembering correctly, the application had filters not to process and send out those test rows to the field. At least the first few iterations. Later HR assigned 9 character IDs to everyone. It was too much. D-guy, on wireless, even omitted the first two and called out “345, 345, you have two incoming”. Out of respect to his craft, I recorded the HR IDs in the database but displayed the 5 digits on the screen. Or just the 3. Honestly I do not remember, I cannot testify under oath.

Help went the other way, towards the customer, too. Say, you are shipping every day, mostly at the same time: You are a textile manufacturer and sending samples every day or every Tuesday and Friday, whatever. We would not burden you with a call, day after day, for something happening regularly. I kept a list of “automated visits list” in the Customer Database. The list went out to the drivers, every morning. Then they became “regular” calls (with the different birth mark preserved, of course) and flowed in the pipe, happily. Only D-guy and the driver knew it did not come from a call. Or the supervisor checking the reports where they were clearly marked.

One Application, One Dispatcher

This is most of the story of how the machine’s decision became the default and the man’s job became the exceptions.

There are many little bits and details, more where this came from. When I sat down to write this, I gave free rein to the AI assistant on the code from my archives. After each paragraph, it dived in and fact-checked what I remembered. Mark Twain said, “When I was younger, I could remember anything, whether it had happened or not; but my faculties are decaying now and soon I shall be so I cannot remember any but the things that never happened”. AI agent helped me and at the same time compiled facts from my own code I was not able to remember after 20+ years. I cannot express my joy as memory surfaced, just like the submarine after long hours, even days, and the sailors breathed the cool breeze.