Zippy in Slack

What this page is for

Zippy also lives in Slack. It posts coverage and custody alerts to the right channels, answers questions when you mention or DM it, and turns a plain Slack message into a bulletin on the Command Center's Billboard. This page covers the Slack side only - for what Zippy can do overall, see What Zippy Can Do.

What Zippy posts to Slack

Alert type	Channel or DM	What it says	What you can do from Slack
Time-off / coverage request	Org's coverage channel	A driver's time-off request, with a reference number	React ✅ (or ✔️) to approve, ❌ (or ❎) to deny
Chain-of-custody alert	Org's custody channel	A specimen in a driver's hand got dropped, mismatched, or changed drivers mid-custody, with the order link	Read-only - click the order link
Playbook alert	Org's playbook channel (the Zippy channel until one is set)	A Playbook play with a Send a message → Slack channel action fired: the play's name, its message, and the order link	Read-only - click the order link
Dark-driver alert	Org's custody channel	A driver with open work has sent no GPS for over an hour during the day	Read-only
#Billboard confirmation	Same channel, as a 📰 reaction	Confirms your `#Billboard` post was published	Edit or delete the message to update or remove the bulletin

Blurry-GPS answers (technical channel). Zippy does not send the blurry-GPS phone steps on its own: a dispatcher picks who gets them in Command Center (Geofence > Blurry GPS). When a driver answers them, Zippy posts one line in the org's technical channel (for example #technical) saying whether they acknowledged, declined or dismissed the steps, and when they were sent. No line means the driver has not answered yet.
Coverage, custody and playbook channels are configured per organization; if none is set up, Zippy fails closed and logs it instead of posting into the wrong company's Slack.

Talking to Zippy in Slack

Address Zippy two ways: @mention it in any channel it's in, or DM it directly. Either way it's the same Zippy, running the same tools with the same read/write permissions tied to your StatVault role - not a lighter or looser version.
Your Slack account has to be linked to a StatVault user for Zippy to know who you are. If it isn't linked, Zippy still answers general lookups, but anything that changes data - assigning a driver, filing time off, editing a rule - is refused until an admin links your Slack ID to your account at /admin/users. Send Zippy whoami any time to see how it sees you: your linked StatVault user (or "no match"), your role, and whether writes are allowed.
Uploading a schedule photo or document. Send Zippy an image or PDF along with words like "schedule," "shift," "coverage," or "assign," and it reads the document, pulls out every assignment and callout it finds, and files the assignments as standing preferences (driver X is the preferred driver, driver Y has a limitation) and every callout as an out row on the coverage calendar for each named day — the same row a dispatcher adds by hand, so the calendar, Fleet Pressure and dispatch suggestions all see it at once. If the schedule names specific dates, preferences expire at the end of that day; a schedule marked "going forward" (or with no dates at all) is filed as permanent. Zippy replies with a checklist of what it created (out days per driver, which preferences are temporary versus permanent) - check that list against the document.
Sending a picture to drivers. Post the picture in a thread with Zippy (or reply in that thread), ask who should get it - for example "who delivered for account 123401 in the last 60 days" - then say "send them this pic, require ack." Zippy previews the message with the driver list and the photo count; react :white_check_mark: to send one private DM per driver with the picture attached. Photos only (jpg, png, webp, heic, gif, max 10MB) - a PDF can be read but not forwarded. Zippy only sees pictures posted in that thread, and a driver's acknowledgement posts back to the thread as usual. The Zippy page does the same with its camera button (see the Zippy page guide).
To check what Zippy created from a document or a conversation, ask it directly (for example, "what do we know about driver 301?") or look it up on Ask Zippy, where the same knowledge is queryable.

The Billboard channel

Post a message anywhere in a channel Zippy is in starting with #Billboard and it becomes a bulletin on the Command Center's Watches tab - no waiting on Zippy to notice it. Zippy confirms with a single 📰 reaction on your message; it never replies with a text message for this.
Add a horizon word to control how long the bulletin stays up: today (the default), tomorrow, week, or an explicit date. Flag severity with ! (warning) or !! (critical) at the start; with neither, it posts as plain info. Mentioning INC-1042 links the bulletin to that incident.
Editing your Slack message updates the same bulletin in place - title, body, horizon, and incident link are all re-read from the new text. Deleting your Slack message closes the bulletin's live window (the record stays, for history).
Posting to the Billboard is limited to dispatcher-role users and up whose Slack account is linked to a StatVault user in the same organization as the Slack workspace; anyone else's #Billboard message is silently dropped, with no confirmation reaction and no bulletin.

Common tasks

Approve a time-off request from Slack. Find the coverage-request post and react with ✅ (or the check-mark emoji). Zippy replies in-thread confirming who approved it and that the driver was notified; the driver's out days land on the Coverage Calendar. On a CXT-connected org with the coverage bridge set to push ("both"), the ✅ is the approval and also creates the Need-to-Cover (NTC) ticket in CXT, through the same checked push as the Coverage Calendar; the reply names the new CXT ticket, or says why it wasn't pushed (then open that day's out row on the Coverage Calendar and click Push to CXT). With the bridge on "inbound", StatVault never creates CXT tickets, and the reply tells you to enter the NTC in CXT yourself.
Deny a time-off request, with a reason. React with ❌ instead. Zippy files the denial and notifies the driver; there's no separate reason field on the reaction itself. If someone already reviewed the same request in StatVault or Slack, the second reviewer sees "Already reviewed" and no second decision or notification is sent. If another review is still in progress, Zippy asks you to try again.
Ask Zippy who is on call. @mention it or DM it: "who's on call this weekend?"
Post a bulletin for tomorrow. Type #Billboard tomorrow: <your headline> in a channel Zippy is in.
Find an old Slack thread. Ask Zippy "any Slack mentions of the north campus dock?" - it searches archived Slack history and can hydrate live results when you give it a channel.

Things that confuse people

Approving or denying in Slack is real, not a preview - it records the driver's out days on the Coverage Calendar (on approve) and notifies the driver immediately, same as approving from the Coverage Calendar. It never writes CXT: on a CXT-connected org a dispatcher pushes the Need-to-Cover ticket from the calendar.
When Zippy's Slack process restarts it re-reads the last 14 days of CXT coverage tickets for every CXT-connected organisation, so the calendar catches up on anything that changed while it was down.
Zippy in Slack answers using your organization's own timezone, not UTC - "today" and "tomorrow" are relative to that.
Reactions from someone who isn't a recognized dispatcher (unlinked account, or a role below dispatcher) are ignored - Zippy replies in-thread that a dispatcher needs to react instead.
A #Billboard post with no horizon word doesn't stay up forever - it defaults to expiring at the end of that day, org-local.
Only a dispatcher-and-up user whose Slack identity is linked can post to the Billboard - anyone else gets silently dropped, no error in Slack.

Ask Zippy
What Zippy Can Do
Coverage Calendar
Command Center
Emails & Notifications - the other channels: email, driver push, SMS, in-browser