Logistics, field service, and workforce software
Dispatch Software: Build, Buy, or Integrate?
A decision framework for logistics, delivery, and field-service teams evaluating packaged dispatch products, custom coordination layers, and full custom platforms.
Published by Kennedy Gichobi · Fact-checked by OpenAI Codex research review · Published · 1644 words
Dispatch software is a system of decisions, not a map screen
Dispatch connects demand, commitments, jobs or shipments, resources, skills, equipment, locations, time windows, routes, status, exceptions, communication, proof, billing, and customer expectations. A generic map with draggable pins can look complete while hiding the operational authority needed to run the day. Before choosing a product or custom build, define which decisions the system makes, recommends, records, or leaves to a dispatcher.
Trace a difficult day from order or service request through validation, planning, assignment, acceptance, travel, arrival, work or pickup, exception, completion, proof, settlement, and follow-up. Include a callout, cancellation, worker absence, vehicle problem, address error, customer unavailable, partial delivery, failed mobile connection, priority change, route breach, duplicate event, disputed proof, and next-day correction. Identify the source of truth and accountable role at every step.
The right solution is commonly hybrid. A transportation, field-service, workforce, mapping, telematics, payment, or ERP product may remain authoritative while a custom coordination layer handles a distinctive promise or exception process. The decision should protect safety and worker judgment. Software must not encourage interaction while driving or infer that a location signal proves safe, lawful, or completed work.
Buy when the operation fits a mature product model
Buying is usually appropriate for standard work-order intake, resource availability, ordinary assignment, route planning, driver or technician mobile workflow, notifications, proof capture, and common reports. Established products can provide faster deployment, broad device support, domain integrations, and a maintained routing or scheduling engine. An operation that is not differentiated by dispatch should be cautious about becoming a software company.
Evaluate through scenarios rather than a feature checklist. Ask the product to demonstrate multi-depot work, skills, equipment compatibility, recurring jobs, split work, customer windows, priority escalation, reassignment, after-hours coverage, offline completion, partial proof, failed notification, correction, and export. Record manual workarounds, configuration limits, premium modules, transaction fees, API restrictions, and how the product handles an outage.
Review pricing units, contract term, implementation, migration, map and message consumption, mobile users, support, service levels, integration access, rate limits, data retention, sub-processors, location-data use, security evidence, accessibility, export, and exit. A low per-user price can become expensive when every contractor, temporary worker, integration, message, or optimization request adds cost.
Configure when the data and lifecycle already fit
Configuration works when the packaged product understands the essential entities and states but needs local job types, priorities, territories, skills, forms, notifications, escalation, roles, and reports. Prefer governed configuration to custom code where possible because it follows the vendor's supported upgrade path. Avoid creating a hidden programming environment that only one administrator understands.
Maintain a configuration register with purpose, owner, scope, effective date, dependency, test case, approval, and rollback. Separate enterprise defaults from depot, team, client, contract, or service-specific overrides. Version consequential rules such as priority, assignment eligibility, cutoff, and proof requirements. A later configuration change should not make yesterday's dispatch appear to have followed today's rules.
Quantify workarounds. An exceptional manual decision handled twice a month may not justify engineering. Re-keying every completed job into finance, manually reconciling failed messages, or exporting location history daily may justify integration. A custom field is not a durable answer when the product cannot enforce the lifecycle, authorization, or reconciliation that the field represents.
Build focused capability when dispatch is differentiating
Custom development is justified where service quality depends on workflow a package cannot model responsibly: unusual resource compatibility, proprietary commitment logic, complex multi-party handoffs, specialized exception recovery, customer-specific control, mixed owned and contracted capacity, or integration across legacy systems. Build the smallest complete capability that preserves clear authority rather than cloning an entire TMS or field-service suite.
Define the measurable advantage: reduce unassigned urgent work, shorten exception resolution, improve first-time completion, eliminate duplicate entry, expose truthful customer status, or reconcile contracted capacity. “More flexible” is not a measurable product outcome. Validate the uncertain rule with real scenarios and representative data before building a large optimization engine around assumptions.
Custom work includes production identity, authorization, observability, recovery, support, documentation, accessibility, migration, and export. NIST's Secure Software Development Framework provides practices for protecting code and artifacts, producing well-secured releases, and addressing vulnerabilities. Budget these continuing obligations and staffing continuity; the business will own a product, not only source code.
Keep optimization and automation within accountable boundaries
Decide whether routing or assignment is manual, rules-based, optimized, predictive, or a combination. Record objectives, hard constraints, preferences, data sources, update frequency, and override authority. Cost, distance, time, service level, worker preference, vehicle capacity, skill, breaks, access, emissions, risk, and customer impact can conflict. A route labeled “optimal” merely optimized the objectives encoded by its designers.
Test missing coordinates, inaccurate duration, new roads, restricted access, oversized vehicles, weather, timezones, daylight-saving change, late orders, stale traffic, and a resource already committed elsewhere. Preserve the plan version and explain material changes. Give dispatchers a usable way to override with reason and learn from outcomes without punishing necessary judgment.
Do not allow automation to make employment, safety, eligibility, or consequential customer decisions beyond approved policy and qualified review. A model score should not silently remove work, intensify an unsafe route, or treat location gaps as misconduct. Use operational metrics to improve the system, not create surveillance incentives that cause people to hide exceptions.
Design mobile and offline behavior before procurement
The field application must work under intermittent connectivity, limited battery, glare, noise, gloves, motion, device sharing, and time pressure. Define what is downloaded, encrypted, expired, revoked, queued, retried, and visible offline. Preserve local work until the server accepts or explicitly rejects it. Test force-close, device restart, clock error, low storage, duplicate tapping, photo upload failure, changed assignment, and logout before synchronization.
Use state beyond color, large targets, readable typography, alternatives to dragging and gestures, and clear confirmation for consequential actions. WCAG 2.2 is an appropriate web baseline, while field conditions add human-factors needs. Provide keyboard and assistive-technology support for dispatcher workflows and accessible customer status, forms, and proof review.
Separate navigation from interaction. The system should not demand reading, typing, photographing, or resolving complex exceptions while a person is driving or operating equipment. Use organizational policy, safe stop workflows, voice or hands-free features only where appropriately evaluated, and escalation to a dispatcher. Technology cannot make an unsafe process safe merely by reducing taps.
Govern location, proof, and personal information
Define why location is collected, whose device or asset it represents, precision, frequency, visibility, retention, sharing, and what decisions may use it. Collect the minimum needed for the approved purpose. Distinguish planned, reported, device-derived, geocoded, and verified locations. A point on a map does not prove identity, delivery, work quality, consent, or responsibility.
Proof may include signature, photo, barcode, document, measurement, recipient name, timestamp, and location. Define authority, alternatives, redaction, correction, retention, and dispute handling. Avoid permanent public links. Protect homes, faces, license plates, access codes, medical or service details, and other sensitive content. Preserve the original and approved transformations where evidence integrity matters.
NIST's Privacy Framework is a voluntary tool for identifying and managing privacy risk. Use it to map people, data, purposes, processing, third parties, and outcomes, while qualified privacy, labor, legal, safety, and contract professionals determine applicable obligations. Do not expand tracking merely because a mobile device makes it easy.
Compare lifecycle cost and exit readiness
For a purchased product, include subscriptions, usage fees, map calls, messages, mobile users, implementation, configuration, integration, migration, training, administration, support, price change, and exit. For custom capability, include discovery, design, engineering, infrastructure, providers, testing, security, migration, support, monitoring, incident response, device compatibility, maintenance, and staffing continuity.
Price uncertainty as a range. Integration access, address quality, historical records, routing constraints, partner cooperation, and mobile conditions often dominate effort. Measure recurring manual work and failure consequence without promising that every saved minute becomes cash. Separate initial transition from annual ownership and the cost of operating both systems during rollout.
Require export of jobs, assignments, status history, proofs, messages, configuration, users, roles, and external identifiers in documented usable formats. The organization should control or be able to transfer domains, repositories, cloud accounts, storage, map and communication providers, integrations, deployment pipelines, backups, monitoring, and documentation. Test exit before dependence becomes irreversible.
Run one difficult dispatch scenario before choosing
Ask every option to trace the same scenario: an urgent job arrives with an ambiguous address; the preferred worker lacks required equipment; a route is already delayed; one device is offline; the customer changes the window; the assignment is transferred; proof upload fails after completion; a duplicate event reaches billing; and the customer disputes the final status. Require the system to explain authority, state, identity, privacy, retry, reconciliation, communication, and operator action.
Compare buy, configure, integrate, and build against disqualifying constraints and weighted preferences: workflow fit, time to value, integration behavior, mobile resilience, safety boundary, data control, privacy, accessibility, security evidence, support, lifecycle cost, roadmap, and exit. A short proof with representative data should resolve the largest uncertainty before a large license or development commitment.
Use the dispatch software requirements checklist for detailed workflow design and the fleet-management requirements checklist where vehicle lifecycle is central. Share service types, territories, resources, constraints, systems, job volume, mobile conditions, location-data policy, integrations, and target outcome through the project questionnaire, or use quick contact to pressure-test the proposed boundary.
Authoritative references
Related software planning guides
- Dispatch System Timeline: A Phased Roadmap for Logistics and Field Service
- Freight Forwarding Workflow Platform Requirements
- Port and Maritime Operations Platform Requirements Checklist