Dispatch and scheduling
How do you assign the right technician without overloading a territory?
About
OnDispatch has been developed and used in production for more than ten years. It grew from the day-to-day needs of a working field service operation, where customer service, dispatch, technicians, parts, clients and accounting all have to work from the same information.
OnDispatch started with a practical problem: running a service operation required too many disconnected systems.
A service call might begin with customer service, move to dispatch, go into the field with a technician, wait for a part, return for another visit, pass through quality control and finally reach invoicing and payment. When each department works from a different system, information gets repeated, lost or disconnected from the original job.
OnDispatch was built around a different idea: the service call should remain one connected record from beginning to end.
Over time, that idea grew into a platform for managing the people, parts, commitments, communications and financial activity surrounding field service.
Features were not added because they appeared on a software checklist. Most began with an operational problem that needed to be solved.
How do you assign the right technician without overloading a territory?
How do you keep different promises to different clients and know before one is missed?
How do you know where every part went, what it cost and whether it came back?
How do you manage employees and independent service providers together without losing visibility?
How do you connect what the client owes you with what you owe the person who completed the work?
How do you identify where coverage is missing and build the technician network to fill it?
Customer information, appointments, technicians, parts, communications, SLAs, invoices and payments should remain connected to the work that created them.
Customer service should not have to call dispatch to find out what happened. Billing should not have to reconstruct a repair from spreadsheets. A technician should not need to call the office for information already in the system.
Employees and subcontractors, warranty and customer-paid work, multiple visits, parts delays, recalls, client requirements and changing schedules are normal parts of field service. The software should be built around that reality.
We describe OnDispatch based on what the platform can do now. As the system evolves, we continue building from real operational needs.
OnDispatch began as software built to support the operations of a field service company in the United States.
What started as a way to manage service calls grew as the operation grew. Customer service needed better visibility. Dispatch needed technician availability and geographic coverage. Technicians needed information in the field. Parts had to be ordered, tracked and returned. Clients had different SLA requirements. Accounting needed to connect invoices and payments back to the service performed.
Instead of assembling those functions from disconnected applications, the system kept evolving around the service call itself.
After more than a decade of development and production use, that internal operating system became OnDispatch: a platform designed to bring the same connected approach to other field service businesses.
Field service keeps changing. Clients expect faster communication, technicians need better tools in the field, and service companies need greater visibility across increasingly complex operations.
OnDispatch will continue evolving around those needs while keeping the principle it started with: one connected operation, built around the service call.
OnDispatch is developed and operated by:
OnDispatch.com Inc.
Headquarters:
801 Northpoint Parkway, Suite 20, West Palm Beach, FL 33407
General inquiries:
services@ondispatch.com
Sales:
sales@ondispatch.com
Support:
Existing customers can sign in or contact their assigned support team.