MSG user manual

Start with channels

1. Open MSG and complete the channel/onboarding settings for the channels you intend to use.
2. Review the active account and property context. Property access limits the automations and logs available to you.
3. Use Message editor for individual rules, Draft with AI for a proposed rule, Customer journeys for grouped stages, Advanced tools for forms/rulebooks/API, and Logs for execution evidence.
4. Send a controlled test before enabling a broad audience.

Account-level sender, provider credentials and API tokens may require an authorized account context.

Email

1. Open email channel settings and review the configured provider, sender address and sender name.
2. Confirm the sending domain/sender setup shown in onboarding.
3. Create a test email with the intended language and send it to a controlled address.
4. Check delivery logs and recipient spam filtering if it is not received.

SMS and WhatsApp

1. For SMS, configure the Twilio credentials and sending identity required by the channel settings.
2. Check that the guest phone number includes the correct country code.
3. For WhatsApp, complete the Meta/WhatsApp configuration and choose an approved template when the workflow requires one.
4. Map template variables and test delivery before enabling automation.

WhatsApp production availability depends on the provider/account approval and template configuration. A successful template edit is not proof of provider approval.

Slack

1. Configure the intended Slack webhook in messaging settings.
2. Choose the operational channel/recipient behavior and test a message.
3. Verify the destination and any mentions before using the message for staff alerts.

Build the content

1. Open Message editor and create or edit a rule.
2. Choose the channel and sender/recipient settings.
3. For email, set the subject and formatted body; for SMS and Slack, review the text; for WhatsApp, review the selected template and variables.
4. Add language variants and choose the intended fallback behavior.
5. Insert supported tokens from the editor rather than guessing their names.
6. Preview the content for representative reservation data and send a controlled test before enabling.

Maintain an existing rule

1. Locate the rule in the existing automation list and open its details.
2. Review content, trigger, conditions and timing together before saving changes.
3. Disable a rule that should stop sending and confirm its saved state.

Use the token picker

1. Choose a token supported by the current channel and automation context.
2. Preview it with a representative reservation and check required data such as email, phone, assigned unit and language.
3. For Salto, use {{salto.pin}} for a PIN or {{salto.guestUrl}} for a personal door-access page.
4. Use the online check-in or service-booking link token offered by the picker for those configured flows.
5. Review the final rendered message and link before sending.

Some tokens create or resolve reservation-scoped access links. They require the relevant app, permissions and configuration; a copied raw token is not an access link.

Create a reservation or event automation

1. Choose the reservation/event source supported by the editor.
2. Select the included properties and configure the conditions and exclusions offered for that source.
3. Check field paths, operators and values, including how grouped conditions combine.
4. Choose when to send: the offered event delay, reference-date offset or scheduled execution time.
5. Preview the audience/conditions, name the rule and save it in the intended enabled state.

Use a recurring property schedule

1. Choose a recurring trigger, included properties, recurrence and time zone. A weekly recurrence offers a weekday selector, such as Friday.
2. Understand the scope: each occurrence creates one event per eligible property and supplies property context. It does not enumerate the hotel’s in-house reservations or guests.
3. Configure a recipient supported by that property context and test the actual channel and rendered recipient.
4. Use a supported reservation-specific rule when the message requires a guest’s address or reservation tokens. Confirm a suitable guest-audience workflow with support before planning a weekly broadcast to all staying guests.

Recurring rules do not expose the normal reservation condition controls. A weekly schedule alone is not an in-house guest broadcast.

A missing rendered recipient can prevent sending. A property-level run is not proof that any particular guest received a message.

Validate the behavior

1. For a reservation/event rule, use one reservation that should match and one that should not. For recurrence, test the property event and its explicitly configured recipient.
2. Wait for the relevant event or schedule and inspect Logs.
3. If a message is skipped, check scope, conditions, timing, channel and recipient data before duplicating the rule.

Saving a rule does not guarantee that historical events are replayed. Check the preview and trace for the actual trigger.

Plan the journey

1. Open Customer journeys and choose or create a journey.
2. Add the needed stages, such as reservation created, before arrival, check-in day, during stay, checkout day and post-stay.
3. For each stage, set the channel, content, conditions and arrival/departure reference with the intended offset.
4. Check whether other active rules already send the same message to the same audience.
5. Save and test representative reservations, including amended arrival and departure dates.

A journey is a collection of configured stages. Inspect each stage’s conditions and timing when only part of a journey sends.

Check moved or canceled reservations

1. Inspect which created, amended or canceled reservation events the stage actually subscribes to. A before-arrival preset can be created-only; saving it does not establish change-event handling.
2. After a relevant change, check the current reservation, rule conditions, scheduled timing and execution logs. Date changes can reschedule work only when a configured event reaches the rule and its timing is evaluated.
3. A scheduled execution fetches current reservation data, but does not itself recompute its send time. Do not assume that updated message content means the schedule moved.
4. For cancellation, verify a condition that suppresses the send and inspect the actual execution result; there is no universal cancellation suppression guarantee.
5. Already-sent messages cannot be recalled by a date change. Preview and send corrected information when necessary, checking for duplicate sends.

Create and review a draft

1. Open Draft with AI and describe the audience, trigger, conditions, channel, timing and desired message.
2. Review all generated fields, property scope, conditions, tokens and message translations.
3. Adjust the proposal in the editor and save only after it matches the intended workflow.
4. Use the available feedback controls when a draft is incorrect.
5. Review AI settings and usage indicators before enabling optional paid usage.

An AI draft is a proposal. It cannot establish that your provider credentials, guest data or production delivery are working.

Configure the form

1. Open Advanced tools → Form generator.
2. Choose the intended form or preset and configure its questions and required fields.
3. Set the title, introduction and success message in the intended languages, and review the default language.
4. Adjust appearance and preview the guest experience.
5. Save the configuration and use the provided link/token workflow for the intended reservation.

Test guest use

1. Open a generated link for a test reservation.
2. Check language, required fields, submission and the success state.
3. Verify the resulting reservation/profile information in the authorized staff view.
4. If a link is unavailable, check the saved form, link validity, reservation scope and the exact error.

A public form link grants a specific guest workflow. Share it with its intended recipient and avoid reusing one reservation’s link for another.

Work with a rulebook

1. Open Advanced tools → Automation rulebook.
2. Start from the example format shown in the interface and supply the intended automation definitions.
3. Review validation messages and correct unsupported fields or conditions.
4. Inspect each resulting rule, its scope and enabled state before activating it.
5. Use the automation list/details to maintain the imported rules and inspect later executions.

Do not paste provider credentials or customer records into a rulebook. Importing a definition is separate from verifying its operational behavior.

Create and revoke credentials

1. Open MSG in account context, then Advanced tools → MSG API.
2. Enter an integration name and create a token. Copy it immediately and store it in your server-side secret manager.
3. Review active tokens, created/last-used times and prefixes.
4. Revoke a token when the integration is retired or its credential needs replacement.

Call the API

1. Use the endpoint displayed by the running app, ending in /api/msg/api.
2. Send Authorization: Bearer YOUR_TOKEN.
3. Use GET with resource=automations to list automations.
4. Use POST with resource=messages, to, subject and html to send through the configured account sender.
5. Respect the published limits and retry guidance: 120 reads/minute and 10 sends/minute per token, up to 10 active tokens, 10 recipients and 250 kB HTML per send.

{"resource":"messages","to":["guest@example.com"],"subject":"Welcome","html":"<p>Hello</p>"}

Send with the right context

1. Open the intended reservation/booking in MSG or use the messaging action offered in Profiles or Bulk.
2. Confirm reservation ID, property, participant, destination address/phone and preferred language.
3. Choose the channel/template and preview resolved tokens.
4. Send the message once, then inspect the relevant logs.

A selected profile may participate in several reservations. Verify the stay when using reservation-dependent content such as PINs and check-in links.

Investigate a missing message

1. Open Logs and narrow the property, dates, automation and reservation/recipient filters available.
2. Find the trigger/execution trace and inspect matched or skipped conditions and timing.
3. If execution reached delivery, inspect the channel/provider result and rendered recipient.
4. For unresolved tokens, verify the selected reservation and the data or integration required by that token.
5. For a provider rejection, correct the sender, template, credentials or recipient issue indicated by the error.
6. For support, include account/property, automation and reservation IDs, channel, expected send time and trace/error text.

Do not resend blindly when provider delivery is uncertain; check the existing message result first.