We've put together a list of some of the most common mistakes we’ve seen companies make when adding text messaging functionality to their application. Keep these in mind when you're in their shoes, and you’ll be on the fast track to scalable success.
We've put together a list of some of the most common mistakes we’ve seen companies make when adding text messaging functionality to their application. Keep these in mind when you're in their shoes, and you’ll be on the fast track to scalable success.
Did you know that there is a limit to the number of text messages you can send per day and per second?
Exceeding these limits can cause your messages to be placed in a queue to be sent later than expected or even blocked. Having the right amount and/or type of numbers is critical to success. This is especially important for real-time back and forth conversations and time sensitive communications like mass emergency messages, access codes like two-factor authentication, etc.
2. Users are slow to read and respond to text messages from their customers because they aren’t being notified about new messages properly.
This tends to happen when the people who created the text message inbox failed to understand how their user’s message volume and personal availability impacts how they need to be notified about incoming messages. Take the time to understand your users different needs and develop your SMS inbox accordingly. Please note, sometimes your clients will need a product that is flexible enough to handle more than one of these use cases.
3. Users can’t see whether a customer’s phone number is text-enabled or not.
This can both 1) prevent users from even trying to send a message to a customer out of fear it won’t send or 2) causes them to think they are communicating with customers when they really aren’t. How awkward and problematic is that? To solve this problem, for every new customer phone number added, consider making an API request here to see if the number is text-enabled. Then have some design pattern for making it easy for the user to see whether the number is text-enabled within your application.
4. Users are unable to see conversations in the same way in which a recipient sees them.
For example, the recipient sees two message threads on their phone because the account sent them messages from two different numbers. But the user sees these two different threads as if they are one thread. This can cause a ton of confusion and miscommunication for both the user and recipient. As such, it’s best to have some way of allowing users to easily see these as two different conversations within their inbox.
5. The product creates liability issues for the client because it doesn’t have tools in place to automatically or manually allow users to unsubscribe customers from future text messages.
While this is a great starting place for compliance purposes, we recommend that your users should be even more sensitive to a recipients desire to no longer receive messages. Failure to honor somebody's intent might not land you in legal trouble, but it can quickly damage your reputation (think social media and everything digital). So also consider providing users with the ability to manually unsubscribe customers from within your inbox as well.
6. Users don’t have a way to identify unresolved conversations that need followed-up.
This causes customer needs to go unattended to and for users to waste time searching through messages to try to figure out who still needs attention. You can easily solve this problem by either 1) allowing users to manually flag unresolved conversations with an asterisk or 2) by keeping all conversations in an open status until they have been closed out by the user.
7. Users mistakenly see messages from a different client’s account.
This can happen when the same customer phone number exists in two different accounts within your application and you allow the same phone number to be used across accounts. Ideally you can easily solve for this by not allowing the same phone number to be used across different accounts.
If you really need to allow for cross-account numbers or short codes for one-time notifications, like you want to use the same short code across accounts for sending receipts, then just don’t thread any customer replies to these message back into your application and make it clear to your users that this will occur. You can use the same number for one-time transactional messages that don’t solicit a response.
