Daniel Jones

Lisa Tam - would be great if you could provide an update on this, it's still a blocker for us.  Any information is appreciated.

Rachel Martin - did you ever find a solution or workaround?

Hi Lisa Tam,

Just wondering if you have any further information on whether this is on the roadmap or not?

Many thanks,
Daniel

Just to be clear, I'm not proposing that support for "Multi-line" text fields should be added to the "Ask for details" step.

We'd think it more appropriate that the "Send message" step has an option to wait for a response (as explained in my original argument above).

Hi Lisa,

After some further testing, I figured out why I wasn't able to get the "Ask for details" step to work with free/multi-line text, it appears that this is not supported.

The article "Why aren't all my custom fields appearing as options in the bot builder?" states:

You can only add text or drop-down custom fields to the bot builder.

I've verified this behaviour, custom fields of type "Multi-line" can't be added to the "Ask for details" step.

Hi Lisa,

Thanks for getting back to me.  At it's simplest, the example above is what we are looking to achieve, I.e.

1. "Hi Daniel, how can we help you today?"
2. [WAIT FOR RESPONSE]
3. [TRANSFER TO AGENT]

The "Ask for details" step (in my opinion) is a very robotic way of collecting open-ended or free text responses.  It doesn't feel conversational to be presented with a form field to collect this type of response.  I agree it has a place for very specific pieces of information, "Order Number", "Email Address" etc, where you'd perhaps want to process this further or have it be more machine readable to pass into other processes.

Another example would be if you want to ask multiple open-ended questions in succession, it seems cumbersome to require a custom ticket field for every possible question that you would want to ask, rather than the customer's answer just being part of the conversation (which the agent can read).

I should add too, that in my flow example above.  If the user is already authenticated, simply opening the messaging widget will create a ticket.

Hi Lisa Tam,

We are looking for the same feature that Rachel Martin has proposed.  It's preventing us from adopting Zendesk Messaging at the moment.

Essentially, we want to be able to ask the customer a question using the "Send message" step in Flow Builder, and then wait for them to respond before the flow advances to the next step.

Here’s a simplified version of what we are trying to build:

How this works in practice is as follows (this example follows the unauthenticated path, but it’s the same problem either way):

Essentially, we want to wait until they have responded to the question, before transferring them to an agent (otherwise a ticket is created without the context and the agent is sitting around waiting).

A “wait for response before proceeding to next step” option on the “Send message” step would solve this, or alternatively a new step “Ask a question” or something along those lines.  Other steps such as "Present options" already exhibits similar behaviour (I.e. waiting for a response before proceeding).

In theory we could use the “Ask for details” step to populate a custom ticket field ("Enquiry" perhaps), but this doesn’t seem ideal or suited to free text and isn’t very conversational (I.e. asking the user to complete a form).  Obviously there is a place for the "Ask for details" step, but my interpretation of this would be to use it where a specific piece of information is required (such as a Name or Email Address etc) rather than potentially long-form free text.  I did try this as a workaround but couldn’t get the flow builder to recognise the custom ticket field I had added, even then it's not really an acceptable solution in my opinion.

Hope this adds some weight behind this feature request.  It does seem like an obvious omission to me and something that could be resolved fairly quickly given that fundamentally - waiting is already supported by some of the other step types (Such as "Present options").

Hi Sergio,

Just to add our experience.  We've been aiming to use Zendesk Messaging for a long time now.  Initially the main blocker was the lack of authentication (and so there would have been no way for our agents to know who a customer was without asking them - a non starter).

Following the release of authentication support, the next issue was that the "external_id" wasn't surfaced by the API (like you describe, we are setting this to our internal id for a user).

The "external_id" that you supply as part of authentication is now surfaced from the Zendesk Support API on the user object as of mid August this year.

We already have an internal app/plugin that we have written for Zendesk Support which fetches user details, order history etc from our CRM and displays it to our agents.  Now that the "external_id" is available, we can use that - and so our plugin displays the customer name and email address to our agents.

Creating a Zendesk Support app/plugin is perhaps not the workaround you are looking for but it's definitely a solution.  There are other benefits in being able to surface any information/context you want to your agents all within Zendesk Support.

Our thoughts are that Zendesk Messaging has been very much a work in progress/draft since it was released, and prior to August this year pretty much unusable for anything real (unless you want a terrible customer experience).

It's now usable we think with the above caveat, but still not an out-of-the-box solution.  The improvements are arriving slowly, this is definitely "the future".  We've evaluated a lot of alternatives to Zendesk and they all seem to fall short in other ways (lack of native mobile SDKs, lack of support for particular channels etc) so I think Zendesk is the most comprehensive solution.

Hope this is helpful.

Thanks,
Daniel