Same feature list. Opposite design intent.

The difference in one sentence

Employee tracking answers a question the organisation has. Lone worker safety answers a question the worker's absence raises.

That sounds like positioning, and it is actually an architectural fork. Once you decide the organisation is the one asking, sharing has to be administered — enrolled by an admin, visible to a role the worker is not in, and difficult for the worker to switch off, because a switch the worker controls would defeat the purpose. Once you decide the absence is what matters, the opposite is true: sharing can be consented to, scoped, and revocable, because the safety value comes from the check-in and the escalation rather than from continuous observation.

Every downstream difference follows from that one decision.

What employee GPS tracking is built to do

Workforce tracking products are generally built around an organisational view. The specifics vary by vendor; the shape below is consistent, and the last line is the point of listing it:

• An administrator enrols devices or accounts, rather than each person choosing to join.
• A web console is the primary surface, and it typically shows the whole workforce at once.
• Location history is retained for review after the fact, commonly for timesheet, route, or dispute purposes.
• Reporting and export are usually first-class features, because the output is meant to be read by someone who was not there.
• Whether a worker can pause sharing is normally an administrator setting rather than the worker's own.
• These are legitimate products with legitimate uses. They are simply not safety tools, and the two are frequently sold as though they were interchangeable.

What a lone worker safety app is built to do

A safety tool is judged on one moment: the one where somebody has stopped responding and a decision has to be made. Everything else in the product is scaffolding for that moment.

• A check-in that the worker sends, so that silence becomes a signal rather than an absence nobody noticed.
• An escalation that reaches named humans with the last known position and the time, so the follow-up starts somewhere concrete.
• A position that is honest about its own age — live, stale, or unknown — because a confident dot on a forty-minute-old fix is worse than no dot.
• Sharing the worker consented to, because a worker who resents the tool defeats it, and a defeated tool protects nobody.
• A defined answer to who calls emergency services, since no app does that.

Where the feature lists overlap and the design does not

Both categories will list live location, geofencing, alerts, and history. Reading those lists side by side tells you almost nothing, because the words describe the same capability serving two different masters.

Four questions separate them, and none of them appear on a feature grid:

• Who turns sharing on — the person being located, or an account administrator?
• Can that person turn it off today, without asking anybody?
• Who can see the map — the people the worker is working with, or a role the worker is not part of?
• What is the alert connected to at the far end — a named person who will act, or a screen nobody is obliged to watch?

Why we decline surveillance intent

People do arrive looking for staff tracking, and STALKR is a poor purchase for them — not because we disapprove on principle, but because the product will not do the job. There is no console that shows a workforce, no way to enrol someone who did not ask to join, and no manager-only history to review. A buyer who wants those things would be disappointed, and we would rather say so before the purchase.

There is a second reason, and it is the practical one. A safety mechanism only works if it is running when it is needed. Location sharing that a crew experiences as monitoring gets defeated in ordinary, undramatic ways — the phone stays in the truck, the app is force-quit, the timer is never armed. Consent is not a moral flourish bolted onto the design; it is the thing that keeps the check-in armed on a wet Tuesday in month seven, which is the only reason any of it protects anybody.

So STALKR's sharing is scoped to a Crew, chosen per Crew, and revocable by the person sharing. That is the whole difference, and it is also why the surveillance version of the product cannot be built out of it later without breaking it.

The one control that constrains a member, and its limits

STALKR does have a control that keeps sharing on: Tracking Enforced is a Pro admin setting that keeps every member of one Crew — the Crew owner included — Live until the owner turns enforcement off in Crew settings.

It is worth stating exactly what that is and is not, because it is the closest thing in the product to the thing this page is distinguishing itself from:

• It is scoped to a single Crew, and it applies to the owner too rather than exempting them.
• It is a visible Crew rule, not a hidden setting — nobody in the Crew is unaware of it.
• It cannot manufacture a position. If location permission is denied on the device, there is nothing to publish, and no app setting overrides the operating system.
• It cannot stop someone leaving the Crew, and leaving ends that Crew's access to them.
• It does not create a manager console, a history report, or a view that the member does not also have.

What STALKR gives up by being built this way

The design decision has a price, and it is paid in capabilities a workforce buyer would reasonably expect:

• No supervisor or web dashboard — everything is inside the iOS app.
• No enterprise provisioning, SSO, or workforce administration. People join a Crew with a code and an approval, one at a time.
• No compliance export or reporting, and no audit report for a regulator or an insurer.
• No professional or 24-7 monitoring centre, and no man-down or fall detection.
• No configurable escalation policy — escalation is push and email to the Crew and the recipients the user chose.
• No public App Store release and no Android release. STALKR is an iOS TestFlight beta.

Which one you actually need

The test is what you would do with the information at 4pm on a normal day.

• If the answer is nothing — you only want to know somebody is still fine, and to find them fast if they are not — you want a lone worker safety app, and consent costs you nothing.
• If the answer is that you would check routes, verify hours, or review where somebody went, that is a workforce management requirement. Buy a tool built for it, and be straightforward with your crew about what it does.
• If both are genuinely true, keep them as separate tools with separate conversations. Bundling them is what turns a safety programme into something people work around.

Design intent, side by side

STALKR's answers to those four questions, with the honest gaps in the same table. The right-hand column describes the workforce-tracking category rather than any particular product — implementations differ, and we can only speak precisely about our own.

Related NAVTRL Systems