Customer notifications

Customer notifications are the automatic messages — SMS, email, WhatsApp, voice, and more — that go out as a delivery moves through its stages. You build a trigger for the event that should fire a message, write the message with merge fields that fill in per delivery, and choose the destinations that receive it. Nash then sends the right message to the right person at the right moment, with no one watching the order.

You do all of this in the Notifications workspace, which has three tabs:

• Triggers — the rules that fire messages. Each trigger pairs an event with a message and the destinations it goes to.
• Destinations — the contact groups a trigger can send to, on channels like email, SMS, WhatsApp, and voice.
• Settings — the SMS sending account for your organization. This tab is available to merchant accounts.

A trigger is one event, one message, one set of destinations

Everything here hangs off the trigger. When you add one, you pick a trigger type, configure its settings, toggle Send a message and write the templated body, then choose Send to — the destination groups that receive it. A trigger can also flag the delivery for attention, auto-resolve, emit a custom event, or apply conditional logic, but the common shape is simple: an event happens, a message goes out, and specific destinations receive it.

The trigger catalogue is large and organized into categories — delivery, driver, status, order, and refund. One distinction matters more than any other here: many triggers are internal-ops alerts to your own team, not customer messages. The canonical customer-facing trigger is Delivery Status Transition, which is the default when you add a trigger. Reach for it when you want to tell a customer that their delivery was picked up, is out for delivery, or has arrived.

Messages and destinations

A message is written with merge fields — the customer's name, phone, and email, the pickup and dropoff details, the driver and provider, ETAs, and more. Two merge fields are worth calling out: {{job_tracking_link}} and {{customer_feedback_link}}, which resolve to the customer's tracking page.

Destinations are contact groups on a channel — email, SMS, WhatsApp, voice, and others. A group holds contacts, and a mention token inside it decides who actually receives the message: a customer field sends to the customer, while a fixed address sends to an ops team. That's the same mechanism whether a message is meant for your customer or for your own team.

Notifications and the tracking page

A notification is usually how a customer gets their tracking link in the first place. When a message embeds {{job_tracking_link}}, opening the message is how the customer reaches the tracking page. So "text my customer when it's out for delivery, with a tracking link" is a Delivery Status Transition trigger built here — even though the link itself points at the tracking page, which is a separate object. Notifications carry the link; the tracking page is what the link opens.

Nash dispatches the delivery, and a provider or your own fleet carries it. A notification only announces what Nash observed about that delivery — it doesn't make Nash the party performing the drive.

What you can do

• How customer notifications work — the model behind this workspace: how a trigger fires, why most triggers are internal alerts, and how messages and destinations fit together.
• Set up customer notifications — get oriented on triggers, messages, and destinations.
• Create a notification trigger — pick the event, write the message, and choose where it sends.
• Manage notification destinations — build the contact groups your notifications reach.
• Send customers a tracking link — how the tracking page reaches a customer through a notification.
• Format notification text with Markdown — use merge fields and formatting in a message body.
• Notification trigger reference — the full trigger catalogue and what each type does.
• Notification events and variables reference — every firing event and every merge field available in a message.