Is your mobile app stuck with a chat product from the web era? Let’s fix this!

[ This post first appeared in the Hotline.io product blog ]

You have a pretty neat mobile app. The engagement could always be better, but the MAUs are climbing slowly towards half a million, bringing with it an increase in revenue. You tried out a few growth hacks to bump up your numbers further, before you realized that supporting and engaging your users is the only sure-shot way to long term growth.

You’ve heard the hype: Software is eating the world, messaging even more so. You are usually ahead of the curve. It’s time to get an in-app chat product, you decide. You call your product person and discuss getting chat for support and engagement. A couple of weeks in, the integration is complete and you pat yourself on the back for a job well done. You even sign-up to give a talk on “#ConversationalCommerce” at the next local mobile meet-up. Great!

A month later, your agents can’t seem to handle the load of real-time chats coming in. Your top performing support rep cribs that she is often idling, waiting for a customer response, and asks to go back to email. Your support head tells you that they need to hire 3 more agents than they had originally planned. The user metrics that all articles on the internet promised, do look marginally better, but there are new pains to deal with. The management is by now aware that this was completely your idea, as you contemplate how and where you went wrong.

What could have gone wrong? 

You are probably stuck with a tool that wasn’t built for mobile — you are using a “Shrink-and-Squeeze” mobile offering from a live chat tool created for the web era.

So how does one to move from this to a true “mobile-first” messaging experience?

Here are some inputs to get your mobile-first messaging right: helping you get to an experience suited for messaging conversations that could be short/light weight, but asynchronous and long lived.

1. Get rid of the “End Chat” button

Do you need to “end chat” when you are talking to your friends on FB Messenger, WhatsApp or iMessage? Mobile chat conversations are long lived — users will switch between using the messaging feature to reach you and actually using your app (or other apps).

Also, why confuse your users with 2 options (Back and End Chat/Dismiss) on the top of your screen? How does your Average Joe user know which one to press to get out of the chat screen to go back to using your product?

Would your users knowingly want to “end chat” and lose all the chat history/context?

2. Don’t “Close” the chat automatically 

Mobile messaging is meant to be asynchronous. We want to engage AT OUR CONVENIENCE. If that means being able to send a message when the customer wants to, and engage back when she can, your software should support that! No “chasing” her for an answer, or closing the conversation unilaterally please — it’s just not the right experience for mobile. These are long living conversations that need to be persisted.

3. No more “Our agents are offline, please send us email”

One of the key differences between live chat and messaging is — you can allow the customer to tell you her problem whenever, and then get back when you have the bandwidth. Why ask her to go through a separate experience for when you are away? Why expect her to engage over email outside the app just because your agents aren’t online when she is?

4. Persist Conversations —Design for Continuity

If your agents need to open “recent tickets” or reference older chats with a user from a huge list of “chats” in your chat tool, you’ve lost the plot. The history of recent conversations with the user should be right there — scroll up to see the history like you would in a messaging app — for the user and the agent alike!

We all know how much time a live chat agent has, and you don’t want them spending precious time figuring which previous conversation to read through. Or worse, not see previous conversations because of the inertia to access them.

5. Don’t ask users to identify themselves or provide context again

Don’t ask your app user questions you already should have the answer to.

 If they are signed into your app, don’t ask them to give their details again for chat support (surprisingly, even Zappos does this for logged in mobile app users — an appendage from the web experience clearly?)!

If you know the user, you probably also know their active transactions or last actions. You should look to deliver a “wow” experience where your agents have all the context they need already — just get to answering the user’s query rather than ask for “order id”s or “app version”s.

6. Use instant push notifications to bring the user back

You know what’s common about users on your mobile app? They’re easily distracted. They send you a message, and then they’re off to do something else on their phone — maybe answer a call from their boss, or respond to a friend’s message on Snapchat.

Did you know that 20% to 30% of your app users will choose to engage back at their convenience even if you respond immediately to them? So the experience when the user is outside the app is really important to closing the loop with them. You send a reply, the user should see a push on their screen as long as they are outside the messaging screen / app. Instantly. Does your in-app chat deliver that experience?

7. Ensure flexibility to handle higher chat volume per agent

Your support rep is no super-hero (ok, they are in some ways). There’s only so many live conversations one can handle at a time. However, you should know that they can handle many more asynchronous conversations in parallel. If 30% of your users don’t engage back instantly, you can allow for them to engage back, and handle other conversations active in the meantime. In short, your tools need to allow reps to be able to handle much more in parallel than you would have on web.

8. Add support for sending rich content

Sharing pictures/screen grabs, or sending a voice message is now table stakes. Make sure you are also able to send your users links to other media like videos, or FAQ articles, or deep links within the app or to content outside it. Rich messaging makes it easier to communicate for users and agents alike — a picture is worth 10 exchanges, and a video is worth 20 perhaps!

9. Use the Brand rather than Agent Names 

 It is often impractical to have the same person continue the conversation with the users given how asynchronous they may turn out to be. Given the context is available right there for anyone to take over and engage, why have the customer get anxious about different people engaging with him/her at different points in time? Let’s not complicate what should be a simple engagement between your customer and your business. The human touch is delivered via the actual content of your messages — it’s not about the name really 

With that, things have changed pretty dramatically for your agents and users! All for the better!

Your new experience should allow your support team to deliver an experience that is great when it is “live”, and also work well in an asynchronous environment — handle elegantly both the cases where your agents have their hands full, and the ones when the customer doesn’t engage back instantly.

You can now deal with the longer-lived mobile conversations better, and do a true load-balanced assignment among your “online” agents knowing how many active conversations they are handling.

Most importantly, you now let your customer engage like they would with friends or colleagues on Snapchat or iMessage. Simple and convenient as an experience, delightful as a result.

NOW, it’s time to give your kick-ass talk on #ConversationalCommerce!

PS: Have tips to make your chat better? Leave me a note at [email protected]. I build Hotline.io at Freshdesk, and would love to learn from your experiences with mobile chat

Illustrations by Shruti Venkatesh