Managing field teams — a guide for companies with crews outside the office
Installers, service engineers, site crews. How to organise work for people who do not sit at a desk, and why standard collaboration tools do not help them.
If you run an installation, service or fit-out business, you know the split: part of the team sits in the office working on computers, part drives out and works on phones. The first group gets tools. The second gets a group chat and a call from the coordinator.
This guide is about the second group — and about why it is the most overlooked segment of the business software market.
Why office tools do not work in the field
Collaboration platforms were built around desk work. That is not an accusation — it is a description of design assumptions that simply do not hold in the field.
They assume a large screen. A twelve-column table is readable on a monitor. On a phone in sunlight, held one-handed, it is not.
They assume a keyboard. Filling in a site report on a phone takes three times as long as on a computer. If it is the last task of the day after eight hours of physical work, it will not be done properly — or at all.
They assume a stable connection. An app that spins on a weak signal and loses a typed-in form teaches people not to use it. One such incident is enough.
They assume location does not matter. In an office it does not. In a company with eight crews covering a region, "who is nearest" is a basic operational question — and most tools cannot answer it. Location is one axis among five views of the same job data; a tool serves whichever one it was built around, and the rest end up in somebody's spreadsheet.
What is actually needed
The order matters — this runs from things without which nothing works, down to improvements.
A map showing where the crews are
A view showing where the people are and where the jobs are. Not to monitor them — so the coordinator can answer "who takes the callout in the north" in five seconds instead of five phone calls. Assignment is one of the six stages of a service work order, and the one that most often ends up existing only as an agreement between two people.
This is a view that standard collaboration platforms simply do not have; they offer tables, kanban boards and calendars. A map is fundamental in the field and redundant in an office — which is exactly why it is missing.
Forms you can fill in one-handed
A site report has to be closeable in under twenty seconds. Practically: choice fields rather than text fields, a photo rather than a description, defaults inferred from the job context. What a form can realistically ask for is set by the conditions a technician works in — one free hand, gloves, a screen in direct sun — not by what the office would like to know.
Every text field in a field form is a decision to spend a minute of an engineer's time on information. Sometimes that is worth it. Usually it is not.
Sensible behaviour on a weak connection
The absolute minimum: a completed form must not be lost when the connection drops mid-submit. That is a lower bar than full offline support and it solves most real situations.
Full offline — a whole day of work with no network and a later sync — is technically hard and worth the cost only in industries where coverage genuinely is not there. Before treating it as a requirement, check the numbers: how many times a month do your crews actually lose signal for more than a few minutes?
Photos attached to the job
Photo documentation sitting in an engineer's phone is useless to the company. The same documentation attached to the job is evidence in a customer dispute and material for billing. Whether it can still be found a year later comes down to attaching photos to the job, not the chat.
The economics: why per-seat pricing blocks rollouts
This is the reason many companies never give their field crews tools — and it is a commercial reason, not a technical one.
If a tool costs the same for an engineer as for an operations director, then at fifteen engineers the bill becomes hard to defend. The engineer uses three features, the director uses thirty, and the price is identical.
The result: the company buys access for the office and the field stays on a group chat. And at that point the whole investment in organising the data loses its point, because half the information is still created outside the system.
The sensible model is role-based pricing. Field access at a fraction of full access. That is not a courtesy to the customer — it is the condition for a rollout covering the whole company rather than half of it.
How to roll it out so the crew actually uses it
Start with one crew, not all of them. Pick a foreman who is open to change and give them two weeks. Their opinion will convince the rest more effectively than any training session.
Take something away before you add something. If the new tool arrives on top of phone calls, group chat and paper job cards, it will be abandoned. A rollout has to replace, not accumulate.
No requirements in week one. Let the crew first see they are getting something for themselves — jobs with addresses and navigation, site history, photos from the previous visit. Add the reporting requirements in week two, once the tool has already paid them back.
Measure abandonment, not adoption. The percentage of people who logged in once tells you nothing. The percentage still using it in week three tells you everything.
Where AI fits in
Carefully, and in specific places:
Photo description instead of a written report. The engineer takes a photo, the model describes what is in it, the human corrects it in one tap. That removes the most hated part of field work.
Answers about site history. "What did we do here last time" asked by voice on the way to the site, instead of scrolling a job list.
Assignment suggestions. The model proposes who should take a callout based on location and skills — and the coordinator approves. The approval matters here: assignment is a decision about someone's working day and should not happen automatically.
More on why agent actions should require confirmation in the guide on AI agents for business.
Where to next
- Remote work tools — connecting the office to the field
- AI adoption for companies with no IT department — where to start overall
Frequently asked questions
- Why do standard project management tools fail for field crews?
- Because they are designed for desk work — they assume a large screen, a keyboard and a stable connection. An engineer on a roof has a phone, one free hand and poor signal. A tool that needs ten taps in those conditions simply will not be used.
- What matters most in a tool for field workers?
- A map view showing where crews are, forms fillable one-handed on a phone, and sensible behaviour on a weak connection. Every other feature is secondary to whether the person in the field opens the app at all.
- How should licences for field workers be priced?
- A sensible model charges by role rather than a flat per-person rate. An engineer needs a handful of features, an operations director needs all of them — and the price should reflect that, or the company simply will not buy access for the whole crew.
- Does field work require an offline mode?
- It depends on the industry. Crews working in basements, plant rooms and areas without coverage — yes. Urban service work usually not. Before treating offline as a requirement, check how often your crews actually lose signal; the number is often lower than the team assumes.
Read next
Five views of the same job — map, table, kanban, timeline
The dispatcher wants a map, finance a table, the manager a timeline, the engineer today's list. What each of the five views is for, and what each one hides.
Photos and files from the job — findable a year later
A photo sent to a group chat stops existing once the thread scrolls. How to attach files to the job so they can still be found a year later, not just today.
Offline work in the field — a real requirement or a convenient excuse
Three levels of working without a network and what each one costs. How to check whether your crews really lose signal, before full offline delays the rollout.