Requests, assignments, rider updates, customer messages, payments, and proof often sit in different channels.
Product Case Study
How Dexa connects delivery requests, dispatch, riders, proof, and reporting
Dexa is Zamacore’s delivery platform for independent drivers and courier businesses. This case study explains the operational problem behind the product, its request-to-receipt workflow, and the public evidence a buyer can inspect. It describes real product capabilities and published plans without anonymous testimonials or invented performance figures.
Dexa connects booking, assignment, delivery progress, evidence, payment, receipt, and reporting.
Buyers can review the two products, delivery workflow, published plans, and walkthrough before deciding.
The delivery-operations problem Dexa addresses
A courier job begins with a customer request containing pickup, destination, contact, package, timing, and service details. Operations may need to confirm the price, payment terms, delivery zone, available rider, and special instructions before work begins. During delivery, customer service, dispatch, the rider, and the recipient all need a consistent understanding of status.
When the request arrives through a message and assignment happens by phone, the operating record becomes scattered. A dispatcher may not know which rider accepted the work. Customer service may ask the rider for every update. Proof can remain on a personal device. Cash or digital payment information may not connect to the order. Management later assembles reports from conversations and partial lists.
Dexa addresses this coordination gap through two connected products. Dexa Driver gives independent drivers a customer channel, while Dexa Courier gives courier teams control over the wider delivery operation. The shared idea is that the order remains the central record from request and assignment through progress, proof, payment, receipt, and reporting.
The Dexa request-to-receipt workflow
1. Receive the request
Capture pickup and delivery details, contacts, package information, requested time, service, pricing context, and instructions in one customer record.
2. Confirm and assign
Operations reviews the request and gives the responsible rider or driver the order context required to accept and complete the work.
3. Follow delivery status
Structured events show whether the order is awaiting assignment, accepted, collected, in progress, delayed, delivered, failed, returned, or otherwise needs action.
4. Keep customers informed
Relevant status and communication records reduce repeated manual calls and help support staff answer from the current operating view.
5. Close with proof
Store the appropriate name, timestamp, signature, photo, note, quantity, or other delivery evidence under the completed order.
6. Record payment and report
Connect payment, receipt, delivery completion, and operational reporting so the job has a traceable commercial close.
Evidence buyers can inspect
Dexa’s public evidence demonstrates its product positioning, connected driver and courier experiences, complete delivery workflow, and published plan structure. A courier team can compare these materials with its order volume, service zones, dispatch roles, fleet model, payment process, customer communication, and reporting needs.
Dexa Driver and Dexa Courier
The product entry point shows the distinct paths for independent drivers and courier businesses instead of forcing both operating models into the same message.
Two connected products
Drivers can own a customer channel while courier teams control orders, dispatch, riders, evidence, payment, and business reporting.
Delivery workflow
The workflow evidence connects booking, assignment, progress, proof, payment, and receipt as stages of the same operating record.
Published courier plans
The plan view gives buyers a public basis for comparing operating tools and limits with current delivery volume and growth.
Why order status and responsibility matter
Status is useful only when each stage has a clear meaning and responsible role. “In progress” may hide whether an order is waiting for pickup, travelling to the recipient, delayed, or awaiting customer action. Dexa’s structured workflow gives operations a shared vocabulary for following the job.
Assignments should preserve who received the work, when they accepted it, and which order details were available. Reassignment and cancellation need visible reasons. Failed attempts and returns should remain connected to the original request rather than becoming untracked conversations. This history helps dispatch and customer service investigate exceptions.
Businesses needing a focused last-mile system can review Zamacore’s courier dispatch software in Kenya page. Companies managing vehicles, fuel, maintenance, trip expenses, customer contracts, and fleet profitability can also explore the broader Transport ERP platform.
Proof of delivery, payments, and commercial closure
A delivery should not become complete merely because a rider says it is complete. The appropriate proof depends on the service: recipient name, signature, photo, timestamp, location event, delivery note, quantity, condition, one-time code, or an authorised exception. The evidence needs to remain attached to the order where operations and customer service can retrieve it.
Payment may happen before booking, at pickup, on delivery, by account, or after invoicing. Cash, M-Pesa, bank, and credit workflows create different controls. The order should show the expected method and retain suitable transaction or collection information. Zamacore’s M-Pesa reconciliation software page explains matching and exception handling for payment operations.
Commercial closure links the completed service to a receipt, invoice, customer account, rider settlement, or management report according to the business model. When these steps share one order reference, teams can explain delivered-but-unpaid, paid-but-unallocated, failed, returned, or disputed work more consistently.
Operational value without unsupported metrics
The inspectable value is the connected operating flow. Customers and teams get a clearer request record. Dispatch can see assignments and current status. Riders receive order context. Proof remains attached to completion. Payments and receipts relate to the delivery. Management can review operations from structured data rather than rebuilding activity from messages.
This case study does not claim an unverified percentage improvement in delivery success, a specific time saving, or a named courier result that has not been approved for publication. Outcomes depend on order quality, service-zone design, rider adoption, connectivity, customer behaviour, payment controls, and management follow-through.
During discovery, teams can define measurable goals such as assignment time, failed attempts, missing proof, unresolved payment references, customer-status enquiries, returned orders, or reporting effort. Zamacore’s logistics software overview places Dexa within wider fleet, distribution, maintenance, and transport operations.
Adoption and product evaluation
A courier team should map its service types, zones, pricing rules, customer information, rider roles, status stages, proof requirements, payment methods, and closing reports before rollout. Existing customer and order records may need cleaning, while active jobs require a clear cutover plan.
A pilot can begin with one service area, dispatcher, rider group, or customer segment. Users test an ordinary delivery alongside cancellations, reassignments, delays, failed attempts, returns, cash collection, M-Pesa references, and proof exceptions. Training follows the actual responsibilities of booking, dispatch, rider operations, customer service, finance, and management.
Dexa publishes Starter, Growth, and Enterprise monthly plans and provides trial onboarding through business signup. Buyers should confirm the current plan, third-party service costs, limits, and integration requirements. Bring sample order forms, price lists, status messages, proof records, payment references, and reports to a demonstration so the comparison uses familiar work.
The evaluation should follow several complete scenarios: a normal prepaid delivery, a cash-on-delivery order, reassignment after rider rejection, a customer delay, a failed attempt, a return, and a completed delivery with proof. Testing exceptions reveals whether responsibilities, notifications, evidence, payments, and reports remain clear when daily operations do not follow the ideal path.
Inspect Dexa against your delivery operation
Review the product evidence, then compare it with your booking, pricing, dispatch, rider, proof, payment, customer communication, and reporting workflow.