Customer tracking and notifications

Tracking and notifications is the customer-facing layer of a running delivery — everything your customer sees and hears while their order is on its way. It has two halves, and they work as one system: a tracking page the customer opens, and notifications that tell them what's happening and carry the link to that page.

• The tracking page is a live, Nash-hosted page — map, ETA, delivery status, and the driver's info Nash surfaces — that a customer opens from a link. It shows only what your organization has turned on, styled with your branding.
• Notifications are the messages — SMS, email, and other channels — that fire as a delivery moves through its stages: created, dispatched, out for delivery, completed, and more. Each one is a trigger: an event or condition you choose, a message you write, and the channel(s) it goes out on.

The two aren't separate features. A notification is often how the customer gets the tracking page in the first place — its message carries the tracking link as a variable, so opening the message is how they reach the page. Set up one without the other and a customer can miss the page entirely, or get updates with nowhere to click through to. Because of that, most operators think about this as one setup, not two.

Operators configure it; customers experience it during a delivery

You do all of this work in the portal, before and independent of any single delivery — deciding what the tracking page shows, writing the messages, choosing which events trigger them, and picking destinations. None of that setup is visible to your customer. What they experience is the finished product, live, while their own delivery is running: a message arrives, they tap the link, the page opens.

Where each part lives

• Tracking page — customize what shows on the page, apply your branding, let customers see tracking before the order even dispatches, and collect feedback once it's delivered.
• Customer notifications — build the triggers that fire messages, choose where each one goes, and manage the channels those messages can reach.

Nash dispatches the delivery; the provider or your own fleet carries it. The tracking page reflects the driver's location and status as Nash surfaces them from whoever's actually making the delivery — it isn't Nash performing the delivery itself.

What you can do

• How tracking and notifications work — the model behind this section: how a trigger fires, how the tracking link ties the two halves together, and how channels and destinations fit in.
• Customize your tracking page — choose what a customer sees on their tracking page.
• Brand your tracking page — apply your logo, color, and footer to the customer-facing page.
• Show tracking before dispatch — let customers open their tracking page before their order is even assigned.
• Collect delivery feedback — gather a rating or comment from the customer after delivery.
• Set up customer notifications — get oriented on triggers, messages, and destinations.
• Create a notification trigger — choose the event, write the message, and pick where it sends.
• Manage notification destinations — configure the channels your notifications can reach.
• Format notification text with Markdown — use variables and formatting in a message body.
• Send customers a tracking link — how the tracking page reaches a customer through a notification.

The customer's experience follows the delivery

What a customer sees and hears is driven by the delivery itself — a notification fires because the delivery's status changed, and the tracking page reflects that same status live. See how deliveries work for the lifecycle behind those changes, and the delivery status reference for what each status means.