Who to hire for ClickSoftware on Salesforce

Field service buyers hire badly when they treat scheduling as a software feature. The product is only as good as three pieces of data: how long jobs take, which workers can do them, and where those workers can go. Get those wrong and the best optimiser in the world produces a confident, wrong plan. Get them right and a modest configuration performs well. This page explains how to hire a partner for the product that grew from the ClickSoftware acquisition, which credential and skills map to the work, how to run a first engagement, and what to ask. It names no winner. The cost of a project is on ClickSoftware implementation cost.

#Which product you are hiring for

The rebrand record states the lineage: "Field Service Lightning, acquired from ClickSoftware in 2019, became Salesforce Field Service with the Winter ‘21 release." Salesforce's help documentation then gives the current name: "Field Service is now Agentforce Field Service and Operations. In some cases, we still use Field Service to refer to this product area in Salesforce applications and documentation."

For a buyer, the practical meaning is simple. There is one Salesforce field service product, and it runs on the core platform alongside Service Cloud. The partner you want builds on it. If a proposal introduces another scheduling engine to sit beside it, ask why, because that adds an integration and a second source of truth for the same appointments. Whether you should be on the product at all is a different matter, covered in should I migrate from ClickSoftware.

Because the product name changed, take care with search terms. Some vendors still say Field Service Lightning, the name the product carried before it was renamed Salesforce Field Service and then Agentforce Field Service and Operations. Ask candidates to use the current product name so you know their knowledge is current.

#Duration, skill and territory

These three are the hiring interview in miniature.

Duration. Each type of job needs an estimated time, and the estimate must reflect reality, including travel and the extra visit that happens when a part is missing. In Salesforce these live in work types, and they are often copied from a spreadsheet nobody has checked since go-live. A partner worth hiring asks for actual completion times and compares them with the estimates before suggesting any configuration.

Skill. Each worker has skills and levels, and each job requires some. Skill data tends to rot, because it is entered once and never updated when somebody gets trained or leaves. Ask how the partner would keep it current, and who in your organisation would own it.

Territory. Service territories define where a worker can operate and when. Boundaries drawn for sales regions or postcodes often make poor service territories, because they ignore traffic, depots and the real geography of a day. Ask to see how a candidate would redraw one.

Salesforce describes the dispatcher's side of this: "Easily filter service appointments, update resource absences, and coordinate crews across territories directly in the console." That sentence lists the daily jobs of a dispatcher, and every one depends on those three data sets. If the data is wrong, the dispatcher spends the day overriding the system, and trust drains away.

#Credentials and skills

The credential that matches the work is the Salesforce Certified Agentforce Field Service and Operations Consultant, listed on Trailhead's credentials pages. Treat it as proof that a person has studied the product's design, not that they have tuned a policy on live data. Pair it with core-platform skills, and ask who in the team holds the administrator and developer credentials too.

The skills to look for are:

• Service territory design, operating hours and resource availability, including absences.
• Work types, skill requirements and appointment booking.
• Scheduling policies, work rules and service objectives, and what each one trades off.
• The enhanced scheduling engine, which Salesforce describes like this: "Built on the Hyperforce platform for speed and scale, Enhanced Scheduling and Optimization automates workforce scheduling, reduces travel time, and ensures compliance with service-level agreements." Ask whether your tenant uses it and what it changes.
• The mobile app: offline behaviour, forms, signatures, parts and inventory.
• Integration to ERP, asset and inventory systems, and to customer notifications.

Salesforce also says refinement should be measured: "When refining your scheduling policy, get an instant view of optimization results and KPI changes." A partner should be able to describe which key performance indicators they would compare before and after a policy change.

#What to check in each data set

Before any partner configures anything, someone has to look at the data. The table shows the checks a competent consultant will run on day one, and the failures they usually find.

Each row is a conversation with a different person. Durations belong to operations managers, skills to team leaders and training coordinators, territories to regional managers, absences to whoever runs the roster, and windows to the contact centre. A partner who talks only to the project sponsor will miss most of this. Ask who they would interview in the first week, and listen for roles rather than job titles.

It is also worth asking how the partner would treat the people. Dispatchers have workarounds, usually good ones, and they know where the data is wrong. A consultant who treats overrides as a nuisance has missed the best source of evidence available. One who asks to sit with a dispatcher for a morning, and records every manual change they make, will find the real problems quickly.

Finally, ask about change. A scheduling policy is a set of trade-offs, such as travel against customer preference against overtime, and moving one of them upsets somebody. Good partners involve the people who will feel it, and agree in advance how a change is announced and reversed. That discipline is worth more than any particular setting.

#A first engagement worth buying

Choose one territory with enough volume to be meaningful, and ask for a scheduling-policy review lasting several weeks. The partner takes a sample of recently completed appointments and compares estimated duration with actual, required skill with the skill of the person who attended, and planned travel with real travel. They list where the plan and reality diverge, and what each divergence costs in overtime, repeat visits or missed service windows.

The deliverables are a gap analysis, a ranked list of data fixes, a draft revised scheduling policy, and a test plan that replays historical days against the new policy. A good partner will say how they would validate improvements before they touch live scheduling.

Only then should you agree a build. If the review shows that data fixes alone would solve most of the problem, you will have saved a project. If it shows a deeper design problem, you will know exactly what to ask for.

#Red flags specific to this product

A second scheduler. Any plan that adds another engine beside the product is solving the wrong problem, and creates an integration you will pay for repeatedly.

Optimiser first, data later. Tuning policies on wrong durations produces precision without accuracy.

Territories copied from sales. If the proposal reuses sales territories without discussion, it has not looked at how workers actually drive.

No measure of success. Ask which indicators will improve and by how much you should expect to see them move. Do not accept promises with no baseline.

Ignoring the technician. Mobile workflows decide whether workers record accurate times. A partner who never mentions the mobile experience will leave you with poor data.

Treating it as Service Cloud. The case management skills overlap, but scheduling, dispatch and mobile design are separate disciplines. Ask for field-specific references.

#Ten questions for the first call

1. How would you test whether our job durations are accurate?
2. How would you keep worker skills current after go-live?
3. How would you draw service territories for our depots and traffic?
4. Which scheduling policy trade-offs would you discuss with our dispatchers first?
5. Do we use the enhanced scheduling engine, and what would change if we did?
6. How would you replay historical days to test a new policy?
7. What happens on the mobile app when a technician has no signal?
8. How do parts and inventory enter the schedule?
9. How do you handle an emergency job that displaces a planned one?
10. What would you refuse to automate?

The tenth question reveals judgement. Good consultants know that some dispatch decisions should stay with a human.

#Checking references and evidence

Ask a reference for the dispatcher's view, not the executive sponsor's. Ask whether overrides fell after the project, whether repeat visits changed, and whether technicians trusted the schedule.

Ask for the baseline and the result for the indicators that mattered, and for the method used to measure them. Marketing statistics on a vendor page are not a substitute for a client's own numbers.

Ask the named consultant to examine your own data in a short session and tell you what looks wrong. A person who has configured scheduling can usually spot a suspicious duration or a missing skill in minutes. Finally, speak to a technician on one of their previous projects if you can. Technicians know whether the mobile app helped them or slowed them down, and they are rarely coached before a reference call.

#Commercial models and the statement of work

A fixed fee suits the territory review. A phased fee suits a rollout by territory, with acceptance at each stage. Time and materials with a cap suits integration work, where unknowns appear late. A small retainer suits continuing policy tuning after go-live, which tends to matter more than the original build.

The statement of work should name the territories, work types, skills and policies in scope. It should require a baseline of agreed indicators before any change, a replay or pilot method, and acceptance criteria tied to those indicators. It should cover mobile testing on real devices in poor coverage, a training plan for dispatchers and technicians, and a handover of the policy rationale in writing. State clearly that no second scheduling engine is in scope unless you have approved it. For licence background, see the ClickSoftware licence page, and for history, what happened to ClickSoftware. Connection details are in integrating ClickSoftware with Salesforce. Salesforce describes the product at Field Service.

#When you can skip a partner

If you have a small team, a handful of job types and an administrator who understands territories and skills, you may not need outside help. Changing a work type duration, adding a skill or adjusting operating hours are routine tasks. Bring in a partner when the schedule is routinely overridden, when you are expanding to new territories, when mobile adoption is poor, or when you are adding optimisation and cannot tell whether it helps.

One caution applies even when you hire. Resist the urge to switch on every scheduling feature at once. Each addition, whether it is automatic scheduling, a tighter appointment window or a new skill rule, changes how dispatchers and technicians experience the day. Introduce them one at a time, in one territory, with a baseline and a review date, and keep the manual override available throughout. People forgive a system that is cautious and improving. They rarely forgive one that rearranged their week without warning. A partner who plans the rollout in small, reversible steps is showing you the habit that matters most in this kind of work.