Salesforce Field Service Implementation: Why in Waves?

I always roll out Salesforce Field Service in waves, region by region or country by country. Each wave brings its own master data, dispatchers, technicians and partners, and the first wave is the test for all others. Then there is a topic that often comes up too late: the works council. It plays a role on what technicians can see of each other, for example in timesheets, and on the technicians’ location. Both should be raised proactively. And different regions and countries have different conditions that need checking before each wave.

This is the last part of the series. The parts before describe what has to be in place in every wave: the decision in part 1, master data in part 2, scheduling in part 3, spare parts in part 4, contracts in part 5 and partners in part 6.

The first wave is the test for all others

Field Service changes the working day of dispatchers and technicians. A dispatcher who has worked with a planning board for years suddenly reviews proposals from an engine. A technician who wrote reports on paper documents in an app. That does not work for everyone at the same time.

A wave limits the risk. If skills or visiting hours are missing in the first region, it affects one territory and not the whole field service. The mistakes of the first wave become checkpoints for the next. There is also a practical reason: the master data from part 2 can be cleaned region by region. Whoever starts everything at once needs everything clean at once.

A wave should cover:

• the cleaned master data of the region: assets, skills, visiting hours, absences
• the territories and the scheduling policy, with dispatcher release as in part 3
• the partners of the region, as described in part 6
• training for dispatchers and technicians shortly before go-live
• the agreements with the works council and data protection for that country
• metrics measured before and after go-live

Leave room between two waves. The first weeks after a region goes live are when dispatchers change proposals often and technicians have questions about the app. Starting the next wave in that phase spreads the project team’s attention too thin. It helps when dispatchers of the next wave watch the live region first. They learn more there than in any training. Why training alone does not get technicians to accept the app is covered in Field Service app: getting technicians on board.

Which topics go to the works council early?

Field Service collects data about employees. Two topics played a role in my projects.

Visibility among technicians. Who sees whose appointments, working hours and timesheets? According to Salesforce Help1, Field Service offers timesheets in which technicians record their time for a week or a month, including travel and breaks, with an approval process. Whether a technician sees colleagues’ times and appointments, whether the team lead sees everyone and who approves is decided by sharing. That needs to be settled before it gets built.

Location. According to Salesforce Help2, the mobile app can send technicians’ location to Salesforce regularly. It lands in the Last Known Location field on the service resource, and a history can be recorded if wanted. For scheduling that is useful, because the engine knows where a technician is. For the works council it is a tool that can make behaviour and performance visible.

The technology can be configured. This is what I would discuss with the works council in concrete terms:

Setting	Room to adjust
Interval	How often the app sends the location, in minutes
Accuracy	Fine (about 10 m), medium (about 100 m) or coarse (about 1 km)
Exceptions	Single technicians can be excluded from tracking
Time window	With Appointment Assistant only in the En Route status, on the way to the customer
History	Whether old locations are stored or only the latest one

On top come the skills and absences from part 2 and the voice input I describe in Field Service Mobile: guided flows and voice. That is employee data too.

In Germany, the works council has a right of co-determination under section 87 of the Works Constitution Act3 for technical systems that monitor employee behaviour or performance. How that applies in a given case is for legal to decide.

Why do regions and countries differ?

An international field service does not have one legal situation but many. Co-determination, data protection and working time rules differ by country, sometimes also by region or site with its own employee representation. What takes a short alignment in one country needs a formal works agreement in another.

That argues for waves by country. Each wave checks the conditions of its country before it starts. The configuration has to support that: mobile settings can be assigned per profile, so that location tracking is active in one country and not in another. Set it up that way from the start, so the second country does not inherit the settings of the first. What each country needs beyond law and technology, from a sponsor in the country management to key users, is covered in chapter 4 of the change management masterclass.

How do you measure the success of a wave?

Every wave needs numbers from before and after. I would take the ones that already came up in the series:

• the four numbers from part 1: jobs per day, share of travel time, skills and first-time fix rate
• the failed visits from part 2 and their causes
• the share of proposals the dispatcher changes before release, from part 3
• the response times met, from part 5

If the numbers do not improve in the first wave, in my view it is rarely the product. Usually data is missing, or scheduling still happens on the side. Which numbers to watch is covered in Field Service KPIs after go-live.

First step: a region with clean data for the first wave

For the first wave, pick a region with clean data, an open-minded service manager and a manageable size. Bring the works council into planning that wave, not only into its acceptance. And check the conditions of each country before every further wave, before you commit to dates.

Sources3

1. 1Salesforce Help (opens in a new tab)help.salesforce.com
2. 2Salesforce Help (opens in a new tab)help.salesforce.com
3. 3section 87 of the Works Constitution Act (opens in a new tab)gesetze-im-internet.de