Case study
Why your team's app makes them dig for the customer who is waiting
Our own team app opened on charts, not on the customers waiting for a reply. We rebuilt the first screen around who is waiting and for how long; reaching a customer's chat is a tap or two in the reworked version, against four or five moves before.
Key takeaways
- A team app should open on the question the team asks first: who is waiting, and for how long.
- Showing the elapsed wait and sorting by it makes the longest-waiting customer visible without a search.
- One search box that accepts a phone number, e-mail or name is faster than a perfect menu.
- Screens that build every chart and list at once feel heavy on older phones; only the part on show needs to be built.
- Keep figures behind a tab and put anything that needs a person at the front.
The person who runs our own team's support app told us that reaching a customer's chat took four or five moves. Both reworked versions, iPhone and Android, were finished by the Sunday. The rule we took from it is plain: a team app first screen shows waiting customers, not figures. Older versions of the app keep working unchanged; the reworked layout is in the next versions, on their way to the App Store and Google Play.
What a slow first screen costs a service business
In a service business, customer reply time is part of the product. The customer who writes in is judging how quickly someone comes back, and the app is where that answer starts. When the first screen shows charts, every reply begins after the staff member has found the conversation. Nobody can see at a glance who has waited longest, so the quiet customer and the urgent one look the same. The same app is used by people in different roles, and one crowded layout slows each role down in a different way.
What our own team told us after a day of using the app
This was our own app, used by our engineers and support staff, so the complaint came from inside. The person who runs the team said reaching a client's chat took four or five moves, and finding a colleague to write to took as long. Several screens were so full of figures that what needed a person was lost among them. The app opened on an overview of numbers, not on the people waiting for a reply.
What we found, screen by screen
We went through the app as each role uses it in a working day: the person in charge, the engineers who handle requests, the finance desk. We counted the taps to the tasks people repeat: open a client's chat, write to a colleague, find an old request, see what to do next. Two patterns came out. Chats were split by where they came from, so finding one client meant knowing which list it sat in. The busiest screens also built every chart, list and tile at once, even parts nobody looked at, which made them slow to open. The morning question — who wrote to us, and what do I do now — had no single place to be answered.
Why the app had grown this way
The cause was not one bad screen. The app had grown screen by screen, with each new feature adding its own tab or tile. Its layout followed how the system was built rather than the order a person works in. That is how an internal app can age: every request is met where it lands, and nobody steps back to ask what the first screen is for.
What changed: the team app first screen shows waiting customers
We rebuilt the navigation from the first screen down, on iPhone and Android at once. In the reworked app, every role opens on a new Home. At the top are the messages waiting, each with who wrote, the start of what they wrote and how long ago. The customer who has waited longest comes first, and the wait turns amber at 5 minutes and dark red at 15. A long press — press and hold — pins a chat to Home, mutes it or marks it read. Below that is what this person should do now, in the order of their day. A strip across the top holds the team chat and any pinned chats.
One search box finds a client by company name, or by a person's name, e-mail or phone number. It also accepts a number typed with spaces or a leading zero, and it finds a colleague or an old request. Anyone on the team can write to any colleague directly. The crowded screens were cut into parts behind a row of tabs. Only the chosen part is built, and anything that needs a person, such as a figure that was missed, comes first and is marked.
On the client side, group chats got a Chats tab with the main support chat first and the groups below it, and requests that can be found again by number or by words.
Where it stands and what it changes
The change that keeps older versions of the app working is live. The new layout is in the next iPhone and Android versions, on their way to the App Store and Google Play. Staff will see it when those versions are live; it is not in people's hands before then. In the reworked version, reaching a client's chat takes a tap or two from Home or one search, against four or five moves before. The complaint came on a Friday and both versions were finished by the Sunday.
What you can check yourself
- Open the app as the person on the support desk does at the start of a day. Count the taps to the chat of the customer who wrote last.
- Look at the first screen. Can you see who is waiting and for how long, or do you see figures first?
- Search for a customer by phone number typed the way people type it, with spaces or a leading zero. Does the right person come up?
- Ask someone with an older phone to time how long the busiest screen takes to open, then time a quiet screen for comparison.
- Ask each role to name the one task they turn to the app for. If it is not on the first screen or one search away, that is the place to start.
What to do next
Watch one person do the task that matters: opening the chat of the customer who has waited longest. Count the taps and the seconds, and write down where they hesitate. If the path takes four or five moves, or the first screen is a dashboard, the layout is working against the reply. Ask whoever looks after the app to show you what the first screen would look like with waiting customers at the top, and keep the figures behind a tab rather than in the way. This is the kind of work our engineers do on apps for clients and on our own products.
Questions people ask
How many taps should it take to reach a waiting customer's chat?
Aim for one or two taps from the first screen, or a single search. If a common task takes four or five moves, the layout is adding steps before the reply can start.
Should our team app open on a dashboard or on the messages waiting?
For a team whose job is answering customers, it should open on the messages waiting, with the longest wait first. Figures can sit behind a tab; they should not be the first thing between a staff member and a customer.
Why do busy app screens open slowly on older phones?
A screen that builds every chart, list and tile at once is doing work for parts nobody is looking at. Splitting the screen into tabs and building only the chosen part gives an older phone less to carry.
How do we make it obvious which customer has waited longest?
Show the elapsed wait on each message and sort the list by it, longest first. A colour change as the wait grows lets the team see the urgent ones without reading every line.
Can we change the app's layout without breaking the version staff already have?
Yes, if the change is made so older versions keep working while the new ones reach the stores. Expect both versions to run side by side for a while, and check that the older one still opens chats and sends replies.