Model the work before you configure anything
Start by cataloguing the kinds of jobs your organization does: installations, repairs, inspections, preventive visits. For each, record the typical duration, the skills required, the parts commonly used, and whether it must be completed in one visit. These become work types, which let the system estimate time and match the right people. If durations are guesses, the schedule will be too, so use real data from past jobs where you have it.
- List job types and group those that behave the same.
- Record standard durations and the skills and certifications needed.
- Note which jobs require parts, permits, or access arrangements.
Resources, skills, territories and availability
Technicians are modeled as service resources with skills, home bases, and working hours. Territories define where they work, and operating hours define when. The accuracy of these records is critical: a technician who is listed as certified but is not, or whose working hours are wrong, will produce schedules that cannot be followed. Build processes to keep skills and availability current, such as updating certifications when training is completed.
Scheduling policies and optimization
Scheduling policies express your priorities: minimize travel, honor appointment windows, prefer a customer's usual technician, respect overtime limits. They are combinations of rules and objectives, and tuning them is an iterative job. Start with a simple policy, run it against a sample of real jobs, and compare the result to what experienced dispatchers would have done. Adjust until the schedule is plausible, then let dispatchers use it and capture their overrides as feedback.
Be realistic about what automation does. It proposes; dispatchers decide, particularly in the first months.
Implementation and integration services →The mobile experience for technicians
The mobile app is where the work is recorded, so its design decides data quality. Include only the fields and steps technicians need, in the order they work. Support offline use where coverage is unreliable, and test it on the devices and networks that technicians actually use. Photos, signatures, checklists, and parts used should be quick to capture. If the app is clumsy, technicians will record work later, from memory, and accuracy suffers.
Inventory, assets and service history
Parts availability influences whether a first visit succeeds. Model warehouses and vehicles as stock locations, and decide how replenishment is triggered. Track customer equipment as assets, with serial numbers, installation dates, and past service, so technicians arrive with context. Maintenance plans can generate recurring visits for assets under contract, reducing manual scheduling.
Explore Salesforce solutions →Decisions to settle before configuration starts
- Appointment promise. Decide whether customers receive a window, an arrival time, or live tracking, and make sure operations can honor it.
- Dispatcher authority. Define when dispatchers may override the schedule, and how overrides are recorded.
- Billing handoff. Agree how completed work orders produce invoices, and in which system.
- Data ownership. Decide which system owns customers, assets, and parts so records do not conflict.
A realistic first 90 days
- Days 1 to 30. Define work types, skills, and territories, and clean customer and asset data.
- Days 31 to 60. Configure scheduling and the mobile app, then pilot with one territory and a small group of technicians.
- Days 61 to 90. Tune policies from pilot feedback, add inventory and maintenance plans, and roll out to additional territories.
Pitfalls to avoid
- Skipping the work-type groundwork. Guessed durations produce unreliable schedules.
- Overengineering scheduling rules. Too many rules conflict. Start simple and add one at a time.
- Ignoring dispatcher trust. If dispatchers do not trust the schedule, they will bypass it. Involve them in tuning.
- Testing mobile in the office. Test with real devices, in real conditions, with the real technicians.
