Marius Wilhelmi

As follow up to my previous post above: we are looking into a workaround by using “Dynamic options”.  It looks like these are not translated. It is imo unnecessary complicated to be forced to load button labels from a server, but in our first test it seems to work. However, the next problem is that we would only like certain terms not to be translated on button labels (in the example below only “Native Access”), so I am not yet sure if we should solve this problem with “Dynamic options”.

There is a nice tutorial about implementing dynamic options.

Another strong vote to make the custom translation available for the options buttons. Since this is currently not possible, we completely need to switch off the multi-lingual support for the AI agent. There would be several ways to solve the problem:

1. Custom translation for the buttons directly
2. Support for dynamic content
3. Allow to use a predefined list of terms (like "entities") that are not translated automatically

I would prefer 2. or 3., while 3 could be helpful for the whole AI agent conversation in general.
There is a screenshot attached where you see that one of our product name “Kontakt” is automatically translated. In another case it translates a tool of us called “Native Access” that we do not want to have translated

Jahn yes, we found a workaround. While we never understood why this happens sometimes, we could just add the “ask for details” block in the bot editor and add the “name” and “email” system fields to be requested. These fields only pop up in the user journey if not yet filled, so when the authentication is successfuly, a user will not see these fields, otherwise the user has to enter name and email address to continue.

After some additional tests we found that the messaging widget actually does not ask for the email address in the moment when the JWT response token is undefined or includes an external_id which does not belong to any user in Zendesk. We saw in our JWT server logs that in some cases, although we use the signed_in condition in the help center, the "users/me" endpoint returns the following data:
"user_id": null,

"name": "Anonymous user",

"email": "invalid@example.com"

In order to find a solution for this problem, we will now offer users to log-in (again?) or file a support ticket via a different form if they have problems with the login.
It would be good though to understand, under which conditions the widget asks for the email if no JWT token is provided.

Same problem here. It happens very sporadically in our case though, like 1 in 100 cases. It looks like these customers are not authenticated at all, since we usually verify all customers via JWT. However, as far as I see, in these cases customers are not even asked for email and name, which would be the default behavior of the widget when non-authenticated start messaging. Any ideas how we can troubleshoot this issue?

Currently, all time-based triggers are available for Chat, but not for Messaging. This is probably related to the fact that both are different technologies. However, from a user perspective, the web widget looks pretty much like a chat client, and therefore there is an expectation of a real-time chat workflow with messaging.

One specific use case that we would like to implement after a handover to a human agent:

When a user waits more than 5 minutes without a response from a human agent, we want to send an automatic message to the user, e.g. that we have a created a ticket for the request and that we follow up at a later time.

We did not really find a good workaround for this, e.g. making this message dependent on the size of the waiting queue is not the same. With time-based triggers we could achieve a much better communication with the customer in case of longer waiting times.