How customer notifications work

A customer notification is an automatic message that goes out as a delivery moves through its stages. Every one of them comes from a trigger: a single rule that answers three questions at once — when to fire, what to say, and where to send it. Event, message, destinations. That three-part shape is the whole model, and everything else in this article is detail hanging off it: what each part is, which triggers are actually for your customer versus your own team, and how a message reaches the right person.

One thing to hold onto before the detail: Nash dispatches the delivery, and a provider or your own fleet carries it out. A notification only reports on that delivery — it announces a status Nash observed. Sending a message doesn't make Nash the party performing the drive.

The Notifications workspace

You build all of this in the Notifications workspace, which splits into three tabs, one per part of the model:

• Triggers — the rules themselves. This is where you spend most of your time: each trigger is one event paired with a message and the destinations it goes to.
• Destinations — the contact groups a trigger can send to, each on a channel like email, SMS, WhatsApp, or voice.
• Settings — the SMS sending account for your organization. This tab is available to merchant accounts, and it's where the sender identity behind your customer SMS is chosen.

The tabs map onto the model cleanly: a trigger (Triggers) sends a message to one or more contact groups (Destinations), over channels whose SMS sender is configured once for the whole organization (Settings).

A trigger is event, message, and destinations in one drawer

Open a trigger and you're looking at a single form that holds all three parts at once. You don't set up "when it fires" in one place and "what it says" in another — they're fields of the same drawer:

1. A trigger type — the event or condition that makes the trigger fire. You pick the type first, then configure its settings.
2. A message — toggle Send a message on, and you get a templated body to write. This is the text the customer receives.
3. Destinations — under Send to, you choose the contact groups that receive the message.

Beyond those three, a trigger can do a few more things from the same drawer: flag the delivery so it surfaces for your team's attention, auto-resolve a flag, emit a custom event that other systems can react to, and apply conditional logic so it only fires when extra conditions hold. The common case is a message to the customer, but a trigger is really "a rule that reacts to a delivery event," and messaging is one of the things it can do.

Note

Because the event, the message, and the destinations are one form, a trigger can do less than send a message — it can fire only to flag the delivery, or only to emit a custom event, with no customer-facing message at all. Toggling the message off is a real configuration, not a broken one.

Not every trigger is for your customer

This is the distinction that matters most in the whole workspace, and it's easy to miss: the trigger catalogue is large, and many of the triggers are internal-ops alerts to your own team, not messages to your customer.

The catalogue is organized into categories — delivery, driver, status, order, and refund — so you can find the event you want. Some of those events are things a customer cares about ("your delivery is on its way"); others are things only your operations team cares about ("this delivery has been stuck too long," "a refund was requested"). The trigger mechanism is identical for both. What decides whether a trigger is customer-facing or internal isn't the trigger type — it's who its destinations resolve to. Send to a contact group that resolves to the customer, and it's a customer notification. Send to a group that resolves to a fixed ops address, and the same machinery quietly alerts your team instead.

The canonical customer-facing trigger is Delivery Status Transition, which is the default when you add a trigger. It fires when a delivery reaches a status you choose — created, dispatched, out for delivery, completed — and it's the one you reach for when you want to keep a customer informed as their order moves. When in doubt about which trigger sends the "here's your update" message, it's this one. The full catalogue is in the notification trigger reference, and every firing event is enumerated in the notification events and variables reference.

Messages: merge fields fill in per delivery

A message body is free text written with merge fields — {{token}} placeholders that Nash substitutes with real values at send time, per delivery. You write a body like "Hi {{customer.first_name}}, your delivery is on its way — track it here {{job_tracking_link}}", and at send time each token resolves to the actual name and the actual link for that specific delivery.

The available fields cover the delivery end to end: the customer's name, phone, and email; the pickup and dropoff details; the driver and provider; and ETAs. Two merge fields are worth naming on their own:

• {{job_tracking_link}} resolves to the customer's tracking-page URL. This is how a notification delivers the tracking page — the customer taps the link in the message to open it.
• {{customer_feedback_link}} resolves to the feedback surface on that same tracking page, for gathering a rating or comment after delivery.

Both point at the tracking page, which is a separate object. That coupling is the one crossing worth understanding: a notification is usually how a customer gets their tracking link, even though the link itself opens a page you configure elsewhere. Building the message and choosing its formatting stays here; what the linked page shows is covered on the tracking page. Formatting a body with merge fields and Markdown is walked through in format notification text with Markdown.

Destinations: contact groups decide who receives it

A trigger doesn't send to a raw phone number or email address — it sends to a destination, which is a contact group on a channel. The group is the reusable thing: you build it once, and any trigger can send to it.

A group has two properties that matter:

• A channel — email, SMS, WhatsApp, voice, and more. The channel decides the medium the message goes out on.
• A recipient, resolved by a mention token — inside the group, a token decides who actually receives the message. A customer field (the recipient's own phone or email on the delivery) sends to the customer; a fixed address sends to a specific person or ops inbox every time.

That single mechanism is what lets the same trigger machinery serve both customers and your own team, and it's why "who is this trigger for" is answered by the destination, not the trigger type. Building and managing these groups is covered in manage notification destinations, and the end-to-end setup in set up customer notifications.

Settings: the SMS sending account

The Settings tab, available to merchant accounts, holds one important choice: the SMS sending account for your organization. You can use Nash's shared sending account, or bring your own. This is the org-wide sender identity behind your customer SMS — the "from" your customers see — so it's set once for the whole organization rather than per trigger.

Note

Some channels and sending arrangements — such as automated voice or a dedicated sending number — depend on what's provisioned for your organization. Availability varies; if you need a channel or sender setup you don't see, reach out to Nash.

How notifications relate to the tracking page

It's worth stating the boundary plainly, because the two objects are close enough to blur. Customer notifications are the messages that reach the customer and, through {{job_tracking_link}}, carry them to the tracking page — the live, Nash-hosted page a customer opens to watch the delivery. Notifications are the delivery mechanism for the link; the tracking page is what the link opens.

Build a notification with the tracking-link merge field and you've connected the two: the customer gets a message, taps the link, and lands on the page. Build the page but never send a notification carrying its link, and the page exists but no customer finds it. Each object stands on its own — this one is the messages; the tracking page is the destination those messages point to.

One fact to carry out of all of this: a notification announces a status Nash observed, over the channel you chose, to the recipient your destination resolved to. Nash dispatches the work and a provider or your own fleet carries it — customer notifications only report on it.