Interaction State vs Status Fields

Owned by Gnatta
Oct 03, 2024
4 min read

Quick links in this article:

1 What’s the difference? | 2 Why is interaction state important? | 3 Why are status fields important? | 3.1 Additional use cases for status fields

What’s the difference?

An interaction in Gnatta can be described in two ways - by it’s state, and it’s status:

State - This is a default variable Gnatta tracks for every interaction, and is how we manage interaction assignation at a fundamental level. States can be:Created, Automation, Queued, Assigned and Closed. Only Queued interactions will be available for assignation to an agent.

Status - Refers to a custom data field defined when your domain was created. This status field will contain values such as New, Responded or Closed. The agent can change this field on the interaction to trigger additional processes, or workflow can set it automatically.

An interaction can be in an Automation state whilst it’s in a chatbot journey, for example, but with a status of Responded or New. It’s crucial we make that distinction to keep your routing logic clean!

Why is interaction state important?

Using state in your workflow structure is what makes sure interactions are assigned to an agent at just the right time. For example:

  • Simple Assignation Logic

    • You might use Workflow to create a new interaction with a Created state, then carry out queue and data updates. Then, when you’ve completed your data gathering, you can set a Queued state. This prevents Gnatta from attempting to give an operator an interaction before we’ve collected the information they need to provide an answer.

  • Automation Journeys

    • After creating an interaction in a Created state, if you are going to present an automation journey to the customer you could set the state to Automation. This would allow you to prevent the interaction from being caught in other flows and being assigned to an agent before the automation is complete - such as in the middle of a telephone IVR!

  • Agent Handover Logic

    • When an automation journey is complete, you can set the state to Queued with Decision branches to allow customers to exit the journey at any time. This will ensure the interaction is transferred neatly to an agent, protecting the customer experience. That means no endless chatbot loops!

See more on actions used to manage interaction states here: Actions | Set Automation State

Why are status fields important?

This critical data type in Gnatta is how agents close an interaction when they’ve finished working on it, signalling to Gnatta that the interaction can be unassigned. This clears space on their radar to be assigned a new interaction.

The status field options you might need will vary for every business, which is why it’s a custom field that you can edit and change, unlike interaction state (above).

To get started, you’ll need to have at least one Status field set up. You can do this in your domain settings from Advanced > Dynamic Data > + Add. Be sure to set the type as ‘Status’ and the presentation type as ‘Single Select’ - it’s essential it displays as a dropdown for your agents to avoid typing errors interfering with your flows!

image-20240626-120714.png

For more detail, read this article here. If you prefer a follow along video, try here.

A typical ‘Status’ field might have options such as:

  • New - not yet handled!

  • Responded - a new response on an existing interaction

  • Wrap Up - a live conversation has ended, but the agent needs to carry out followups before closing

  • Closed - the agent has indicated they’ve finished with the interaction

  • Ignore - the agent has indicated a response isn’t necessary

  • Junk - the agent has marked the interaction as spam

When creating these options, you can define which are ‘Open’ and which are ‘Closed’ status types. In this example, it’s likely we’d split that as follows:

  • Open - New, Responded, Wrap Up

  • Closed - Closed, Ignore, Junk

Additional use cases for status fields

This field type can also be used to power a huge range of dynamic automations, and reporting possibilities. Example use cases include:

  • Reporting

    • In Gnatta Reporting, you can split your data by status. This can be useful for splitting out interactions that were actually handled or worked by an agent (Closed), ignored or junked.

  • Prompting Agents

    • Setting the status to a particular value via Workflow could signpost to the agent what they need to do next. For example, if the status is set to Wrap Up when a customer ends a chat then the agent will know they need to be adding notes to the interaction and carrying out any followup actions before they set to Closed.

  • Automated Chases

    • If you had a status value for Start Chase, you could use Workflow to start a timer when that status is detected. When the timer elapses it could trigger a new flow of actions - such as creating a new conversation, or reopening an interaction to assign to an agent.

 

Â