What happens when the phone locks?
A support chat that asks you to keep your phone awake is a sign the architecture has pushed its problem onto the customer. On designing mobile web sessions that survive interruption.
I was in the middle of a support chat on my phone this morning, on a plumbing supplier's website, when the screen locked while I waited for the agent to come back. I unlocked it a few seconds later and the conversation had gone. My place in the queue with it. I had to start again.
What made me laugh, and then made me think, was the message the chat had shown me earlier.
"Please prevent your phone from going into sleep mode - as this might cause you to be disconnected." The chat is asking me to change the way I use my phone so that its software keeps working. That is the architecture handing its problem to the customer.
A notice is not a fix
Phones lock. People get interrupted, by a notification, a call, putting the kettle on, or glancing at a text. Mobile browsers suspend background tabs to save battery, drop idle connections, and freeze pages that are not in front of the user. This is not edge-case behaviour, it is how every phone works, all day long. A web experience that only holds together while the customer stares at it unblinking is built on an assumption that was never true.
So a banner asking people to disable sleep mode is not solving the problem, it is documenting it. And it puts the cost on exactly the person you were trying to help, at the moment they least want friction.
Design for the interruption
The fix is to treat interruption as the normal case rather than the exception. If the session drops, it should be able to reconnect and pick up exactly where it was, because the state that matters does not live in the open tab, it lives on the server.
At Si Novi we would approach this by persisting the chat and the pre-chat details, who you are, what you were asking about, and where you were in the queue, so that a reconnecting device resumes the same conversation instead of starting a new one. The phone locking becomes a non-event: the connection re-establishes, the transcript is still there, the queue position is intact, and the customer never knows anything happened.
Build for the phone that locks
None of this is exotic. It is the same discipline as any resilient system: assume the connection will fail, assume the process will be interrupted, and make the state durable enough to survive it. It is also the same theme as designing software around how people actually behave rather than how we wish they would. The difference on mobile is that the interruption is not a rare fault, it is the default. Build for the phone that locks, because every phone does.
I first posted this as a short note on LinkedIn after it happened to me.