Your staff have to use this app, so it has to be faster than the notebook it replaces.
A customer app has to earn its place on a phone. An employee app does not, because the work now runs through it. That is exactly why it gets designed badly: nobody can walk away, so nobody has to be convinced.
The people who open it are a technician in a lift machine room where the signal dies, and a picker in a godown wearing gloves. Add the guard starting a night shift on a phone three people share. Those are three different design problems, not one.
An employee app is software for people on your payroll who do their work away from a desk. It records what happened where it happened: the attendance punch at the site gate, the photo of the delivered carton, the stock moved from one rack to another. The web system your office uses stays where it is.
Where it earns its place.
What changes when the person is on your payroll
Compulsory use sounds like an advantage. In practice it removes the feedback that would have told you the screen is wrong.
- The same screen is opened forty times a shift, so two extra taps become an hour a week
- Nobody uninstalls it, so complaints reach you as bad data rather than as complaints
- It sits next to a salary, so staff read every feature as being about trust
Who actually opens it
Name them before we draw a screen. The job decides the interface far more than the industry does.
- Field technicians, one-handed, often with the other hand on a machine
- Delivery riders, outdoors, in sunlight, on a bike that is about to move
- Warehouse pickers, gloved, scanning rather than typing
- Security guards, on a shared handset, changing at shift handover
The things that decide whether staff use it
None of them are features. All of them turn up in the first week and cannot be added later without a rewrite.
- Works with no signal, and syncs when the phone finds one
- Opens to the one thing this person does next, not to a menu
- Big targets, because a gloved thumb is not a mouse pointer
- Photos compressed before upload, so a day of work is not a day of data
- Login that survives a shift change on a shared phone
Continuous location tracking is the commonest request and the fastest way to lose the app. A phone whose battery dies by two in the afternoon gets left in a drawer.
Offline is the requirement, not the extra
A basement. A lift shaft. A godown with a tin roof, a village road. The app has to be useful in all four, and honest about what it has not sent yet.
- Work queued on the phone and marked clearly as not yet sent
- What to do when the supervisor and the technician both changed the same job
- A sync state on the screen, so nobody wonders whether the day was saved
How we build it
- Shadow a shift
- One job
- Offline model
- Pilot team
- Rollout
- Support
- Watching the work before designing anything, even for one day
- Building the single task that takes the most time first
- React Native and Expo, so Android and iOS stay in step
- The office side of it: what the supervisor sees the next morning
The language and build toolchain question is answered on the React Native page. This page is about the person holding the phone.
When this is the right choice.
- Work that has to be recorded where it happens, not typed up later
- Staff who need evidence attached: a photo, a signature, a reading, a location
- Sites, routes or branches where a supervisor cannot see the work directly
- Teams that lose an hour a day to WhatsApp groups and a register
When it is not.
- Back-office work at a keyboard, where a browser screen is quicker to use and cheaper to change
- An app whose real purpose is watching where staff are, which staff will defeat within a month
- Work two branches do differently, where nobody has yet said which one is right
- A job that comes round twice a month, where a WhatsApp form link costs nothing and works
Questions we are asked about it.
Will it work where there is no signal?
That is how we design it from the start. The app holds the work on the phone, shows plainly that it has not been sent, and syncs when a connection appears.
Can we track our staff with it?
Location can be recorded at the moments that matter: the site punch, the delivery, the meter reading. Following a person all day drains the battery and upsets the team. The map it produces is one nobody reads. We will build it, and we will tell you first what it usually costs in goodwill.
Should it run on company phones or personal ones?
Personal phones work for attendance, visits and simple forms, and cost you nothing upfront. Company handsets make sense where a scanner, a shared shift device or a locked-down phone is needed. The awkward middle is asking staff to spend their own data on your uploads.
Do we need an app at all, or would a mobile website do?
If the work needs the camera, works without signal, or has to send notifications, you need an app. If it is a form filled indoors on wifi, a mobile web page costs less to build and less to change. That is worth settling before anybody quotes for an app.
Will it run on the old Android phones our team has?
Usually yes, and we test on one. It does change decisions: a smaller app, fewer animations, photos compressed on the device, and less held in memory.
How do we get staff to actually use it?
Make it faster than what they do now, and start with one team rather than everybody. Attendance through the app on day one is the usual lever, though it buys compliance rather than goodwill.
Services that use it.
What it sits with.
Not sure Employee apps is the right choice?
Tell us what the software has to do and who opens it. If something else fits better, we will say so, and say why.
- No obligation
- We reply the same working day
- Your details stay private