Don't start by tracking the crew all day

The first spec

A company with a field team, say electricians, cleaners, inspectors or delivery drivers, decides to build an app. The office's first wish is simple: we want to see where everyone is. So the first line of the spec says the app should track location all the time.

It sounds reasonable. It's the wrong first move.

Not because the office's questions are wrong. Dispatchers need to know who's closest to an urgent job. Customers want an arrival time. Managers need to show that a visit happened. Those are real needs. The trouble is that "track location all the time" doesn't answer any of them well, and it creates three new problems along the way.

What goes wrong

People say no, or switch it off. Phones ask the user before an app can see their location, and ask again, more pointedly, before it can see location in the background. Many workers will decline anything that looks like being followed after hours, especially on their own phone. Others accept and quietly turn it off later. Either way, the map the office was promised has gaps, and nobody can tell a gap from a worker who's simply not moving.

The app stores push back. Android's own developer guidance says most apps only need location while someone is using them, and that background location should be critical to the app's core function and obvious to the user. Google Play restricts background location to apps that meet that bar. An app that asks for it without a clear reason can be held back in review, and that's a bad week to discover it.

It doesn't even work the way the office imagines. To save battery, Android limits how often an app running in the background gets location updates, to a few times an hour on most current phones. The live dot gliding across the map isn't what you get from a background app. And the phones that do keep checking location constantly run down faster, which in a field job means a dead phone before the last visit.

The better first move

Start with the question location has to answer. Write each one down, and next to it, the moment it needs answering.

Has the worker arrived? Location at check-in, when they tap "arrived" on the job. The app is open; that's foreground location, the kind people are most comfortable granting.

When will they get here? Location during a trip the worker has started, with a visible notice on their phone that the trip is being shared. On Android that's a foreground service with a persistent notification, which the system treats as foreground access. The customer gets a live ETA; the sharing ends when the worker arrives.

Did the visit happen? Location and time at check-in and check-out, attached to the job record, alongside the photos and signatures you already collect.

Who's closest to an urgent job? Each worker's last check-in or last trip location, plus their schedule. For most dispatch decisions, "finished at the Elm Street job twenty minutes ago" is more useful than a dot on a map.

Location is evidence for a question. Decide the question before you collect the evidence.

Precise or approximate

Both Android and iPhone let people share approximate location instead of precise. For most check-ins, approximate isn't enough to tell which house on a street the worker is at. For "which part of town is the team in," it's fine.

Decide per question which you need. Ask for precise only where it matters, and say why in the app at the moment you ask. When someone gives approximate anyway, the app should still work, with check-in falling back to the worker confirming the address.

The same goes for the order of asking. Don't put every permission request on the first screen after login, before the worker has seen a single job. Ask for location the first time they tap "start trip" or "arrived," with one line explaining what it's for. A request that arrives with an obvious reason gets a different answer from one that arrives with none.

What to tell the crew

The technical plan is half of it. The other half is a plain explanation, written before launch, of what the app records, when and who sees it.

Something like: "The app records your location when you check in and out of a job, and while you're on a trip you've started to a customer. It doesn't record your location outside those times. Dispatch and your manager can see it. Customers see your ETA only." Then make the app do exactly that. If your work involves monitoring rules in your state or country, check them with whoever handles employment advice for you; this note isn't that.

When the explanation matches the behavior, most crews accept it. When it doesn't, the first worker who notices will tell everyone else. For more on what to watch before you write the spec, see Ride along for a shift before you design the field app, and for when people say no to permissions, see They denied push. You still owe them a path.

Before you write the spec

List the questions the office wants location to answer. For each one, write the moment it's needed, whether precise matters and what happens if the worker says no. If any question really does need all-day background location, write down why, because you'll need that reason for the crew and for the app store.

Some jobs do have a real case: lone workers in remote places, for example, where someone needs to know if a person has stopped moving. Even then, limit it to working hours, make it visible on the phone and give the worker a way to see what's been shared. Then test the whole plan on the oldest, cheapest phone anyone on the crew carries, through a full shift, before you roll it out.

We build mobile applications for people who work away from a desk, including the permission plans that let them say yes. If your field app is stuck on a location question, talk to us.

Related work: WorkStep.