With the Sinch Conversation API, you are always in control of your customer conversation whether it be over SMS, RCS, WhatsApp or Facebook Messenger. Of course, the API will support additional channels as they become popular.
Sinch Conversation API
The Sinch Conversation API offers one single API endpoint for sending and receiving messages across the most popular channels using one unified format. For more advanced messaging use cases, it offers conversations, contacts, switching between Bot and Human chats and much more for the advanced chatbot and conversational messaging application developer.
Different message channel (bearer) features and functions are supported through built-in transcoding. As a developer, you have the option to use either a global message template and for it to be automatically transcoded to each message channel format, or simply ignore transcoding and specify an exact layout for the channel you are interested in.
The benefits of this approach are that a developer needs to only become familiar with one Messaging API and yet have the power of conversations across all supported channels, still offering full control over channel specific features if required.
Further, it doesn’t matter which conversation channel the customer engages over, or switch between: a single callback contains all aspects of the conversation for easy integration into the Sinch portfolio of services, or any third-party platform.
Read more about Sinch and the Conversation API here.
One of the main challenges with the Conversation API was that it was a totally new product from Sinch. Coming into a new team as the lead designer for the Conversation APi, we had to establish the best practices for the product in order to reach our goal. At the start, we wanted to offer a single API endpoint for sending and receiving messages. Not only were we dependent on out other products such as WhatsApp and RCS, we had to make sure we were in-sync with our design throughout the portal in order keep the consistency. What we needed was a clear list of requirements, a user journey flow and wireframes before moving on to designs and prototypes.
With a clear requirement on place, we needed to create wireframes to be able to understand the user journey better. There was a clear understanding that configuring a channel to be able to send and receive messages through the Conversation API. After some test sessions and design validation, we were ready to move onto designing mockups and testing prototypes.
For closed beta our focus was to understand flow of the product, which led to design being very complex for the end user. After open beta focused on enhancing the user experience when configuring an app and channels. This led to design being more smooth and simple when configuring after validating it with some test sessions with current users.