Field Service app: getting technicians on board

Service technicians accept the Salesforce Field Service app when it takes work off their hands on site, and work around it when it mainly brings control and more documentation. That is why adoption is decided long before the rollout: by what the technician gets out of the app, by an open agreement on location tracking and hours with the works council, and by an app that also works in a basement without signal. A small group of experienced technicians who test all of this on real jobs beforehand is the most effective lever for that.

Technician adoption is a topic of its own

Field Service changes the working day of dispatchers and technicians. A technician who used to write reports on paper suddenly documents in an app. They see their appointments on the phone instead of on a note from the office, and they rightly wonder who can now see where they are.

Technicians are also a special group. They are rarely in the office, often attend training only once and have little patience with software that does not work in front of the machine at the customer’s site. If the app fails twice in the first week, the team considers it useless, and that reputation outlasts the fix.

What keeps technicians from using the app?

In terms of the ADKAR model: with technicians, desire (the willingness to take part) and ability (being able to do it in daily work) are missing most often. This table sorts the typical reasons:

Reason	Stage	What helps
“Headquarters wants to see where I am”	desire	clarify location tracking openly, limit it, agree it with the works council
“I write more than before”	desire	short forms, prefilled data, only required fields someone needs
“Nothing works without signal”	ability	define offline data beforehand and test it in the basement
“I cannot find the feature”	knowledge	training on a real work order, technicians as key users in the region
“After the update everything is different”	reinforcement	test app updates beforehand and announce them

Willingness grows when the app delivers something. For a technician that concretely means: the asset history is visible on site, the right spare parts are known before the job, and the service report is finished after the job instead of being written in the hotel at night. What inspection forms without paper look like is in Field Service Data Capture.

How do you handle location and hours?

The works council plays a role in two topics: the visibility of technicians to each other, for example in timesheets, and the location of technicians. Both should be raised proactively, before anything is set up. Location tracking in the Field Service app can be configured in interval and accuracy and switched off for individual technicians. The available settings are in the Field Service rollout.

For adoption, openness counts more than the setting itself. A technician who learns from the works council that their location is only transmitted while travelling to a job reacts differently from one who discovers it on a map in the office. The agreement therefore belongs in the communication before the rollout, in plain words.

How do you involve technicians before the rollout?

I recommend a small group of experienced technicians per region who work along before the rollout:

• Test forms on real jobs. An inspection form that looks logical at a desk can be useless in front of the machine, because the order does not match the workflow.
• Check offline. The group takes the app where there is no signal and reports which data is missing. What should be stored offline on the device is in Field Service app offline.
• Train colleagues. Experienced technicians explain the app more convincingly than a trainer from the project, because they know the same jobs.
• Remain contacts. After the rollout they are the first contacts in their region, like key users in inside sales, see key users in Salesforce rollouts.

It matters that this group can bring about real changes. If their feedback disappears in the backlog, they stop giving feedback.

After the rollout every region needs a short way back

The first weeks after a region goes live are when technicians have the most questions about the app. During this phase the project team should be reachable and not already start the next region. After that, reinforcement counts: every app update can change workflows and should be tested beforehand, as described in testing Field Service app updates.

A short way back matters just as much. A technician who notices on site that a required field does not fit should be able to report it in a minute, ideally straight from the app or through their contact in the region. If a visible change follows within two weeks, word spreads in the team, and that works better than a training session. If nothing happens, the required field soon gets filled with dots.

Whether the app has landed shows in numbers: work orders closed in the app instead of being entered later in the office, completed forms and service reports on the day of the job. How to set up such numbers is in measuring Salesforce adoption after go-live.

Win three to five test technicians in the first region

In the first region, find three to five experienced technicians who are willing to test the app on real jobs beforehand. Plan time for this in their schedule, otherwise they only test in their lunch break. In parallel, clarify location and hours with the works council and write the result down in plain words. Then decide which forms and data the technician needs on site, and drop the rest, even if a department at headquarters would like to have it.