Code Brew Labs Developed a Transportation Management System for a 3PL Provider to Increase On-Time Deliveries by 35%

The old allocation process required dispatchers to check vehicle availability by phone. We moved those checks into a dispatch service.

When shipments are ready for assignment, the software looks at vehicle capacity and delivery zones. It also checks if a driver has already been assigned another trip during the same period.

• Vehicle availability and driver schedule checks
• Shipment weight and vehicle capacity rules
• Delivery zone matching and urgent order handling
• Warnings for overlapping assignments
• Manual reassignment with shipment history

Dispatchers could now check vehicle capacity and driver availability before assigning shipments. The system handled routine checks, while the dispatcher remained responsible for the final assignment.

We used Google Maps Platform to support route planning. Dispatchers could review the stops assigned to a vehicle and change their order before releasing the trip.

The route module considered delivery locations and the time windows entered against each shipment.

• Multi-stop route planning using Google Maps Platform
• Estimated travel distance and arrival times
• Delivery time window checks
• Route updates after shipment reassignment
• Planned and completed trip comparisons

This was particularly useful when several deliveries were scheduled in the same district but had different receiving hours.

Drivers previously received a lot of trip details through WhatsApp. The new mobile app gave them a daily trip list with the details needed at each stop.

A driver could open a shipment and update the delivery without calling the office.

• Daily trip assignments with delivery instructions
• Navigation and shipment status updates
• Recipient signatures and delivery photographs
• Failed delivery reporting
• Offline updates when mobile coverage is unavailable

Some delivery locations had unreliable mobile coverage. The app therefore saved pending updates on the device. Once the connection returned, the app synchronized the pending updates with the TMS. This helped keep delivery records available even when drivers worked in areas with poor network coverage.

The operations team needed to know which trips were progressing normally and which ones needed attention.

We connected driver location updates with the dispatch dashboard. WebSockets delivered new status information to the screen as it became available.

• Active trips and latest reported driver locations
• Planned and actual delivery status
• Estimated arrival information
• Completed trip history

Managers could investigate a delayed shipment directly in the dashboard instead of calling every driver on the route.

Location information was available only to authorized users and within the configured tracking rules.

A failed delivery previously created a chain of calls between the driver and dispatch office. We added an exception workflow to keep these cases visible.

If a customer was unavailable, the driver selected the reason in the app. The shipment then appeared in the dispatcher's exception queue.

• Failed delivery reasons and supporting photographs
• Rescheduling and shipment reassignment
• Vehicle breakdown reporting
• Overdue shipment alerts and manager escalation

Delivery confirmation was another part of the process that needed attention.

Earlier, drivers sent photographs and signatures to the office. The documents were sometimes received hours after the delivery itself.

The new driver app attached proof of delivery directly to the shipment.

• Recipient signatures and delivery photographs
• Delivery timestamps and permitted location details
• Secure storage of delivery records in Amazon S3
• Required confirmation checks before completion
• Proof of delivery available to authorized office staff

Office staff could now find the delivery evidence through the shipment record.

The provider wanted to keep its existing ERP. It already contained customer accounts and handled invoicing.

We built an API layer between the TMS and the ERP so that shipment information could move between both systems.

A new delivery order entered the TMS for planning. After completion, the shipment status and proof-of-delivery reference were returned to the ERP.

• Shipment imports through REST APIs
• Customer order references retained
• Delivery status and completed shipment updates sent to the ERP
• Failed requests handled through retry queues
• Duplicate update checks and integration error logs

The ERP continued handling financial records. Dispatch planning and delivery operations moved into the TMS.

Dispatchers needed to know when a shipment was delayed or a delivery attempt failed. We added automatic alerts so the team could respond without repeatedly calling drivers.

Customers could also receive configured delivery updates. Redis and BullMQ handled background notifications and retried failed requests.

• New trips notify assigned drivers
• Delayed deliveries appear in the dispatch dashboard
• Failed attempts notify the operations team
• Customers receive configured shipment updates
• Completed deliveries trigger confirmation messages
• Unresolved exceptions remain visible until reviewed

Redis and BullMQ handled scheduled jobs and retries when notification requests failed.