Enneo applies various steps to facilitate the work for the agent when dealing with incoming tickets:

• It summarizes the customer’s request
• It tries to identify the sender in the customer database
• It categorizes the ticket
• It detects the sentiment
• It provides a suggestion on how to respond, considering customer data.

On top of these steps mentioned above, Enneo allows you to add a deep backend/ERP integration for customer service requests. This integration automates typical use cases to a level where they only require a one-click agent approval. These automations are called "AI Functions" in Enneo.

AI Functions

An AI Function digitizes the workflow an agent would usually do when responding to a customer service request. It serves as the link between unstructured customer communication and structured backend interfaces, typically a REST API oder SOAP API, but any interface is possible as long as it gives real-time feedback.

Examples of AI Functions include:

For the supported ERP system Powercloud, Enneo offers a constantly growing list of AI functions to support common customer service requests.

The beauty of AI functions is that they are designed to allow clients to add any number of AI Functions without customization.

Setting up an AI Function

AI Functions can be configured in Settings → Business logic. You can choose an AI function using the Browse button.

On a strcutural level, an enneo processes AI Functions for tickets in these 4 steps:

1. Gather input parameters from specified sources
2. Run custom business logic executor
3. Choose matching output condition based on rules
4. Re-run based on agent input

Step 1: Input parameters

Here you specify which data points are needed as input to process an AI Logic. In the example above we want to terminate a contract, so we need

1. The contract number to identify the customer. This is taken from the ticket metadata.
2. The date when the contract should be terminated, taken using a prompt from the ticket
3. The type of termination, e.g. a regular termination or a termination because of a price adjustment. This is also extracted from the ticket using a LLM.
4. If a proof has been provided. A proof is needed for certain termination types, such as a relocation or a termination because of death. This results in a longer prompt, so the LLM knows if that criteria is satisfied.

Step 2: Business Logic configuration

This section allows you to specify the actual business logic of the AI function.

Technically, this sections takes pre-populated input parameters from the previous step, and feeds it into an executor, which is a place for you to specify custom business logic.

Specifying an executor

You are offered 4 different ways how you can define your business logic:

• As source code directly in the enneo UI (shown in the picture above). You can choose between Python, PHP and Node.js. You can leverage the enneo SDK that includes helper functions to create interaction forms for the agents or interact with the enneo API, including authentication using on-demand session tokens. The parameters are passed to your script as JSON-encoded string in stdin. This is useful if you have straight-forward business logic that you want to quickly set up.
• As API Call to a HTTP REST Endpoint of your choosing. The parameters are passed as JSON-encoded body (POST-Call) or as query parameters (GET-Call). This option is recommended if you need proper version-control or staged development processes.
• As Visual Editor, which allows you to specify business processes using a low-code visual editor. In enneo, we are using retool workflows for this feature. This option is recommended if you don’t have any coding experience and want to digitize your processes. If you desire this feature, let us know as this requires a custom set-up.
• No business logic: This option is useful if you want to branch output conditions only based on existing information, and do not need any additional processing. An example can be a payment delay approval if the decision is only based on a preexisting ERP field like creditworthiness. Then you don’t need any logic to determine if you should approve or deny the request.

Return values of an executor

In most use cases, your executor will return a form that shows the relevant information to you agent so a decision can be made, as shown in this example. In enneo, we call this interaction.

An interaction is defined by a strict JSON data format that you can either create yourself, or use the Enneo SDK for it. Please refer to the following documentation on interactions:

Step 3: Output handling

This section visualizes the branching logic or decision tree of a business logic. In the above example of a termination, there are four possible scenarios (”output cases”):

1. The agent decided the termination can be processed and the customer is informed about his termination date. The LLM creates a response to the customer based on the ticket context and the prompt specified.
2. The agent decided we need further confirmation, for example a proof of a landlord for a relocation termination. We create a response to the customer using a pre-defined text template.
3. The agent decided the termination was already processed. The LLM creates a response to the customer based on the ticket context and the prompt specified.
4. The agent has not made a decision yet. The interaction that was the output of the previous step is shown to the agent.

Step 4: Handling agent input

Initially as outcome of the previous step, we will always have the case that an agent has not made a decision yet (output case 4). The executor is run and the output interaction was shown to the agent.

Once the agent has made a decision and clicked on the button, enneo populates the internal variable _action with the decision. In the example above, the only option is termination_already_processed, which results in output case no. 3 being run and a text drafted to the agent.

This approach allows the agent to have full control over the result, but still have a one-click automation.

Developing AI Functions

enneo has additional tools to facilitate the development of AI functions, mainly:

• Setting up different test case tickets to validate different customer scenarios
• Raw data access to all relevant JSON objects
• Offline-development tools, allowing you to use
• your own IDE and debugging when using the code executor
• a CURL command export when using the API executor