SMS – Pendula for Enterprise

Working with SMS

SMS, or Short Messaging Service, is a powerful communication tool that allows businesses to engage directly with customers through concise, timely messages. Pendula enhances this by enabling conversational SMS, where recipients can respond to messages and trigger automated follow-up actions. Pendula integrates seamlessly with your data sources, enabling automated actions based on specific events or conditions such as payment confirmations, invoice deliveries, or the start of a customer relationship. This integration allows for dynamic and contextually relevant communications that keep your audience engaged and informed.

Best practices for SMS communications

Understand the legal obligations of using SMS

When using SMS for marketing and communication, it is crucial to comply with legal standards applicable to the countries you operating within. Best practices to ensure consumer protection and privacy:

Always obtain either express consent before sending marketing SMS. Without this, messages could be considered spam.
Clearly identify your organisation within the SMS to avoid any ambiguity about the sender.

The mobile phone number your SMS are sent from is unique to your business and will not change. You might like to suggest to your customers that they save this number or add it to their contact list for future communication.

Provide recipients with an easy and clear way to opt out of receiving further communications. This can be achieved by including a simple opt-out instruction in every message, such as "Reply STOP to unsubscribe."
Ensure you are capturing and referring to your customers' communication preferences when sending out SMS, and always have a clear path for them to opt out if they wish.

  Hi [Name], this is [Your Company Name]. Thank you for signing up for the event!
  Visit [Link] for details. To opt-out of future messages, reply STOP.

Start with accurate data management

Pendula is directly connected to your data source. Keep your data source clean and up to date to make the most of any SMS communication. This includes:

Consistently updating and verifying mobile phone numbers and communication preferences across your contact records. This ensures that your messages reach the intended recipients without errors.
Checking your database to eliminate duplicate records. Sending multiple messages to the same phone number can lead to increased costs and customer dissatisfaction.
Store mobile phone numbers in international format (e.g., +61 for Australia), without any extra characters like spaces or text. This standardisation is crucial for global message delivery and ensures that inbound messages are correctly associated with customer records.

Why do mobile phone numbers need to be stored in international format?
When a recipient replies to one of your messages, it's received by Pendula in this format (we support SMS from all over the world). Therefore, for Pendula to match this message back to the correct contact record in your data source they need to be stored in this format.
Correct Format: +61400123456
Incorrect Format: 0400 123 456 or 0400123456

Understanding SMS Segmentation and Concatenation

The most effective SMS content is relevant, interesting and easily understood. It's designed for sending short messages which are rapidly delivered, with a high read and response rate.

Segmentation

SMS messages are typically restricted to 160 characters. When your message exceeds this limit, it must be segmented. Each segmented part of the message can hold 153 characters, not the full 160, because additional characters are needed to manage and reassemble the message parts correctly on the recipient's device. Aim to communicate your message within the standard SMS length of 160 characters. This limit keeps the message concise enough for quick consumption without needing segmentation.

Concatenation

This is the process of linking segmented messages so that they appear as a single, continuous message on the recipient’s phone. This is done automatically by most modern mobile devices, which recognise the segments and stitch them together seamlessly.

This message is exactly 160 characters, fitting within one SMS segment.

  Quick reminder: Your appointment is scheduled for tomorrow at 3 PM. Please reply
  YES to confirm or NO to reschedule.

This message is 290 characters, which would be split into two segments. The first segment uses 153 characters, and the remaining 137 characters form the second segment.

  Thank you for your recent purchase from our store! We hope you are delighted
  with your new items. Remember, if you have any questions or need support, don't
  hesitate to contact our customer service team. We're here to help!

If your message strategy involves longer narratives, consider how smartphones and carrier limitations might affect the delivery. Keep your messages below 750 characters (approximately 5 concatenated segments) to ensure compatibility and delivery across all devices and networks.

Managing non-GSM characters in SMS

When incorporating non-GSM characters—such as emojis or characters from non-Latin scripts—into SMS messages, understanding their impact on segmentation and encoding is important

Typically, SMS messages use the GSM-7 character set, including letters, numbers, and common punctuation, each encoded in 7 bits, allowing up to 160 characters per SMS.

Non-GSM characters require UCS-2 encoding, which uses 16 bits per character. This change reduces the maximum length to 70 characters per SMS. Each segmented SMS can then only contain 64 characters due to the additional space needed for headers. Non-GSM characters, like emojis, often consume more space than GSM characters. Most emojis count as two characters, but newer ones might take up to four. Messages with non-GSM characters are segmented when they exceed 70 characters, with each segment able to contain only 64 characters. This needs careful management to avoid unexpected costs and message fragmentation.

For a detailed guide on non-GSM characters, see Understanding non-GSM characters.

Pendula helps you identify when a non-GSM character is introduced to your intended messaging.

Stick to the GSM-7 character set, which include letters of the English alphabet, numbers, and common punctuation marks or symbols such as !,'@%$=.?/().. Avoiding characters outside this set ensures that your message remains within the single SMS limit and avoids potential delivery issues.

Certain symbols, like curly brackets {} or the Euro symbol €, consume more than one character space. Using these sparingly can prevent unexpected message segmentation.

Keep your messaging relevant and valuable to your customers

To maintain customer interest and satisfaction, it is essential to ensure that every SMS sent holds significance for its recipients. Irrelevant messages not only disrupt the customer but also increase the likelihood of them perceiving the communication as spam.

Merge fields act as placeholders within your SMS template, which are automatically filled with specific data from your database when messages are sent. You can use a recipient’s first name to address them directly in the SMS, making the message feel more personal and engaging.

  "Hi {{First Name}}, don't forget your appointment on **{{Appointment Date}}**
  at {{Time}}. Reply YES to confirm."

For a detailed guide on Merge Fields, see Working with Merge Fields in Workflow Studio

Limit your CTA to one or two options

Ensure your call to action is clear and straightforward, so recipients aren't confused on how they are supposed to respond. Providing too many different reply options increases the margin for error and generally makes for a worse experience. If there is a lot of information you wish to capture via SMS, consider breaking this up over a series of messages with a question and answer approach for a seamless and easy to follow conversation.

"To confirm your appointment, reply YES. For rescheduling, reply NO."

If the interaction requires more detailed responses or multiple pieces of information, consider deploying a series of messages, each with a clear, actionable step. This approach helps maintain engagement without overwhelming the recipient.

Keep inbound responses unique

In SMS communication, the context of a response is primarily discerned from the sender's mobile phone number and the message content. This direct and straightforward method differs from channels like email, where additional metadata can provide context.

Pendula allows for the automation of SMS-based conversations by setting specific expected responses to sent messages. If a response from a recipient perfectly matches a predefined expectation, automated actions can be triggered accordingly. To ensure clarity and effectiveness in automated SMS interactions, it's critical to designate unique response triggers for different messaging campaigns. When multiple messages request the same response, it can lead to confusion about which message the recipient is responding to. For instance, if two promotions are sent to the same contact and both anticipate a 'YES' reply, it will be unclear which promotion the 'YES' refers to.

Instead of using a generic reply like 'YES' for multiple offers, tailor the responses to be distinct:

"Reply YESDEAL to accept the 20% discount offer."
"Reply YESTICKET to confirm your event ticket purchase."

Use specific keywords that relate directly to the message content, reducing the likelihood of overlap and ensuring responses can be accurately matched to the correct interaction.
Communicate clearly in the SMS what the expected response should be, using straightforward language that ties directly back to the message's call to action.

Pendula SMS capabilities

Reply matching

Pendula's reply matching feature automates SMS responses by recognising specific keywords in incoming messages. This allows for predefined actions to be triggered based on customer replies, streamlining interactions and ensuring timely, relevant communications. For example, responses to promotional SMS such as "YES" to accept an offer or "NO" to opt out can automatically initiate appropriate follow-up actions, enhancing efficiency and customer engagement.

For further information, see How reply matching works

Rules and recipes

Rules allow you to define conditions for acceptable replies, such as specific keywords or formats. This helps in tailoring responses that trigger specific actions within your SMS workflows. Recipes are predefined rules that simplify setup by providing common response patterns. This makes it easier to quickly deploy interaction scenarios without crafting conditions from scratch.

For further information, see Rules and recipes

Nodes for SMS management

Inbound message trigger node

Initiates a flow when a specific SMS message is received. It is configured to recognise predefined keywords or phrases within the text message, facilitating instantaneous engagement with customers.

For further information, see Inbound message trigger node

Conversation action node

Handles two-way SMS interactions, enabling conversations that can adapt based on customer responses.

For a detailed guide, see Conversation node

Outbound SMS node

Sends a single SMS to a designated recipient. The node offers two outcome paths based on message delivery status—sent and not sent. It handles fallbacks and failures by tailoring experiences based on these outcomes.

For a detailed guide, see Outbound SMS

Workflow action nodes

Workflow action nodes in Pendula enhance the flexibility and efficiency of SMS campaigns by allowing for dynamic responses based on evolving criteria. These nodes can re-evaluate conditions midway through a customer journey, segment recipients into tailored pathways, and integrate valuable feedback directly into your data systems. By orchestrating multiple interactions within a single flow, they effectively synchronize your SMS strategies with broader business processes. This functionality is crucial for adapting communication tactics based on progressing leads, or updating database records based on interactive customer responses.

Reference

Inbound message trigger

Complete overview of Flow Builder

The Inbound message trigger initiates a flow when it detects incoming messages that meet specified criteria or rules. This ensures that your automated workflows respond appropriately to each relevant customer interaction.

Understanding rules and recipes

Rules are specific conditions that a message must meet to trigger a response. These conditions can be based on the content of the message, such as keywords or phrases. Recipes are predefined sets of rules designed to match common patterns such as email addresses, phone numbers and more. They simplify the process of setting up common reply scenarios.

Merging rules and recipes within a path allows for comprehensive coverage of potential customer responses, ensuring the flow can handle the varied ways customers might respond.

For a detailed guide on each, see Rules and recipes

Usage scenario

The example below demonstrates the use of the Inbound Trigger Node within a flow that initiates an experience when a customer expresses interest in an event. By replying with ATTEND, the customer indicates their intention to attend the event, while replying with CONTACT signifies an interest to get in touch with the organisers. The Inbound Message Trigger node evaluates the different replies and appropriately routes the flow to handle each specific request.

Configuring the trigger

Path labelling
You can define clear labels for each path. These labels appear on the canvas, providing a visual representation of message routing within your flow.

Defining trigger criteria
Determine the specific conditions—known as rules or recipes—that incoming messages must meet to initiate the flow.

Implementing OR logic within paths
Multiple rules or recipes can be set within a single path, where each is connected with "OR" logic. This means that if an incoming message matches any of the listed conditions, it will follow that path.

If a reply matches several paths, the topmost path or rule will always take precedence. If a reply matches several triggers, all matching triggers will be fired.

Prioritisation in reply matching

The Inbound Message Trigger starts a flow in response to incoming messages that meet specific criteria. When a message is received, a systematic prioritising exact keywords before considering broader rules.

1. Active Conversations
The system checks if there are any ongoing conversations with the sender. If so, it looks for a match within these conversations first, prioritising exact keywords before considering broader rules.

2. Inbound SMS Triggers
If the message does not fit into any active conversation, the system then attempts to match it with any Inbound SMS Triggers. Here, all triggers that detect the keyword are activated.

3. Match Priority
Within a node, if multiple paths or rules could match a reply, the system follows the top-down priority. The first path or first rule of a path that aligns with the incoming message takes precedence.

4. Unmatched Messages
Messages that do not correspond with any active conversations or triggers are labeled as “unmatched.” If you have an Unmatched Message Trigger flow set up, it will then handle these messages to ensure no communication is left without a response.

For a detailed explanation on setting up an unmatched message trigger, see Unmatched Message Trigger Node.

For a detailed explanation, see How reply matching works and Best practices for creating two-way conversations with reply matching.

When an inbound message comes into Pendula, both the phone number and the keywords in the message body are used to match an inbound message to a flow and continue the recipient down the correct path of their customer journey.
What happens if the message matches two or more flows?
Only the most recent flow will be matched.
What happens if it matches a recipient number, but no flows?
When Pendula receives an inbound message, first it checks if it will trigger an active flow with an inbound message node trigger. If there’s no match, then Pendula looks for any messages that might have been sent to this number; if it was expecting any keywords from this number as part of a conversation node (outbound SMS) in any active flow.
What happens if it doesn’t match either a recipient number, or a flow?
The message will be persisted into the database and Pendula will publish an UnmatchedMessageEvent to the event queue.

Mergefield explorer

Mergefields function as dynamic placeholders within a flow, automatically populated with actual data as the flow progresses. Below are key mergefields accessible in subsequent nodes following the Inbound Message Trigger

Mergefield name	Description	Possible outputs	Definition and examples
`fromNumber`	The number from which the message was received		"+61 400000000"
`matchedIntent`	The intent/branch matched based on the message content		Indicates the flow's path or intent that the incoming message has triggered, based on its content (e.g., “YES”).
`matchedPart`	The part of the message that matched the rule		Specifies the segment of the inbound message that fulfilled the criteria of a rule. This is helpful when the Contains rule is used. For example, "annie@acme.com" would be the matched part of the message "my email is mailto:annie@acme.com
`matchedType`	Classifies the kind of rule match that prompted the flow to activate. This can be used in later nodes such as Criteria Filter.	Exact Match (Trigger)	An inbound message has been matched to the is exactly rule in an Inbound SMS Trigger Node.
		Rule Match (Trigger)	An inbound message has been matched to a free response, a rule or recipe in a Inbound SMS Trigger Node.
`messageBody`	The entire body of the inbound message		“Yes, thank you”.
`timeStamp`	The time at which the message was received in Unix Epoch time in milliseconds		“1672534861000”

Opt-in and opt-out flows

Opt-in and opt-out trigger flows should be used as final 'catch all' flows. Triggers contain limited context, meaning if a customer decides to opt-out mid-flow, you would not be able to see which flow caused the opt-out. Instead, in your marketing flows, add opt-in and opt-out paths of your Conversation Nodes for a richer context.

For other best practices, see Best practices for creating two-way conversations with reply matching.

Opt outs will not affect active flows. This means if a recipient is mid-way through an active flow and triggers an opt-out flow, they won’t drop out of the active flow. They will however, be excluded from any new flows. For example, if Pendula is waiting on a reply from a particular number and that person messages 'STOP' (as an opt-out) and then messages 'CONFIRM' in response to the original offer, the flow will continue on the 'CONFIRMED' path.

In the following example, we have two flows.

Flow I triggers an experience when the keyword OFFER is used. The flow prompts the customer to either CONFIRM or DECLINE the offer and based on the reply, sends outbound SMS.

Flow II is an opt-out flow that triggers an experience when the keyword STOP is used. The flow updates the CRM, and sends the confirmation outbound SMS to the customer.

Here is an example conversation where the person messages 'STOP' (as an opt-out) and then messages 'CONFIRM' in response to the original offer, the flow will continue on the 'CONFIRMED' path.

Reference

Unmatched message trigger

Complete overview of Flow Builder

The Unmatched message trigger is a global flow that is triggered whenever a message is marked as “Unmatched”, when UnmatchedMessageEvent is published to the event queue. A message is marked as “Unmatched” when a received message is not matched to any active Conversations or Inbound SMS message triggers, thus effectively addressing messages that otherwise would remain unprocessed.

Only ONE unmatched trigger flow can be active at a time. Drafts can be created but cannot be activated if there is a duplicate.

Usage scenario

The following example demonstrates a practical application of the Unmatched Message Trigger within a flow, illustrating how these messages are processed to ensure no customer inquiry goes unaddressed.

Send all Unmatched messages to your system of record, and let the customer know the message has been received and an agent will be in touch shortly.

When an Unmatched message is received, start a conversation with the customer which seeks to clarify the intent of their message. Send the message body from both the trigger and Conversation node to your system of record, and let the customer know the message has been received and an agent will be in touch shortly.

Configuring the trigger

This trigger requires minimal setup. Simply ensure that it's active within your desired flow to begin capturing any unmatched inbound SMS messages.

Mergefield Explorer

Mergefields function as dynamic placeholders within a flow, automatically populated with actual data as the flow progresses. Below are key mergefields accessible in subsequent nodes following the Unmatched Message Trigger

Mergefield name	Description	Definition and examples
`fromNumber`	The number from which the message was received	"+61 400000000"
`messageBody`	The entire body of the inbound message	“Yes, thank you”.
`timeStamp`	The time at which the message was received in Unix Epoch time in milliseconds	“1672534861000”

Given the limited mergefields, scenarios requiring comprehensive context—such as understanding the specific prompt a customer is responding to—might not be fully addressed.
For example, if a customer replies with feedback in response to an upsell flow, the context such as what the customer was replying to would not be included in this trigger. In this scenario, we recommend adding a free reply path to your conversation node instead to capture and send it to your platform.

To learn more, see Best practices for creating two-way conversations with reply matching.

Reference

Conversation node

How does reply matching work?
Best practices for creating two way conversations with reply matching

Configure your customer conversations based on anything you receive and progress flow experiences based on what a reply contains, all through the Conversation node on the canvas.

The conversation node allows you to ask your customer a question through the Outbound SMS tab and craft the reply paths depending on their reply through the Replies tab. Before configuring the Replies tab, we strongly recommend reading how Reply Matching works and best practices for configuring workflows with rules.

Usage scenario

The following example demonstrates a practical application of the Conversation message action node within a flow, that sends an confirmation message following a inbound message trigger. Depending on the reply, the experience follows it’s respective path.

Configuring the action

Outbound SMS

Edit the outbound SMS, replies and the reply expiry settings. You can refer to the merge fields section to see how to reference a merge field.

Values in the recipient field must follow the internationally standardised E.164 format: [+] [country code] [recipient number including area code]. For example, an E.164 format Australian number: +61400000000.

Total characters

The number of characters in your message. Not that this does not account for the merge field values – depending on what it renders to, the final character count will vary.

Non-GSM characters

Non-GSM characters (e.g. emojis) are characters that increase the size of your SMS. These can be identified with the orange highlights over these characters.

Copying and pasting from other programmes such Microsoft Word or Google Docs will surface any non-GSM characters present. These will be highlighted automatically.

Learn more about non-GSM characters and SMS size here.

Preview and test

You can also view a preview of the message as it will appear to recipients in the conversation preview.

Replies

In the replies tab, you can label a path’s name (appears on the canvas) and define how responses are matched to this path. You can tailor what happens in each path, in later nodes.

There are two ways to match responses to a path: 1) Expected reply or 2) Free reply.

Expected reply

Expected replies are replies you anticipate on receiving. This includes listening for exact keywords, a certain phrase or word(s) within a sentence, or formatted text (such as email addresses or mobile numbers). You can choose from a pre-written recipe, or build your own 'rule'.

You can add as many rules or recipes within a path. The relationship between each rule/recipe is "OR".

If a reply matches several paths within a node, the topmost path or rule will always be matched. If a reply matches several rules across different active conversations, the reply will be matched with the recipient's most recent conversation. Learn more about Reply Matching

Free reply

Free replies are replies that anything your customer say. They do not have to fulfil any rule to be matched as a 'free reply'. A free reply can contain alphanumeric characters, with or without emojis, and other special characters (such as è). We recommend having a Free Reply path for most flows to ensure unprompted customers replies to your message can be matched to this experience. Learn more about best practices

When the Free Reply path is enabled, it will always be positioned as the last path. This is because if a reply can match multiple paths in a node, the top-most path is always matched first. Learn more about rules, regex and recipes

Outcomes

Configure different experiences based on the outcomes of this node:

Replies
The experience continues on the path if an inbound reply is matched to an expected or free reply path. Reply paths can be configured in the Replies tab. Refer to Mergefield explorer section to see possible outputs.

Not sent
The experience will either end or continue on this path depending on the toggle settings. Specifically, the Outbound SMS part of this node has failed to send due to an error.
When toggled off, the experience will end and exit the flow. When toggled on, the Not Sent path will be visible on the canvas, and the experience on this path can be configured. Refer to Mergefield explorer section to see possible outputs.

No reply
Depending on its toggle settings, the experience will either end or continue on this path if no reply is received after the reply expiry period has elapsed. By default, this configurable reply expiry time is set to 2 days.

This configurable wait time determines how long Pendula should keep the flow open to inbound replies. Once the wait time has elapsed with no reply received, the experience will continue on this 'No reply' path. The flow will no longer match the recipient's inbound messages to the keywords in this flow. You can change the wait time by clicking on the pencil icon.

When toggled off, the experience will end and exit the flow. When toggled on, the No Reply path will be visible on the canvas, and the experience on this path can be configured. Refer to Mergefield explorer section to see possible outputs.

Please note this is different to offer expiry. Reply expiry lets your flow successfully ‘complete’. If you want to build offer expiry functionality into your Pendula flow, you should use criteria split nodes. Learn more about criteria split nodes here.

Mergefield explorer

In later nodes, when viewing the available mergefields for the Conversation node in mergefield explorer you can expect to see:

Mergefield name	Description	Possible outputs	Definition and examples
matchedIntent	The path label (string)	Example: "Yes" would be the matched intent from the path named "Yes".
matchedPart	The part of the message body that was matched with your rule (string)	Example: "annie@acme.com" would be the matched part of the message "my email is annie@acme.com".
matchedType	The reason why a message was matched (string)	`Exact Match (Conversation)`	An inbound message has been matched to the `is exactly` rule in a Conversation Node.
matchedType	The reason why a message was matched (string)	`Rule Match (Conversation)`	An inbound message has been matched to a free response, a rule or recipe in a Conversation Node.
outcome	The final Outbound SMS message delivery status (string)	`success`	The Outbound SMS message was sent to the mobile carrier for delivery, and an inbound message was matched to a path in this node. The experience will continue on the 'Sent' path.
outcome	The final Outbound SMS message delivery status (string)	`failure`	The Outbound SMS message failed to be sent. See outcomeReason (below) for possible reasons. The experience will continue (if configured) or exit the 'Not Sent' path.
outcomeReason	The reason for a message delivery (string)	`expired`	No reply was received within the configure timeframe. The experience will exit the flow.
		`reply`	An inbound SMS was matched to a reply path in this node. The experience will continue on the 'Sent' path.
		`failed: [reason]`	The carrier has accepted the Outbound SMS message, but encountered an error while sending it to the recipient. The experience will continue along the 'Not Sent' path (if configured) or exit the flow.
		`failed-normalization`	The recipient's phone number is invalid. Ensure it is present and in the correct E.164 format. The experience will continue along the 'Not Sent' path (if configured) or exit the flow.
		`other-error`	Another error was found while sending the Outbound SMS message to the recipient. Contact Support for further troubleshooting. The experience will continue along the 'Not Sent' path (if configured) or exit the flow.
		`rejected`	The carrier has rejected the Outbound SMS message. The experience will continue along the 'Not Sent' path (if configured) or exit the flow.
		`validation-error`	An invalid value was found in the node. Ensure your message body is not empty, and that your expiry time is between 1-10 days. The experience will continue along the 'Not Sent' path (if configured) or exit the flow.
timestamp	The time at which the message was received in Unix Epoch (milliseconds)	Example: "1714975027"

Reference

Outbound SMS

Complete overview of the flow builder

Send a single SMS to a designated recipient. The node offers two outcome paths based on message delivery status—sent and not sent. Handle fallbacks and failures by tailoring experiences based on these outcomes.

An Outbound SMS progresses on the Sent path after 10 minutes by default. This wait time is configurable, and exists to monitor for any sending failures that may occur. Learn more in Outcomes section of this article

Usage Scenario

The following example demonstrates a practical application of the Outbound SMS within a flow, that sends an confirmation message following a event sign-up.

Configuring the action

Settings

Edit the recipient field and the message body. Refer to the merge fields section to see how to reference a merge field.

Values in the recipient field must follow the internationally standardised E.164 format: [+] [country code] [recipient number including area code]. For example, an E.164 format Australian number: +61400000000.

Total characters

The number of characters in your message. Not that this does not account for the merge field values – depending on what it renders to, the final character count will vary.

Non-GSM characters

Non-GSM characters (e.g. emojis) are characters that increase the size of your SMS. These can be identified with the orange highlights over these characters.

Learn more about non-GSM characters and SMS size here.

Copying and pasting from other programmes such Microsoft Word or Google Docs will surface any non-GSM characters present. These will be highlighted automatically.

Preview

This is how the message will appear to recipients.

Outcomes

Configure how the experience should continue after this node depending on outcomes of this node.

The possible outcomes of the Outbound SMS are:

Sent

The experience will continue on this path if no failure notifications are received within the default wait time of 10 minutes.

This configurable wait time exists to monitor for any sending failures that may occur after the SMS has been sent to a mobile carrier for delivery. You can change the wait time by clicking on the pencil icon, and when edited, the 'Not sent' wait time will be synced too.

For example, if a sending failure occurs within the default 10 minute wait time, the experience will progress onto the 'Not Sent' path. If no sending failures occur within the default 10 minute wait time, the experience will progress onto the 'Sent path'.

Not sent
The experience will either end or continue on this path (depending on its toggle settings) if a sending failure has occurred within the default wait time of 10 minutes.

This configurable wait time exists to monitor any sending failures that may occur after the SMS has been sent to a mobile carrier for delivery. You can change the wait time by clicking on the pencil icon, and when edited, the 'Sent' wait time will be synced too.

When toggled off, the experience will end and exit the flow. When toggled on, the Not Sent path will be visible on the canvas, where you can further configure the experience on this path. You can refer to Merge fields section below to personalise experiences continuing on this path.

Merge fields

You can reference any merge fields from nodes previous to this node. Learn more about merge fields

In later nodes, when viewing the available merge fields for the Outbound SMS node in merge field explorer you can expect to see:

Merge field	Description	Possible outputs	Output definition
outcome	The final message delivery status (string)	`success`	The message was sent to the mobile carrier for delivery, and no failure notifications were received during the set time period. The experience will continue on the 'Sent' path.
outcome	The final message delivery status (string)	`failure`	The message failed to be sent. See outcomeReason (below) for possible reasons. The experience will continue along the 'Not Sent' path (if configured) or exit the flow.
outcomeReason	The reason for a message delivery (string)	`success-timeout`	The SMS was sent to a mobile carrier for delivery, and no failure notifications were received during the set wait time. The experience will continue on the 'Sent' path.
		`failed: [reason]`	The carrier has accepted the message, but encountered an error while sending it to the recipient. The experience will continue along the 'Not Sent' path (if configured) or exit the flow.
		`failed-normalization`	The recipient's phone number is invalid. Ensure it is present and in the correct E.164 format. The experience will continue along the 'Not Sent' path (if configured) or exit the flow.
		`other-error`	Another error was found while sending the message to the recipient. Contact Support for further troubleshooting. The experience will continue along the 'Not Sent' path (if configured) or exit the flow.
		`rejected`	The carrier has rejected the message. The experience will continue along the 'Not Sent' path (if configured) or exit the flow.
		`validation-error`	An invalid value was found in the node. Ensure the message body is not empty. The experience will continue along the 'Not Sent' path (if configured) or exit the flow.

Reference

Rules and recipes

In this article, you'll learn how to use rules, recipes, and custom regex patterns to manage customer replies in the Conversation Node and Inbound SMS Trigger node. These tools help you set up conditions for accepted replies, such as emails, mobile numbers, or specific keywords.

Key concepts

Rules are specific conditions that a message must meet to trigger a response. These conditions can be based on the content of the message, such as keywords, phrases, or patterns.

Recipes are predefined sets of rules designed to match common patterns such as email addresses, phone numbers and more. They simplify the process of setting up common reply scenarios.

Within Pendula, you can use Preview & test to send test messages and verify if the message matches the rule set.

Rules

Go to the node where you want to add a rule.
Provide a label for the path to clearly identify the purpose of this rule set.
Click on Add Rule to begin the rule creation process.
From the dropdown menu, select the type of rule you want to create. For example, you can choose "Contains word".
Input the specific value that the rule will match in the Value field. For example, enter "promo" to match any message containing the substring "promo".
To create more complex matching criteria, click Add rule or Add recipe to include additional rules. This allows you to build comprehensive conditions for matching inbound messages.
Use the Preview & test to send test messages and verify if the message matches the rule set. If the message matches, it turns green.

Rule Type	Description	Example
Includes text	The received message can include the given text anywhere within. The match is case in-sensitive, and even with additional characters attached, the word will still be matched.	Rule: Includes text "promo"
		Matches: "Get the promo now!"
		Matches: "Promotions are here!"
Contains word	The received message must contain the specified entire word or phrase. The match is case in-sensitive, and cannot contain additional characters attached to the word (must be enclosed by spaces).	Rule: Contains word "yes"
		Matches: "Yes, please!"
		Does Not Match: "yesss"
Is exactly	The received message must match the case-insensitive value letter-for-letter without additional characters such as exclamation marks or emojis.	Rule: Is exactly "STOP"
		Matches: "stop"
		Does Not Match: "stop now"
Is exactly (case sensitive)	The received message must match the case-sensitive value letter-for-letter without additional characters such as exclamation marks or emojis.	Rule: Is exactly (case sensitive) "Hello"
		Matches: "Hello"
		Does Not Match: "hello"
Starts with	The received message must begin with the specified sequence of characters.	Rule: Starts with "Buy"
		Matches: "Buy now!"
		Does Not Match: "Please buy now!"
Ends with	The received message must end with the specified sequence of characters.	Rule: Ends with "thanks"
		Matches: "Many thanks"
		Does Not Match: "Thanks for everything"

Using emojis

When you are creating reply matching rule with emojis, we recommend using only the Includes text rule type, and the default emoji variation to ensure all skin tone variations are matched.

For example:

- "Includes text "👍" will match to any reply containing **any** of these variations: 👍 👍🏻 👍🏼 👍🏽👍🏾 👍🏿".
- "Includes text "👍🏾" will only match replies containing "👍🏾". All other skin tone variations will not be matched.

To consider: Apple and Android message reactions

Apple and Android devices allow users the ability to 'react' to a message. These reactions are received by Pendula as valid replies and will be matched accordingly. You can use the rule Starts with and the value of the react type (e.g. Loved "), for each device type, to cater for these replies.

Reaction	Device	Reply received by Pendula
	Apple	Loved "[Original SMS]"
	Apple	Liked "[Original SMS]"
	Apple	Disliked "[Original SMS]"
	Apple	Laughed at "[Original SMS]"
	Apple	Emphasised "[Original SMS]"
	Apple	Questioned "[Original SMS]"
	Android	❤️ to ' [Original SMS]'
	Android	👍 to ' [Original SMS]'
	Android	👎 to ' [Original SMS]'
	Android	😂 to ' [Original SMS]'
	Android	‼️ to ' [Original SMS]'
	Android	❓ to ' [Original SMS]'

Recipes

A recipe is a pre-written rule. You can browse and add a recipe by selecting "Add recipe". Below are examples of what is and isn't accepted according to the recipes.

Recipe	Replies are matched to this rule if it...	Matched examples	Unmatched examples
Email address	Contains an email address – a username, followed by @ symbol, a domain name and top-level domain (e.g. "com", "org").	`harry@hatman.com`, `My email is harry@hatman.com` (The email itself can be extracted with ‘matchedPart’ mergefield)	`@hatman.com`
Mobile no. (AU)	Contains a valid Australian mobile number. A reply can start with `04`, `614`,`+61`	`0400000000`, `+61400000000`, `61400000000`, `My mobile number is 61400000000` (The mobile number itself can be extracted with ‘matchedPart’ mergefield)	`04000`
Mobile no. (UK)	Contains a valid UK mobile number. A reply can start with `0`, `44`,`+44`and can be proceeded with 4-10 digits.	`07890 111111`, `+4400000000`, `4400000000`
Number	Contains standalone numbers, without accompanying words or alphabet characters. Includes decimal numbers and integers, but not negative numbers.	`1`, `3.14`, `1000000`	`-1`, `I give this a 10/10`, `1,000,000`
No	Contains "no", "nope", or "nah" as standalone words.	`no thanks`, `nah...`	`nothx`, `decline`, `👎🏼`
Yes	Contains "yeah", "yep", or "yes" as standalone words.	`yes!`, `yeah nah`	`yespls`, `yes👍🏼`, `👍🏼`
Opt-out	Exactly matches (non case-sensitive) `Stop`, `stopall`, `unsubscribe`, `cancel`, `end` or `quit`,	`STOP`, `CaNcEL`	`Please stop sending me messages` , `UNSUBSCRIBE!`
Opt-in	Exactly matches (non case-sensitive) `Start`, `Unstop`	`Start`, `unstoP`	`Start sending me messages again` , `unstop?`

Using mergefields

Mergefields allow you to dynamically reference parts of a matched message in subsequent workflow steps. This is particularly useful for creating personalised responses and handling data dynamically.- Access the matched part of the message using the mergefield explorer. For example, the mergefield 'MatchedPart' (a 'string') can be used to reference the exact part of the message that triggered the match.

If a customer replies with an email address that matches a recipe, you can reference this email address later in your workflow to send a confirmation email or update a customer record.

Adding multiple rules and recipes

You can add multiple rules and recipes to a single path, allowing for flexible and comprehensive reply matching. This enables you to handle various types of customer replies efficiently.

When a message matches any rule or recipe in a path, it will follow that path. The relationship between each rule and recipe is "OR," meaning that if a reply matches at least one of the rules, it will be matched to that path.

How does reply matching work?

Reply matching operates based on specific rules for determining which path a message will follow:

If a reply matches multiple paths within the same node, the path positioned highest in the node's configuration will be matched.

Overlapping Rules.png

If a reply matches rules across different active experiences, the reply will be matched to the customer's most recent conversation. Consider Annie, who is in two marketing flows that both listen for the keyword UPGRADE. The first offer is sent at 8 am, and the second at 9 am. When she replies with UPGRADE, her reply is matched to the second flow since it is the most recent interaction.

Concept

How reply matching works

How to

Best practices for creating two-way conversations with reply matching

When creating flows that contain complex rules in the Conversation Node or Inbound SMS triggers, it's important to consider how to handle both free replies and expected responses. Leverage how reply matching works and optimise your flows with the tips and tricks below.

Expected replies are specific responses anticipated by the flow, often defined by the rules and conditions set within the Conversation Node or Inbound SMS triggers. These replies are usually predefined and matched against specific keywords or phrases. Expected replies help ensure that the flow follows a predictable and controlled path, leading to precise outcomes.

Free replies are open-ended and not predefined. These are responses that do not match any specific expected keywords, phrases, or patterns. Free replies require more flexible handling. This can involve natural language processing (NLP) to interpret and categorise the response.

How do I reply to customers dynamically and sensitively in workflow?

In use cases such as survey flows, you can leverage the Natural Language Processing node paired with the Criteria split to determine the sentiment and branch off different experiences depending on how your customers reply.

Please contact Pendula for access to NLP nodes.

How do I best include emojis in my reply matching configuration?

When you are creating reply matching rule with emojis, we recommend using only the Includes text rule type, and the default emoji variation to ensure all skin tone variations are matched.

For example:

"Includes text "👍" will match to any reply containing any of these variations: 👍 👍🏻 👍🏼 👍🏽👍🏾 👍🏿".
"Includes text "👍🏾" will only match replies containing "👍🏾". All other skin tone variations will not be matched.

How do I make sure customers don't upgrade or purchase something by accident?

You can leverage exact matches as a double opt-in method or final purchase confirmation. Exact matches should be used sparingly as it anticipates the exact keywords you specify. Any variation to the keyword, including punctuation will not be matched.

For example, the exact-match keyword UPGRADE123 can be used as a double opt-in or a final purchase confirmation. Other rules such as Contains word or Includes text should not be used in this scenario to prevent accidental purchases.

How do I process an opt-out

Consider having 1 global opt-out flow, 1 global opt-in flow and have each marketing flow have an opt-out path for detailed reporting on customer activity.

In each Conversation node of a marketing flow, we recommend having an opt-out path using the opt-out recipe. Configuring your flows this way will ensure an "opt-out" request contains maximum contextual information, such as which flow or message prompted this action. You can then send this opt-out prompt to your platform, complete with its context.

The global opt-out and opt-in flows serve as the 'catch all' for these requests, but will only contain limited context (mobile number, timestamp and message body). Information such as which flow or message prompted this action will not be captured.

How do I create custom rules?

The pre-written recipes are designed to be all-purpose, however depending on the context of your flow you can also add additional rules to capture a customer's intention.

For example, in an appointment confirmation flow, words like "Attend" and "Confirm" are specific to the nature of an appointment and can be added to the 'Yes' path.

Frame 522.png

How do I ensure unexpected replies are captured in a flow?

A customer may reply with something that is not an exact match. These can be captured by adding a free reply path for re-prompting or to pass this information to your platform. It's important to set the reply expiry on this node in consideration of other active conversations the customer may be in. This is because any reply from the customer (other than an exact keyword match) will be matched to this conversation.

Known limitations: Configuring Reply Matching for Apple and Android reactions

When customers may 'react' to a message, this reaction counts as a reply, and is reflected in History.

For example, when a recipient clicks on a message reaction, it's returned as an inbound message containing the reaction and original content of the SMS. In History, you would expect to see the image below:

This means Pendula will attempt to match the message according to the Reply Matching rules.

Currently, there is no way to include the full message with merge fields and the line breaks in the rule builder. However, we can suggest using the last few words of the original SMS content as a workaround.

How to set up the work-around

In the Conversation node, you can configure the following rules as the first path in the Replies tab:

Rule Value Notes

Ends with

[Last few words of the Outbound SMS]'

Insert the last few words of the Outbound SMS from the corresponding Conversation node. Make sure the words from the Outbound SMS do not contain merge fields or line breaks.

For example, Please reply 'YES' to confirm.'.

This rule will match any reaction reply from an Android device.

Ends with

[Last few words of the Outbound SMS]”

Insert the last few words of the Outbound SMS from the corresponding Conversation node. Make sure the words from the Outbound SMS do not contain merge fields or line breaks. Take note end quotation mark ” is used, not the inch mark ".

For example, Please reply 'YES' to confirm.”.

This rule will match any reaction reply from an Apple device.

This will match reaction messages and continue the experience as configured in the workflow.

While this particular limitation is currently present, we will be addressing this as an item on our roadmap for future development. Subscribe to What's New at Pendula to be notified of it's release.

As best practice, we also suggest having an active Unmatched flow as the fallback to mitigate any more unexpected replies.

Reference

Understanding non-GSM characters

Working with SMS

What are GSM characters?

GSM characters refer to the standard character set used for encoding SMS messages. This set, known as GSM 7-bit alphabet, includes the following:

Letters of the English alphabet (both uppercase and lowercase).
Numerical digits (0-9).
Common punctuation marks and symbols, such as !,'@%$=.?/().

These characters are designed to be compact, with each character encoded using only 7 bits. The efficiency of this encoding allows a standard SMS to contain up to 160 characters.

  Your appointment is on 20th June at 3 PM. Please confirm by replying YES or NO.

This message is within the 160 character limit and uses only GSM characters.

What are non-GSM characters?

Non-GSM characters include any characters that do not conform to the GSM 7-bit standard. These require a different encoding scheme, typically UCS-2 (16-bit), which expands the character set to include:

All types of emojis.
Characters from non-Latin scripts such as Arabic, Chinese, or Cyrillic.
Special symbols that are not covered by the GSM character set, like the Euro symbol € or curly brackets {}.

Certain symbols, like curly brackets {} or the Euro symbol €, consume more than one character space. Using these sparingly can prevent unexpected message segmentation.

Using non-GSM characters changes the encoding of an SMS and reduces the maximum length from 160 to 70 characters due to the increased bit requirement per character.

Hey 😊! Don't forget your appointment on 📅 June 20th at 🕒 3 PM. Reply YES to confirm!

This message includes emojis, which are non-GSM characters. Due to this, the SMS would need to be encoded using UCS-2, significantly reducing the available character limit per segment.

Character limits and concatenation

When non-GSM characters are used, not only is the maximum SMS length reduced from 160 to 70, but also the segmentation behaviour changes:

Single SMS with non-GSM characters can contain up to 70 characters.
For concatenated SMS segments, each can hold only 67 characters when more than one segment is necessary.

This is because additional data (segment headers) are needed to instruct the receiving device on how to reassemble the parts into a coherent message.

How do you know if your message body contains non-GSM characters?

If a non-GSM character is detected within a message body that you have written, the non-GSM character highlighter will highlight the non-GSM characters within.

How to

Setting up a STOP or unsubscribe flow

Method 1

This method outlines an approach for automating SMS unsubscribe requests using CRM integration.

1. Inbound Message Trigger

Configure an inbound message trigger to continuously monitor incoming SMS messages for unsubscribe keywords.

The trigger should be set to recognise various keywords indicating an unsubscribe request. Common keywords include "stop", "unsubscribe", "opt out", "stopall", "cancel", "end", "quit", and similar variations. This ensures the system accurately detects and processes all unsubscribe requests promptly.

2. Check Contact in CRM

Upon receiving the unsubscribe keyword, use the **Make a web request** node to determine if the contact exists in the CRM (e.g., HubSpot). This involves configuring the node to send a POST request to the HubSpot contacts search API.

Here is how the configuration may look like:

In the request body, we send through the phone number via a merge field to be compared against the specified property in the CRM.


  {
  "filterGroups": [
    {
      "filters": [
        {
          "propertyName": "mobile_phone__pre_defined_country_format_",
          "operator": "EQ",
          "value": "{{ inboundSMSTrigger_1.fromNumber }}"
        }
      ]
    }
  ]
}

You can add a payload as such in the Make a web request node under Merge fields → Payload. The total field is part of the response body returned by the CRM search request, indicating the number of contacts matching the specified criteria (e.g., phone number).

  {
    "total": 1,
    "results": [
        {
            "id": "2017",
            "properties": {
                "mobile_phone__pre_defined_country_format_": "+61455841220",
                "email": "example@email.com",
                "firstname": "John",
                "hs_object_id": "2017",
                "use__ticket_activity__waiting_for_reg_forms_": " 180 days",
                "lastname": "Does"
            }
        }
    ]
}

3. Criteria Split

Utilise a criteria split to categorise recipients based on the existence of their contact information in the CRM. This split directs the flow along different paths depending on the search results from the previous step.

Contact Found: If the contact exists in the CRM, the flow proceeds to update their opt-out status. Recipients will follow this path if the total number of matches from the CRM search is greater than or equal to 1.
Contact Not Found: If the contact does not exist in the CRM, the flow sends an outbound SMS informing the recipient. Recipients will follow this path if the total number of matches from the CRM search is equal to 0.
Other: Recipients will follow this path if none of the previous path criteria are met. The flow sends an outbound SMS informing the recipient.

4. Update Contact in CRM

For contacts found in the CRM, use the Make a web request node to update their contact details, setting their status to opt-out. This involves configuring the node to send a PATCH request to the HubSpot contacts API.

In the request body, include the properties that need to be updated. For example:

  {
    "properties": {
        "sms_opt_out__pendula_": "Opted Out",
        "sms_flow_status__pendula_": "SMS Replied-OptOut",
        "sms_last_response__pendula_":"Flow: Re-engage leads\nSMS Reply - OptOut Path\nResponse:{{ inboundSMSTrigger_1.messageBody }}"
    }
}

5. Notify the User

Use the **Outbound SMS** node to inform the customer about their unsubscribe request and provide options to resubscribe if it was done accidentally. To handle resubscription requests, you can set up another flow with an Inbound Message Trigger for the keyword RESUME.

Method 2

While the above method effectively handles unsubscribe requests, it doesn't provide insights into when or after which message a user decided to opt-out. This method addresses this limitation by offering a way to track when users opt-out and during which flow this occurs.

Flow 1

1. Webhook trigger

Use a Webhook Trigger Node to send a data payload. This node will initiate the flow. You may have a payload as such:

{
  "mobile": "0423561439",
  "name": "John Doe"
}

2. Conversation Node

Define multiple paths based on the user's response.

Yes (in this example): Continues with the flow's primary purpose.
STOP: Directs the user to an unsubscribe path. You can use multiple keywords as we did in the first method.

3. Make a Web Request

Set up a Make a Web Request node to handle the unsubscribe action. This node will POST the data to the webhook URL used in Flow 2.

In the request body, you can send user details such as mobile number, name, and flow ID.

The flow ID needs to be manually copied from the URL.
For example, in the URL https://prod3.pendula.app/flows/875ebf90-0332-4b45-8d97-4a30b9f694e0, the flow ID is the part after flows/ and before any other parameters. In this case, the flow ID is 875ebf90-0332-4b45-8d97-4a30b9f694e0.

{
  "mobile": "0400000000",
  "name": "John Doe",
  "flow_id": "875ebf90-0332-4b45-8d97-4a30b9f694e0" 
}

By setting up Flow 1 in this manner, you can direct users based on their responses, track when they decide to opt-out, and handle the unsubscribe process efficiently through a subsequent flow (Flow 2).

Flow 2

Flow 2 is designed to handle the unsubscribe process initiated in Flow 1. It operates similarly to Method 1 but uses a webhook trigger instead of an inbound message trigger to start the process. Configure a Webhook Trigger Node to initiate Flow 2 when it receives a data payload from Flow 1.

You can also paste a sample payload:

{
  "mobile": "0400000000",
  "name": "John Doe",
  "flow_id": "875ebf90-0332-4b45-8d97-4a30b9f694e0" 
}

Working with SMS

Best practices for SMS communications

Understand the legal obligations of using SMS

Start with accurate data management

Understanding SMS Segmentation and Concatenation

Managing non-GSM characters in SMS

Keep your messaging relevant and valuable to your customers

Limit your CTA to one or two options

Keep inbound responses unique

Pendula SMS capabilities

Reply matching

Rules and recipes

Nodes for SMS management

Workflow action nodes

Inbound message trigger

Understanding rules and recipes

Usage scenario

Configuring the trigger

Prioritisation in reply matching

Mergefield explorer

Opt-in and opt-out flows

Unmatched message trigger

Usage scenario

Configuring the trigger

Mergefield Explorer

Conversation node

Usage scenario

Configuring the action

Outbound SMS

Replies

Expected reply

Free reply

Outcomes

Mergefield explorer

Outbound SMS

Usage Scenario

Configuring the action

Settings

Outcomes

Merge fields

Rules and recipes

Key concepts

Rules

Using emojis

To consider: Apple and Android message reactions

Recipes

Using mergefields

Adding multiple rules and recipes

How does reply matching work?

How reply matching works

What is Reply Matching?

Reply matching process

1. Are there any active conversations?

2. Are there any inbound SMS triggers?

3. Mark it as 'unmatched' and redirect to Unmatched message trigger

The priority list visualised

What if I have used the same exact-keyword in the Conversation node across multiple flows?

What if I have overlapping rules/recipes across flows, in the Conversation node, that can match a reply?

What if I have multiple paths or rules in one single Conversation node that match a reply?

Best practices for creating two-way conversations with reply matching

How do I reply to customers dynamically and sensitively in workflow?

How do I best include emojis in my reply matching configuration?

How do I make sure customers don't upgrade or purchase something by accident?

How do I process an opt-out

How do I create custom rules?

How do I ensure unexpected replies are captured in a flow?

Known limitations: Configuring Reply Matching for Apple and Android reactions

How to set up the work-around

Understanding non-GSM characters

What are GSM characters?

What are non-GSM characters?

Character limits and concatenation

How do you know if your message body contains non-GSM characters?

Setting up a STOP or unsubscribe flow

Method 1

1. Inbound Message Trigger

2. Check Contact in CRM

3. Criteria Split

4. Update Contact in CRM

5. Notify the User