Conversation Behaviors Panel

First configuration web page is related to audio prompts and call flow behaviors applied to inbound calls hitting the specific Virtual Receptionist. Let’s go deeper into each setting:

Audio prompts in the Virtual Receptionist don’t require uploading an audio file. Simply enter the text, automatically converted into speech using the built-in TTS engine.

When I answer a call:

• I start the conversation → This is the welcome prompt played to the caller when the Receptionist answers. You can type your own message in the selected language or keep the default one.
  If needed, you can also leave it empty, for example, if the Virtual Receptionist is placed after another auto-attendant or within a specific voice flow.

• Then I specify what I can do depending on the availability of Contacts, Topics and Answers and Booking → This prompt is played by the Virtual Receptionist immediately after the previous message. It has different default versions depending on which features are configured for this Virtual Receptionist.
  Features include:

  • Call transfer to contacts: enabled as soon as at least one contact is added in the Contacts tab.

  • Answering questions: enabled as soon as at least one topic is added in the Topics & Answers tab.

  • Appointment booking: enabled as soon as at least one event is added in the Booking tab.

If none of these features are active, a default fallback message is used:
“I apologize but the reception service is currently unavailable. Please try again later. Goodbye!”.
This is useful during setup to verify that the VR can be reached by phone.

Once at least one feature is enabled, the message automatically adjusts to list the VR’s available capabilities for callers.

The same logic applies here as with language selection: whenever the available features change, this message is reset to either the default version (listing those features) or to a custom message you may have created for that specific scenario.

For this reason, we recommend configuring the features first, and then customize the messages.

Example:
Suppose I add some contacts and a few topics. My VR can now transfer calls and answer questions, but it cannot yet book appointments.
The default message for this scenario is:
“I can connect you with our staff or I can answer questions about us and our services. How may I help you?”.

I customize it to:
“I can put you in touch with our team, or provide information about our company and services. How can I assist you today?”.

Then later I add an event in the Booking tab, the VR can now also book appointments. At this point, the message resets to the default for this new scenario:
“I can connect you with our staff, answer questions about us and our services, or book appointments. How may I help you?”
This default message replaces my previous custom message.

If I remove the booking event, returning to the earlier scenario, the system restores my previous customized message:
“I can put you in touch with our team, or provide information about our company and services. How can I assist you today?”

When I don’t get caller request → This prompt is made up of two parts, which are played at different times, as follows:

• When I don’t get caller request, I make three attempts to understand, informing the caller → This prompt is played whenever the VR cannot interpret the caller’s intent, or when the answers provided are inconsistent with the asked question. The VR asks up to three times for the caller to repeat, and the phrase used for this purpose at each attempt is defined by this prompt.

• The second part depends on the selected fallback behavior. This behavior is executed if the VR still cannot interpret the request or response after three failed attempts.

When the requested contact is not in my contact list → This prompt is made up of two parts, as follows:

• When the requested contact is not in my contact list, I inform the caller → This prompt is played when the contact requested by the caller is not found. Note that this behavior is also used in other cases (see below).

• The second part of the prompt depends on the selected fallback behavior.

When matching more than one contact → It may happen that multiple contacts are found as a result of a search. This can occur either because of duplicate names or because there are names similar to the one searched for. In this section, you can decide how to handle this case. The maximum number of contacts that can be returned is 5.
The possible options are:

• I list the most likely results, one at a time: the VR lists the contacts one by one, asking for confirmation if the contact is the one being searched for before moving on to the next. It is possible to customize the message that is played before listing the found contacts.
  If the caller does not confirm any of the listed contacts, the behavior “When the requested contact is not in my contact list” is applied. Note that in this case, the message cannot be customized, as it is the one defined in the previously mentioned scenario.

• I don't list any results but perform the behavior “When the requested contact is not in my contact list”: the VR does not list the results and acts as in the case “When the requested contact is not in my contact list”. Note that in this case, the message cannot be customized, as it is the one defined in the previously mentioned scenario.

When matching exactly one contact → A single contact match has been found. In this section, you can decide how to handle this case.
The possible options are:

• I ask the caller to confirm the transfer destination: the VR asks the caller to confirm that the contact found is indeed the one they were looking for, before proceeding with the call transfer. It is possible to customize the message used for the confirmation request, also by using tags, which is populated in real time with the contact’s data. The available tags are: <firstName>, <lastName>, <department>, and <officeLocation>.
  If the caller does not confirm the contact, the behavior “When the requested contact is not in my contact list” is applied. Note that in this case, the message cannot be customized, as it is the one defined in the previously mentioned scenario.

• I inform the caller about who will be transferred - no confirmation: the VR does not ask for confirmation of the contact and directly proceeds to the next step, that is transferring the call.

Once the contact to whom the call must be transferred has been identified, the VR plays a prompt to inform the caller. This prompt can be customized and is called “Before proceeding, I notify that the transfer is about to take place”. Note that this prompt is used both when the VR initially finds multiple contacts and when it finds a single contact. This prompt also supports tags: <firstName> and <lastName>.

When the called contact doesn't answer → It may happen that the chosen/matched contact does not answer the call or that their line is busy. In that case, the VR is able to take back the call and handle the scenario. It is possible to choose among the fallback behaviors listed under “I inform the caller”.

To allow the VR to handle the “When the called contact doesn't answer” case, it is necessary to configure a camp-on queue in the UCX Suite and enable the option “Retrieve calls that are not answered by Contacts” under the “Settings” tab of the VR being configured.
The duration of the transfer attempt can be set directly in the camp-on queue, through the parameter “Maximum waiting time”.

When after waiting 5 seconds, I don’t detect any voice input → The VR includes a “no voice input timeout”. If no voice is detected within 5 seconds, the VR plays a customizable prompt up to three times and then apply a fallback behavior.
The prompt is made up of two parts:

• When I don’t detect any voice input, I make three attempts to get a response: this is played each time after the 5 seconds of silence.

• The second part depends on the selected fallback behavior, which is executed if the VR still does not detect any input from the user after three failed attempts.

When I hit the maximum number of calls I can manage in a month → The VR license includes a certain number of calls per month. Once this limit is reached, the VR can’t handle additional calls until the beginning of the following month.
If the maximum threshold is reached, it is still possible to configure a fallback behavior and the related prompt to decide how these calls should be managed.

It is possible to check the usage status directly from the Home page of the UCX Platform:

When the caller indicates they have no further needs → During a VR conversation, the caller is periodically polled for additional needs/topics/queries. If the caller does not require any further assistance, call is terminated with this greetings prompt.

Fallback behaviors

For various scenarios, it is possible to choose the action that the VR should perform, along with the corresponding message to be played to the caller.
Let’s take a closer look at these fallback behaviors:

• I ask for other needs: the VR ends the current request and asks the caller if there is anything else it can help with. At this point, the VR exits the intent it was handling and returns to the initial state, as if the call had just started

• I greet and hang up: the VR plays a message and then disconnects the call

• I transfer to a number: the VR plays a message and then performs a blind transfer to a configurable number. Typically, this number is an Imagicle queue that then routes the call to human agents, who handles the caller’s request. However, the number can be any destination reachable from the UCX Suite, which is itself integrated with the calling platform

• Leave a message (“When the called contact doesn't answer” scenario only): the VR asks the caller whether they want to leave a message to be sent to the contact who did not answer the call.
  Depending on the caller’s choice, two scenarios are possible:

  • Accepts: first, the VR provides instructions on what information to include in the message (reason for the call, first name, last name, and the phone number to be called back on). This message is customizable (“If the caller wants to leave a message, I ask for the content”). Once the caller has left the message, the VR sends an email to the contact’s associated address with the transcription of the message. If everything is successful, the VR plays the prompt “After taking the notes”, which can also be customized, and then execute the configured fallback behavior. Each of these prompts can be customized.

  • Declines: the VR executes the fallback behavior “If the caller prefers not to leave a message or if the contact lacks an email address”. Here too, the prompts can be customized.

If the contact does not have an email address configured, the behavior associated with the case where the caller chooses not to leave a message is automatically applied (“If the caller prefers not to leave a message or if the contact lacks an email address”).