Plugin Tutorial: Measuring Agent Performance

Plugin Tutorial: Measuring Agent Performance

vCons, the heart of the conserver, are constructed based on conversations, but it's entirely up to the developer to pick and choose the conversation, and the boundaries thereof. Every vCon contains a list of the "dialogs" for the conversation: the transcripts, recordings, call legs. For each dialog, a list of participants is provided in the "parties" section. Normally, we imagine that a vCon is a single conversation, between two people (each identified in the parties) and when recorded, contained in the dialogs.

We can just as easily create a vCon that contains the conversation had by an agent through a day. The agent would be identified as a party, but so would every customer that the agent spoke with. The vCon would also hold every dialog held by the agent through the day.

A vCon with this format has several advantages:

• You can pass this vCon into an AI engine to consider an agents performance, through a day
• You can export this vCon to represent a definitive record of the agent's activities.
• You can use vCons with this format to easily drive summary dashboards for teams and departments

Plugin Summary

A plugin is a component of the conserver that takes an inbound vCon, processes it, then could pass this vCon to another plugin. Plugins have two functions, one that starts the plugin in the conserver (called start), another that is called with a vCon UUID for processing (called run). The vCon UUID corresponds to the vCon to be processed, stored in a REDIS key with the same UUID : vcon-{VCON_UUID}. Plugins are assembled in a chain, each feeding the next plugin down the line. To stop processing for a vCon, plugins do not return a vCon UUID; to continue processing, the vCon UUID is passed to the next plugin in the chain. vCons are first created (and passed into chains) by adapters. By default, all adapters push their newly created vCons into a REDIS PUB/SUB channel called "ingress-vcons", and by default, each chain of plugins starts with vCons from this channel.

Plugin Design

To make a plugin that tracks agent performance daily, here's the basic approach

1. An agent performance system will work best if you use a plugin before it to fill in any missing agent data. For an example, see the stitcher plugin. The stitcher plugin takes each created vCon, using the parties information as a reference, reaches out into the employee database to fill in the details of the agents.
2. Create a plugin in a standard template, having a run and a start function. In the early days, copying an existing plugin like summary into a parallel directory will work.
3. In the run function of the plugin, take every vCon that arrives, and look for parties that have the role of "agent". For each such party, look for a vCon in the conserver that represents that agent for the day.
4. If no such vCon exists yet, create it. For ease of implementation, the plugin can keep a REDIS set of vCons for agents that are being built for the day, with keys that expire at midnight.
5. Take the information from the arrived vCon, and update the agents vCon with new parties and dialogs.
6. Optionally, the plugin can return the UUID of the agent's vCon, instead of the arriving vCon. In this case, the plugin down the chain from this plugin could work based on the update of the agent vCon, perhaps to project it onto a relational database, or to update the agent vCon in an external document database.