How to implement Field Service Lightning for telecommunications companies

The splicer was sent to a power job two exchanges away. The skill on the work order said technician. Everyone has that skill. The territory was the sales region, so the offer was legal, and the travel looked no worse than the other legal offers inside a fence that was never an engineering patch. The pit that actually needed them waited. The job they attended needed a different ticket. They were turned around at the site, and the drive was already spent.

People still search for Field Service Lightning for telecommunications. The product to implement is Agentforce Field Service and Operations, formerly Field Service. The two design choices that decide whether it works are territories and skills. Both are on the help page. Neither is a sales map with a new name.

"Set up multilevel service territories that represent the regions where mobile workers can provide services." The region that matters is where the network is, and where a given crew or contractor is allowed and equipped to work it. "Schedule one-time or recurring work orders for customers, and add details about worker preferences, required skills, and parts." The skill has to say what plant the job touches. A customer address alone does not.

#Territories follow the network

Sales regions are drawn for quota. Network work is drawn by cable, by exchange area, by radio cluster, by the contractor who already holds that patch. If you copy the sales hierarchy into service territories, you will schedule a salesperson's postcodes and call it engineering. The drives will be long, the contractors will be in the wrong places, and the optimizer will look guilty for following your membership.

The scheduling optimizer accounts for worker skill level, travel time, location, and other factors. It does not account for a verbal agreement that "we do not really use the western postcodes." If those postcodes are inside the territory, they are in. Remove them from the membership, or split the child patch so the western work is offered only to the crew that holds it. A note on the territory record will not refuse the offer.

Use more than one level. A parent can be the area you report on. The child is the patch a technician or a contractor may enter. Put people on the child they actually cover. Membership of the parent only, because it was faster to load, can make them eligible across every child underneath. Read that result with a dispatcher before you go live. Ask: could this person be offered that exchange? If the answer is yes and it should be no, the membership is wrong.

Do the test with one person, not with a slide. Create them on the parent alone and see which appointments they are offered. Then create them on one child and look again. The difference is what parent membership actually means in your org. Do not assume it is only a reporting roll-up. Reporting can roll up without a scheduling licence. If the test says otherwise, stop adding people to the parent "so the report works."

#Contractors are most of the capacity

Contractors are not an afterthought in telecommunications. They are often most of the capacity. Their territories are their patches. Their hours are their contract, not the employee's roster. Their user is theirs. A borrowed supervisor login hides their hours, their skills, and the record of who attended. See them as capacity with a boundary.

The agreement is the source of the boundary. If the agreement says three days and one exchange cluster, store three days and that cluster. Storing the employee's week, on the parent's territory, will offer them work they will not do, in places they are not paid to enter. The no-show will be blamed on the contractor. The record caused it. How to give them a user, a shift, and a patch without lending an employee login is set out in contractor scheduling. Load them that way from the first patch. Do not "add contractors in phase two" after the territories have been drawn around employees only. Phase two arrives, and the patches are already wrong.

When a patch changes hands, change the membership the same day. The outgoing contractor who stays on the child territory will keep receiving the work whenever their skill matches and their hours say they exist. The optimizer will offer it. Travel will look fine. The commercial arrangement is what you forgot. End the hours as well. A user who can still be scheduled is a user you are still buying, whether accounts payable knows it or not.

#Skills name the plant

A required skill of "technician" or "field" matches everyone you hired. It will not keep a fibre splicer off a power job, or a premises installer out of a jointing pit. Start with the skills that change who can legally or safely do the work, and who can do it without a second visit from another trade.

Examples, not a product catalogue: fibre splicing, copper, radio, exchange equipment, aerial, confined space, electrical isolation. Your list will differ. Write it with the people who hold the tickets, not with an implementation partner guessing from a slide. The list is short on purpose. A skill nobody will be refused for is decoration. Delete it as a requirement. It makes the design look thorough and changes no offer.

Too many required skills on one work order and nothing schedules, because nobody holds the full set. Split the job if two trades are genuinely sequential. A pit that must be made safe by one ticket and then jointed by another is two steps, in order, not one appointment with five tickets "to be safe." The stack will not schedule. Someone will clear the skills under pressure, and the next offer will be the nearest person again. That is the failure you built the list to prevent.

Parts belong on the work order as well. A network job without the joint kit, the drop cable, or the replacement card is a drive to confirm you forgot the part. Preferences matter at the premises: access windows, induction, a dog, a concierge. A pit does not have those. Do not force one work type to pretend both sites are the same. Two work types, with different skills and different parts, are cheaper than one work type that lies about both.

#Implement the difference on purpose

Load territories from the network view and the contractor agreements, then stop. Do not "align to sales" in week two because a report was easier. Reports can roll up. Scheduling membership should not. If a sales manager needs to see activity in their region, give them a report that rolls child patches up. Do not move the technicians onto the sales shape so the report is a filter on territory name.

Pilot one patch. Real work orders, real skills, real contractors, for a fortnight. Count how often the wrong trade was offered, and how often the territory boundary created a drive a dispatcher calls absurd. Fix the skill or the boundary. Then the next patch. A count you do not write down will be remembered as "it felt better." Write the two counts. They are the only evidence the design is the network and not the quota map.

Duration still matters on this plant. A premises job stored as a short generic visit will stack, and the network job stored the same way will too. Correct them from watched work, per work type. The optimizer cannot tell a fibre job from a sales visit except by the records you put on it. Skill, territory, hours, parts, and duration are those records.

Duration and travel still poison this design after the skills are right. A premises visit stored as a short generic slot will overflow, and the induction that every building on that estate requires will be the minutes nobody typed. A network job stored the same way will send a splicer without enough time to make safe and test. Correct the work type from watched jobs in the pilot patch before you copy the pattern nationally. The optimizer will account for travel time on top of whatever duration you left it. If the pilot fortnight is already late by mid-morning, the skill list is not the thing that is wrong.

Keep the pilot's wrong-trade count and absurd-drive count when you open the next patch. The second patch should not invent a new generic skill because the first crew was small and everyone happened to hold the ticket. Scarcity shows up when the patch is larger. Require the plant anyway. A quiet first fortnight is not evidence that "technician" would have been enough. Write the plant skills down where the person raising the work order can see them, in the words the night shift uses. A perfect model that the call-taker cannot apply at 6am will arrive as a blank skill, and the nearest van will be the offer. The work type has to carry the requirement so the call-taker does not have to remember the catalogue under pressure. A blank skill at 6am is how the nearest van becomes the design, whatever the workshop agreed.

Field Service Lightning is what the search box says. The product you implement is Agentforce Field Service and Operations, formerly Field Service. Implement the network and the ticket. Leave the sales map for the people whose job is the quota. The van is not one of them.