Integration with Amazon Connect using AWA skill based routing

brain LEE
Giga Contributor

‎11-04-2022 02:06 AM

Hi, Experts.

 

Amazon Connect and ServiceNow AWA are being integrated.

I would like to use the routing of the agent to AWA of ServiceNow entirely, not Amazon Connect.

 

As shown in the figure below, we created two Skill groups in the "Consumer Service Support" AWA Group and assigned three agents each.
In addition, the "Skill Determination Rule" is set to be judged according to the value of a specific field ("Mobile" or "Laptop") in the interaction table.
All agents are assigned to Amazon Connect's queues.

 

Now, I made a phone call pretending to be a customer for the test. In the Contact Flow of Amazon Connect, the scenario was configured to be connected to the mobile agent, and it was assumed that the mobile counselor (agentA1) and the laptop counselor (agentB1) were waiting, respectively.

 

The customer's phone was expected to ring the mobile agent according to skill routing, but both the mobile counselor and the Laptop counselor are getting calls once in a while. (To be exact with CCP)
It seems to be Amazon Connect's routing is applied before ServiceNow's AWA skill routing, so I think signals are coming into CCP. It is observed that the M2M Skill table is assigned skills.

 

Is there any good idea to make serviceNow's AWA skill routing take precedence over Amazon Connect's routing?

Preview file
21 KB
  • 1,042 Views
1 REPLY 1

eribarkm
Giga Contributor

‎02-10-2023 08:30 AM

As a customer, we had a similar use case and I posed your question to SN product team. This was their reply:

 

"Is there a way to make ServiceNow's AWA skill routing take precedence over Amazon Connect's routing?"

 

Not directly, however, using the Virtual Agent integration with Voice, customers can use AWA to route phone calls instead of using their phone system's routing logic. Essentially, if VA is handling the call flow/IVR, then transfers to an agent, our internal routing is used. If Amazon Connect manages the call flow, then Connect does the routing.

We are currently looking to extend the framework to allow for more flexibility and federated routing, and may have that available in future releases.