Connect to Messaging is an IVR deflection solution that lets brands move voice calls to messages through the Conversational Cloud platform.
Connect to Messaging includes SMS, WhatsApp, Google RCS, Apple Messages for Business, or App Messaging, allowing the consumer to respond and start messaging with the brand using their mobile device
Steps to enable Connect to Messaging
After logging into the Conversational Cloud, click the icon above the profile badge bottom left of the image to the left, then click Connect to Messaging at the top left.
Enable Connect to Messaging if not enabled
When Connect to Messaging has not previously been enabled within the LivePerson account you are working with, it will likely need enabling; you must contact your LivePerson Account Representative to enable Connect to Messaging.
Enabling Connect to Messaging as LPA-user
If you had to follow the previous page and have logged in with LPA-username to the conversational Cloud, you can now navigate back to the Connect to Messaging.
You will now see an Activate option. Clicking it will enable the feature.
First we now need to enable a channel
Before we can use Connect to Messaging, we need to create an API Channel from Conversation Sources, do this by clicking Campaign Builder and then Data Sources.
After clicking Data Sources, you are presented with several Conversation Sources to choose from
We will focus on the Mobile App Data Source; however, your choice may vary depending on the Brand's requirements.
Data Source options
Here we see we have many options available on the selected Conversation Sources tab, we will focus on Mobile App and click Connect to proceed.
Defining our first Mobile app source details
On this screen, we can define our Mobile Application name and Application icon. Ideally, we match it with the application name compiled within Android Studio.
In this example, “com.liveperson.appname”, once we click create, we will then see the screen on the next slide, which will have our App Key
We have a new App Key
The app key shown at the bottom of the page should be placed somewhere safe, as it is used in your mobile App
It is the variable “appInstallationId”. Click Copy to clipboard, then click Done.
Back on the Data Sources screen
Now we can see the com.liveperson.appna… has been created and is enabled as seen by the yellow enabled tick, now we can click Done which will take us back to the Campaign Builder screen.
Data Sources and Mobile App Management
Next, we have to go back to Data Sources > Integrations and click Manage on Mobile app management where we will create a new Application key Management.
Create the App platform and name
Define the push notifications here and use api_key > current_key from google-services.json file
The Mobile App name should match that which was previously defined.
Application key management
If the creation of your Application Key is wrong you can not remove them. Contact support in this instance.
Before you can complete the next slide you need to obtain a Firebase API Key, this key comes from the Firebase legacy project it can be found in the Firebase console
Example Firebase google-services.json
Here we have an example google-services.json file where we obtain the current_key to be used in the next slide, it is important as the key is not found anywhere within the LivePerson Ecosystem, failure to use this key will result in non working app-push.
Select the new App key for later use
Here we paste the API Key found in the google-services.json example on the previous slide, once generated and put it aside for use later this is the App key we will use within the Mobile application.
The Push Notification API Key: It is taken from the google-services.json file.
Head over to Connect to Messaging
Now we are ready to create our Handoff, brands can pass can API handoff id and the API will leverage these configurations to send the IVR deflection outbound message.
Clicking Connect to Messaging will allow this to be completed.
You will now have your Google and liveperson api keys they will be used in the app source later.
Ready to create our first Handoff
At this point you should be on the page below and the uri should look like this
https://connect-to-messaging.z2.fs.liveperson.com/dark-app/c2m/handoffs/list
We start with clicking New Handoff seen to the right of the image below.
Creating our first Handoff
When creating the new API Handoff we should define a Title, a LoopBack Period and select our channel, you should note the “2 In-app” channel is enabled, you can only enable one channel here, later in Routing you can select multiple available channels to be.
The LoopBack Period can be set between 1 hour - 30 days, it is the time a consumer can respond to the in-app notification before it is then accepted by the default engagement should they reply after the period expires.
Editing the API Handoff
We can now edit the title of the push notification and the body text to be sent. You can create multiple handoffs, the messages will be defined by the Brand.
Each ID can later be used in the Eligibility call and can be limited by the LoopBack Period.
Adding and Editing the API Handoffs
Below we can see a list of API HANDOFFS and on the left we have an ID. Clicking the handoff will enable it to be edited.
Create a new API Handoff, enable In-App
Now we can create a new API Handoff, define the Title set the Loopback Period ensure In-App is enabled.
You can only select one option, it is impossible to use both SMS and In-App at the same time.
Now we can edit the Title for push notifications and the Body text for the push notification along with an image should the Brand require, and a clickable link should the Brand require a click through link to another engagement.
Like the previous step you can see here we have more than one App name available and if this is the case more than one can be selected and deselected as seen by the ticks to the right side of the drop down selection, doing so will cause the handoff to be enabled on all apps selected.
On this screen we can preview the push notification that was just defined, if you do not like how it appears then click back, make your changes and edit the title, body, and image as appropriate.
Editing the API Handoff
Below we can see a list of API HANDOFFS and on the left we have an ID.
Clicking the handoff will enable it to be edited.
API Handoff > Settings > Device Check
We can validate whether the consumer on your IVR is calling from a mobile device.
It is possible to check if the device is a landline or mobile device, it is suggested the Brand will do this check and to leave the toggle disabled where possible.
API Handoff > Settings > Routing Location
Check your routing location is enabled, here we have both In-App Agent and SMS Agent.
In the Routing Location screen you can enable and disable skill destinations where the handoff can be routed to. These are defined in Manage users and skills, add a new Skill to match the handoff required, here we have both In-App and SMS Agent skills selected.
API Handoff > Settings >Domains
Restrict the use of Connect to Messaging to known domains only.
The Domains section does not need to be edited, only add list of allowed domains here if you wish to restrict the usage to the defined HTTPS domain name.
Create Engagement
In Campaign Builder, edit the campaign that already exists, if it does not exist, create one.
Add an engagement and click the mobile app.
There is only a single app source per account in Data Sources > conversation sources.
Define your Routing for the Engagement
In the engagement we see Authentication is enabled, this is important because the app-push will not work without authentication.
We are routing to our InApp Agent skill, if you do not have a skill for this, please create one.
Select your Entry Point
The Android demo app has an entry point called “app” we will use this and it will be shown on the next slide you can choose “All entry points here” or “app”.
The brand can also define the entry points should they wish.
The App Entry Point
The demo app has an entry point called “app” as described in the previous slide, we will use this and we can define these as required. These can be defined within the app source code in Android Studio as ‘entryPoints’ new JSONArray and are sent.
As MonitoringParams monitoringParams = new MonitoringParams(null, entryPoints, engagementAttributes);
In the app sources within your chosen IDE, this will likely be AndroidStudio.
The Campaign and its other Engagements
Now that we have defined the engagement we are back on the Campaign page where we can see our newly created Mobile in-app Android app engagement and below we have a social media engagement, as usual one can have many engagements on this screen as required.
We should now be ready to test the app if it is already built and installed on your mobile device, if not test within Android Studio.
Ready to move on? Click here to proceed.