Somebody went out on Tuesday. Nobody can say what they did.

What is field service management software?

Field service management software runs work that happens at somebody else’s premises: the service request, the customer and site it belongs to, when the visit is scheduled and who is going, what the technician does when they get there, the parts used, the evidence of completion and the service history left behind. It is the record of a visit, not a map of where people are.

What does a field service management system manage?

Customers and their sites, service requests and the assets they concern, scheduling and technician assignment, the visit itself and its states, the checks and work carried out, parts consumed, completion evidence, exceptions when a visit cannot happen, the history of everything above, and who in the business is allowed to see or change each part of it.

What is a field service work order?

It is the instruction and the record in one: what needs doing, at which site, for which customer, by whom, with what was actually done written back onto it. On this page it is the visit — FV-2048 — and the point of it is that the instruction and the outcome never live in two different places.

Field service management vs booking software?

Booking owns availability and the appointment: when someone can come, and confirming it. Field service owns everything the appointment turns into — who is going, what they are meant to do, what they actually did, what it consumed and whether the customer can be shown the result. A small operation may genuinely need only booking. Once several technicians are active, the second half is where the work is.

Does it include route optimisation?

No, and it is worth being plain about it. The system records which visits are assigned to whom and when; it does not compute the fastest order to do them in, model traffic or estimate arrival times. Where an operation genuinely needs routing, that is a specialist provider and a scoped connection rather than something quietly implied by a scheduling screen.

Can technician locations be tracked?

Not by default, and Branditify is not a location provider. On-site is a state the technician confirms rather than a pin the system infers. Where an operation already runs a device or telematics provider, that can be connected and scoped around what those devices actually expose — and where it does not, the record still works, because it was never resting on a map.

Can technicians use it on mobile?

Yes — the technician surface is where most of the value is, because it is the only part of the system the customer ever watches somebody use. Whether that is a responsive web view on the phone they already have or a native app is a scoping decision made from how the team works, what the sites are like and whether anything has to survive with no signal.

Does field service software work offline?

Only where it has been built to, and it is a bigger piece of work than a checkbox suggests. Holding a visit on a device and syncing it later means deciding what happens to conflicting edits and to evidence captured out of sequence. Where sites genuinely have no coverage it earns its place; where they do not, it adds cost and risk for nothing.

Can photos or signatures be captured after a visit?

Where they are in scope, yes — photos, notes, checklists, documents and a customer acknowledgement on the technician’s screen are all normal parts of a completion record. What is deliberately not claimed is legal or biometric validity: the system records what was captured, by whom and when, which is what settles almost every service dispute and is a different thing from a certified signature.

Can parts used on a service job be recorded, and connect to inventory?

Yes. The visit records which part was used and how many, against the SKU it belongs to, so the job and the material stay together in the service history. Connecting that to a stock system so the count moves as well is a scoped integration against what that system can accept — the field service record is not a second stock ledger.

Field service management vs CRM?

A CRM owns the customer: who they are, what has been quoted, what is open commercially. Field service owns the execution: which request is live, who is going, what happened on site and what it consumed. They meet at the customer record, and an operation running both usually wants a request raised in one to be visible in the other rather than retyped.

Field service management vs fleet management?

Fleet owns the vehicle, the driver and the trip between places. Field service owns the technician, the site and the job done when they get there. A technician travelling in a van does not make the van the record — and an operation big enough to care about both usually wants them connected at the point where a visit needs a vehicle.

Field service management vs property management?

A property system owns the unit, the occupant and the fact that something is wrong. Field service owns who goes, what they do and what is recorded afterwards. The clean shape is a request raised against a unit becoming a visit assigned to a technician, with each system keeping the half it is actually built for.

Field service management vs auto workshop management?

Direction of travel. Auto workshop management runs a vehicle brought into a workshop — inspection, job card, parts, delivery — and it already absorbed service-centre operations. Field service runs a person travelling to a customer’s premises. Same word, opposite geometry, and two different records.

Can a client portal show service status?

Where a portal is in scope, yes — a controlled view of a request, its state and its completion record, for people outside the business. It is a real decision rather than a default, because it changes what every internal screen is allowed to contain.

Who owns the system and the data after a custom build?

You do. The code, the database and the hosting account are yours, and every request, visit, photo and history record in it is yours. There is no per-technician licence and nothing that stops working if a relationship ends.

What determines the scope of a field service project?

Mostly four things: how many technicians are active, what a visit has to capture on site, whether anything must work without a signal, and how much of the work is planned rather than reactive. Feature lists predict badly; those four predict well.

Can old job sheets or spreadsheets be migrated?

Usually, and the first job is finding out what the current tools can export rather than assuming. Customers, sites and open jobs normally move cleanly. Years of scanned job sheets and photographs depend entirely on what shape they are in and whether the history is worth the work.

What should a field service business digitise first?

Sites and requests, then assignment. A clean list of where you go and what has been asked for is what everything else attaches to, and a visit that has a real owner is what makes anything else measurable. Digitising evidence or parts before those exist just moves the confusion onto a phone.

Custom field service software, or off-the-shelf?

Off-the-shelf is the right answer more often than agencies admit: standard requests, standard scheduling and standard job sheets are well served by a product built for exactly that, particularly where routing and location providers are the main requirement. A custom build earns its place when the last twenty per cent will not configure — crew assignment logic, contract-specific pricing, an evidence workflow a regulator or a client actually dictates — or when several existing systems have to stay in step.

Does every service business need field service software?

No. One or two technicians, a shared calendar and a customer list work perfectly well, and a system would be overhead. It starts paying when more than a few people are active at once, when jobs need an owner rather than a group message, when somebody has to answer what was done at a site last year, or when parts and evidence start deciding whether you get paid.