Location can help a customer find a nearby branch or a driver reach a destination. It can also feel unnecessary when an app asks for it before explaining its purpose. Start with the decision that location will support. A suburb selection, a one-time position and continuous background tracking are different product requirements, with different implications for permission, battery use and customer trust.
Match access to the task
A mobile tyre service might let customers enter a service address manually and optionally use their current position to help locate a breakdown. That does not automatically justify following the customer after the booking. Android documents distinctions between foreground and background location, and between approximate and precise access. Confirm the implementation against current platform requirements. For a branch finder, approximate location may be sufficient; for a roadside rendezvous, a more precise position may be useful alongside a description of the vehicle and surroundings.
Explain the request in context
Ask when the person chooses a location-dependent action, using a short explanation tied to that action. If they decline, keep a manual address or map-selection route available where feasible. Avoid a repeated permission prompt every time they open the app. Show whether location sharing is currently active, who can see it and how it ends. In a workforce app, distinguish a job-related location capture from ongoing monitoring. Those are different experiences and should not be disguised behind the same reassuring label on the permission screen.
Prepare for imperfect positions
A location reading can be stale, approximate or unavailable indoors. Display enough context for the customer to correct it and avoid treating a map pin as proof that someone attended a site. Test denial, a later change in system settings and a device that provides only approximate access. For service appointments, confirm the intended address before committing a booking. For arrival coordination, let people add landmarks or contact instructions. Review whether saved location history is actually needed after the task; collecting more detail creates work and responsibility without necessarily improving the service.
- Would entering a suburb or address solve the task without device access?
- Can the user see and stop any ongoing location-sharing session?
- What useful route remains when precise location is unavailable or declined?
- Does the app ask the customer to confirm the intended service location?