Best Practices, Tips, and Tricks

Handling Quick Replies

Nothing after a Quick Reply

Quick Replies are a temporary menu. The choices disappear from the chat window as soon as another message is sent — whether that message comes from the User or the Bot.

Consequently, Quick Replies should be the last output sent to the User. They should not be followed by Postprocess Code that invokes either sendImmediateReply() or setTriggerNextMessage().

Responding to Quick Replies

There are two ways to handle the User response from a Quick Reply:

When to use Pattern Matching

Pattern Matching is generally easier and more robust.

  • There’s less code to write.
  • You can use it to catch responses from several similar Quick Reply menus on different Bot Messages, without having to repeat your code.
  • The User can type the response, as well as select it from the menu, and get the same result.

When to use Process User Response

The problem with Pattern Matching is that it is not context-specific and doesn’t scale well. The most obvious example of this is that you cannot use Pattern Matching to handle Yes/No questions.

You should probably use Process User Response if:

  • The same (or similar) Quick Reply responses would lead to different messages.
  • You will have a lot of messages and pattern matching, and you want to avoid possible collisions.
  • You need a Payload to be returned along with the response. This is most often needed if you the human-readable Quick Reply is a stand-in for a value needed by Web Responder.

Pattern Matching Tips

Case Insensitive

Patterns are case insensitive. The following will all match the same pattern:

  • casedoesnotmatter
  • CaseDoesNotMatter
  • CASEDOESNOTMATTER
  • Casedoesnotmatter

Wildcards

There are four ways to use wildcard asterisks in a pattern:

  • Not at all: pattern
  • At the beginning only: *pattern
  • At the end only: pattern*
  • At the beginning and end: *pattern*

Using asterisks at the beginning and end is the most common approach. It is relatively robust and more future-proof than other approaches. You are more likely to run into collisions this way, though. So be careful.

No asterisks (pattern) is best for matching patterns to Quick Replies because it helps avoid collisions. Using a no-asterisk pattern to match natural inputs is difficult because Users are likely to add punctuation, leading or trailing spaces, or additional words.

Placing an asterisk only at the end is useful for creating commands the User can call:

  • order *
  • show me *
  • display *

You have to be careful with this approach too. What happens when the User says Please show me...?

Note

We don’t always include asterisks in this guide when talking about pattern concepts like Alternates.

You should know that in most applied cases, leading and trailing asterisks are a good idea.

Working with Alternates

Alternates can be used for synonyms:

  • (hi|hello|hey)
  • (yes|yeah|sure)

It can also be used for alternate spellings:

  • (color|colour)
  • theat(re|er)

Or for different grammatical endings (such as gender or tense):

  • act(or|ress)
  • latin(a|o|x|@)
  • work(|s|ed|ing) — This one has an empty option. It will match:
    • work
    • works
    • worked
    • working

Or common misspelling, typos, and omitted diacriticals:

  • r(é|e)sum(é|e)
  • accept(i|a)ble
  • a(| )lot
  • ch(ei|ie)f

You can combine multiple alternate patterns:

  • (doesnt|does not|doesn’t|isn’t|isn’t|is not) work(|ed|s|ing)
  • (who|what|which) (is|was|were)

You can even nest patterns:

  • (col(or|our)|hue|shade)
  • ((is|does|has|did)(nt|n’t| not))((go|work|do)(|ed|ing|s)) — This will match several ungrammatical constructions (isn’t gos, doesnt worked), but will also match many ways of saying something is broken:
    • isn’t going, isnt going
    • hasn’t worked, hasnt worked
    • did not do
    • doesn’t go, doesnt go
    • does not work

Thinking about language

The key to good pattern matching is thinking about how a user is likely to ask about something.

In the last example, the intention was to match User inputs related to a broken product. This could be stated negatively (it does not work) or positively (it is broken). This would probably require two patterns on a single Bot Message:

  • ((is|does|has|did|will|wo|were)(nt|n’t| not))((go|work|do)(|ed|ing|s))
  • (broke(|n)|busted|damage(|d)|defective)

For a specific product, you could include verbs that describe the product’s purpose in the “negative” pattern:

  • car — ((is|does|has|did|will|wo|were)(nt|n’t| not))((go|work|run(|n)|driv(|e)|start)(|ed|ing|s))
  • coffee maker — ((is|does|has|did|will|wo|were)(nt|n’t| not))((go|work|do|brew|drip(|p)|mak(|e))(|ed|ing|s))

Using Preprocess Code

Preprocess Code is executed before the Result is prepared. If you invoke sendImmediateReply() or botContext.setTriggerNextMessage(), the Result is never prepared.

This means that if you need response logic more complicated than simple pattern matching, you can use Preprocess Code to directly respond to User input — either with an immediate reply or by triggering another message — with JavaScript.

This technique could be used in a Default message to process any input that doesn’t match a pattern. Or it could be used in concert with Pattern Matching to parse starVar1 or starVar2 and route or respond to specific inputs.