Dispatch Dashboard Monitor — Sierra Active Pilot

Inspiration

The project was inspired by the amount of manual work required to monitor Sylectus load offers, identify suitable drivers, calculate deadhead distance, verify customers, contact drivers, and track responses.

Dispatchers were switching between the Sylectus load board, the driver address book, routing tools, factoring systems, messaging platforms, and internal notes. During busy periods, this made it easy to overlook an offer, contact the wrong equipment type, duplicate work, or lose track of a driver’s response.

We wanted to build a single local dispatch workspace that would support the dispatcher without removing human control. The goal was not to automatically accept loads or make final dispatch decisions. The goal was to collect the relevant information, perform repetitive checks, and present everything clearly so the dispatcher could make faster and more accurate decisions.

What it does

Sierra Active Pilot is a local Windows-based dispatch dashboard that monitors Sylectus load offers and helps Sierra’s dispatch team match those offers with available drivers.

The system can:

• Monitor the Sylectus load board for new and updated offers.
• Capture pickup, delivery, mileage, equipment, weight, pieces, customer, timing, and offer information.
• Prevent duplicate postings from cluttering the dispatcher’s pending queue.
• Group multiple broker postings for the same shipment.
• Match offers with potentially suitable drivers based on equipment, availability, location, and deadhead distance.
• Calculate road-based deadhead mileage using a local offline OSRM routing system.
• Display pending, waiting-for-driver, expired, passed, and skipped offers in separate groups.
• Allow the dispatcher to review the original offer before contacting a driver.
• Generate a standardized driver-facing load message.
• Allow the dispatcher to edit the message before sending it.
• Send messages through Emitrr and display the sending, sent, or failed status.
• Receive driver replies through the Emitrr API and inbound webhook integration.
• Display unread message indicators for offers and drivers.
• Run customer factoring checks and visually display the result.
• Show driver availability, vehicle information, cargo dimensions, notes, and last update time.
• Provide debugging tools for manual scraping, matching, and system-status checks.

The dispatcher remains responsible for reviewing every offer and choosing whether to send it, pass it, or skip it.

How we built it

The application was built as a local Python-based system running on a Windows computer.

The main components include:

• Python for the application logic, monitoring, matching, API communication, and database operations.
• Flask for the local dispatcher dashboard.
• SQLite for storing load offers, drivers, matches, decisions, message history, duplicate relationships, and processing statuses.
• Browser automation for interacting with Sylectus and the factoring platform using an authenticated browser profile.
• Sylectus load-board scraping for collecting offer information.
• Sylectus driver-address-book synchronization for maintaining the driver list and driver availability.
• Local OSRM routing running through Docker for calculating true road deadhead mileage without relying on paid routing APIs.
• Emitrr API integration for outbound driver messages.
• An inbound webhook for receiving driver replies and delivering them to the dashboard.
• JavaScript and HTML for real-time dashboard interactions, timers, offer selection, status changes, and message updates.
• Local caching to avoid repeatedly calculating the same routes or processing the same offers.
• Batch launchers that start the required services and open the dashboard through one Windows command.

The system was developed incrementally. Each stage introduced one major capability, including scraping, matching, dashboard review, message preparation, outbound messaging, inbox functionality, local routing, duplicate handling, factoring checks, and user-interface improvements.

Challenges we ran into

One of the largest challenges was working with systems that were not originally designed for this type of integration.

Sylectus required stable browser sessions, manual login handling, page monitoring, and careful extraction of information from an existing web interface. Small page delays or session changes could interrupt scraping or cause refresh timeouts.

Driver and load information was also not always entered consistently. Equipment names, customer details, MC numbers, pickup times, delivery times, weight, and dimensions could appear in different formats or occasionally be missing.

Duplicate shipments were another major challenge. The same shipment could be posted multiple times by different brokers or reposted shortly afterward. We needed to recognize that these offers represented the same shipment without accidentally hiding legitimate loads.

Routing was initially dependent on estimates and external services. Moving to a complete local United States OSRM environment required downloading and processing a large map dataset, configuring Docker, managing storage, and connecting the routing engine to the matching workflow.

Messaging introduced its own set of problems. A message could be successfully delivered even when the browser or dashboard reported a timeout. Message history could load late, and driver replies needed to appear quickly without refreshing or changing the selected offer.

The dashboard also had to manage several asynchronous operations at the same time:

• Load-board scraping
• Driver synchronization
• Matching
• Routing
• Factoring checks
• Outbound messages
• Inbound replies
• Timers
• Offer expiration
• Dashboard refreshes

Keeping the interface responsive while these operations completed in the background was one of the most technically difficult parts of the project.

Another challenge was maintaining strict control over changes. Because the application had grown into a working operational system, even a small unrelated modification could affect scraping, timers, factoring, messaging, or offer-group behavior. Development therefore moved toward small, isolated patches instead of large refactors.

Accomplishments that we're proud of

We are proud that the project developed from a basic load-board monitor into a functional dispatch-assistance platform.

Some of the most important accomplishments include:

• Creating a working local dispatcher dashboard rather than relying on multiple disconnected browser tabs.
• Automatically detecting new Sylectus offers.
• Matching offers with suitable drivers using actual driver and equipment data.
• Calculating true road deadhead mileage locally.
• Building a structured workflow for pending, waiting, expired, passed, and skipped offers.
• Preventing duplicate shipments from flooding the pending queue.
• Allowing the dispatcher to review and edit every message before it is sent.
• Successfully sending driver messages through Emitrr.
• Receiving inbound driver responses through an API and webhook.
• Keeping offer and driver message histories inside the dashboard.
• Adding unread-message indicators without automatically marking unseen messages as read.
• Integrating factoring checks into the load-review process.
• Preserving the selected offer while background updates continue.
• Keeping production decisions under dispatcher control.
• Building a system that runs locally and does not require a large external software platform.

The project now reflects Sierra’s actual dispatch workflow instead of forcing the company to adapt to generic dispatch-management software.

What we learned

We learned that dispatch automation is not only about collecting data. The most important part is presenting the right information at the right moment without creating additional distractions.

A system can technically identify a load and a driver, but the match is only useful when equipment, availability, deadhead, timing, driver notes, and data quality are all considered together.

We also learned that transportation data is rarely perfectly standardized. A reliable system must expect incomplete information, inconsistent equipment names, unusual customer entries, duplicate postings, timezone differences, and delayed website responses.

Another major lesson was that the user interface is just as important as the automation behind it. Dispatchers need to understand immediately:

• Which offers are new
• Which offers require action
• Which driver was contacted
• Whether the message was sent
• Whether the driver replied
• Whether the customer passed the factoring check
• How much time remains before an offer becomes outdated

We learned that local routing can provide more control, lower long-term cost, and greater reliability, but it requires significantly more setup and infrastructure than an external mileage API.

Finally, we learned that smaller, carefully tested changes are safer than large rewrites once an operational tool has multiple connected systems.

What's next for Dispatch Dashboard Monitor

The next stage is to stabilize and refine the existing system before expanding its automation.

The main priorities are:

1. Complete the local OSRM integration across the full matching workflow and improve route caching.
2. Continue improving the reliability of Sylectus scraping and driver synchronization.
3. Reduce delays between factoring-check completion and dashboard updates.
4. Improve outbound-message confirmation so the displayed status always matches the actual Emitrr result.
5. Continue refining inbound reply handling and unread-message behavior.
6. Improve driver availability management and make outdated driver statuses easier to identify.
7. Add clearer warnings when important load information is missing or questionable.
8. Improve matching rules for cargo vans, small straight trucks, large straight trucks, liftgates, pallet jacks, dimensions, and special requirements.
9. Add operational analytics, including response rates, sent-offer results, passed offers, driver engagement, and successful matches.
10. Improve recovery after browser-session failures, Docker restarts, website timeouts, or computer restarts.
11. Continue polishing the dashboard so dispatchers can understand and operate it with minimal training.
12. Test the entire workflow under normal production volume before enabling any additional automated actions.

The long-term vision is for Sierra Active Pilot to become a complete dispatch-assistance environment that monitors opportunities, recommends the best available units, manages driver communication, and organizes the full decision history—while keeping the dispatcher responsible for every final decision.

Built With

• chatgpt