Skip to main content

​
Staffing shift coverage and candidate pipeline: an end-to-end walkthrough

This walkthrough takes a staffing and recruiting agency from the first consent decision to a live, monitored shift-coverage and candidate-pipeline setup. It composes pieces that already ship: RCS rich cards, fallback chains, message scheduling, best-time-to-dial, missed-call SMS callback, two-way SMS, WhatsApp, email attachments, and voice callbacks. The examples below use one fictional agency, Harbor Point Staffing (HPS), 3,400 active candidates and roughly 210 open shifts per week across healthcare and light-industrial accounts. Every control on this page is tenant-owned. Your organization decides which pipeline stages carry which consent basis, which shift alerts count as urgent, which quiet hours apply to non-urgent recruiting, and how a no-show escalates. Orbit provides the channels and the controls; the posture decisions are yours. Write the consent model down first, because the stage decides the basis:
  1. Applied and screening. The candidate opted in on a job board or careers page for updates about this search. Interview reminders and scheduling replies belong here; shift alerts do not.
  2. Placed and rostering. The candidate accepted an assignment and joined your roster. Shift-coverage alerts, shift confirmations, and schedule changes belong here, on the consent the worker gave at placement.
  3. Alumni and re-engagement. Past candidates and workers you re-engage for new searches. This stage respects quiet hours, frequency caps, and every promotional gate in send gates.
Record the per-stage basis in your consent and suppression model, and set the per-class windows in quiet-hours configuration. Two decisions deserve explicit sign-off before the first send:
  • Where a shift alert becomes urgent. An open shift starting in four hours is urgent; a weekend re-engagement blast is not. Write the rule down (“an unfilled shift inside six hours of its start is urgent; everything else respects quiet hours”) so the exemption is never decided at send time.
  • One suppression list across pipeline and roster. A candidate who replies STOP during a shift blast must not keep receiving interview reminders from the pipeline stream. Keep a single candidate suppression list that both streams honor, configured with opt-out lists and the duplicate-send guard in message suppression. If pipeline and roster traffic must use separate senders, attach the same opt-out list to both so one STOP ends both streams.
Then build the candidate record the stages act on: phone in E.164, a pipeline_stage field, the role or trade, and a channel-preference field when you honor one. Create them as custom fields if your import does not carry them, and build one segment per stage so a shift blast addresses the roster rather than the whole book (CDP segments for attribute-driven groups, static contact lists for rosters you maintain by hand).

​
2. Interview reminders as RCS cards with confirm and reschedule

For candidates on RCS-capable devices, replace the one-line “reminder tomorrow at 10” SMS with a card that carries the interview:
  • Interview reminder card. Role, client or site, date and time, address, and the recruiter’s direct line, with suggested actions: Confirm interview deep-links into your scheduling calendar, Reschedule opens the same calendar’s rescheduling URL, and Get directions opens the map link. The card is both the reminder and the interface, and a tap on Confirm writes back to your ATS the same way a keyword reply does.
Compose the card in the RCS rich card builder: pick the bot, add the media and suggestion chips, validate against carrier limits, and save it to the template library so every recruiter sends the same card. Candidates whose device or carrier does not support RCS get the SMS reminder instead, carrying the same confirm and reschedule links as plain URLs. Decide that fallback in fallback chains rather than maintaining a second audience list by hand: the RCS hop sends first, and the SMS hop fires only when the card cannot be delivered. Send the reminder at the right moment with message scheduling: for a Monday 10 AM interview, schedule the card for the previous business day at 4 PM and a short SMS nudge 90 minutes before the slot, each with its own scheduled_at. Edit or cancel either send from the same surface while it is still parked, so a rescheduled interview never produces a stale reminder.

​
3. Shift-coverage alerts: the urgent lane, timing, and missed-alert escalation

An open shift is a countdown, so the coverage lane gets different timing from the pipeline lane:
  • The urgent lane. Shift alerts for shifts inside your signed-off urgent window are exempt from your quiet hours by your configuration, and should be the only recruiting class that is. Declare the class and its exemption in send gates next to the rule you wrote in section 1.
  • Timing the non-urgent lane. For coverage outreach that is not urgent, enroll the roster in best-time-to-dial so each worker’s first contact lands in the window they are most likely to answer, and run the send-time experiments in the smart send timing playbook before you trust a default hour. Alerts that must wait for a window opening go out with message scheduling.
  • Missed-alert escalation. When the coverage call rings out or the worker never opens the alert, the missed-call SMS callback recipe texts them back automatically: the shift summary, the pay range, and the claim link, threaded so the reply lands in the recruiter’s conversation instead of a void. Validate the fallback edge in the simulator before you publish it, and keep the reply threading into your inbox.
Keep the alert copy to one segment where you can: shift, site, start time, pay range, claim link. A worker deciding in the break between two jobs reads one screen.

​
4. Two-way candidate replies on SMS and WhatsApp

A reminder without a reply path makes the recruiter the callback center. Run both conversations where the candidate already is:
  • SMS. Confirm, reschedule, and stop keywords plus free-form replies. The two-way SMS conversation guide covers the threading model, and keyword auto-reply rules with the keyword rules recipes give you the confirm and reschedule acknowledgements without a developer.
  • WhatsApp. Connect your number per WhatsApp getting started: the first message of a session goes out on an approved template, and once the candidate replies the conversation continues free-form. Document requests and offer questions fit here well, on the same number as the rest of the candidate conversation so the recruiter answering sees the reminders that prompted the reply.
Both channels land in the same Inbox: routing rules put candidate replies on the recruiter queue, macros carry your reschedule offers, and the first-response SLA holds the team to answering a candidate the same day. A reply on WhatsApp and a reply on SMS open the same conversation record, so two channels never produce two candidates.

​
5. Onboarding documents over email

The accepted candidate moves to documents, and email carries the ones that need a file, not a message:
  • Offer letters and onboarding packets. Attach the offer letter, the tax and policy forms, and the handbook as files rather than portal links alone (email attachments); check the size limits and the MIME allowlist before you design the packet around them.
  • Class split. Keep onboarding documents in the transactional class so a candidate’s marketing unsubscribe never stops the offer letter. The email lifecycle guide walks the class split, the suppression behavior per class, and the delivery record to keep as your evidence of delivery.
One suppression list still covers the candidate across email, SMS, WhatsApp, and voice: a STOP on SMS is honored on email too, except for the classes your consent model documents as outside it.

​
6. No-show escalation by voice callback

When a candidate misses the interview or a placed worker misses a shift, the escalations belong in a queue, not in a recruiter’s memory:
  • The callback queue. Request a callback from the candidate record and work it from the voice callback console: filter and claim the queue, complete or cancel each callback so the console stays honest, and tag the outcome (rescheduled, withdrew, wrong number) so the pipeline stage updates with the call.
  • The first dial. If your workspace is new to outbound voice, make your first outbound PSTN call walks the number, gating, pacing, and the Calls console as the verification loop before the callback queue goes live.
The federal 8 AM to 9 PM recipient-local dialing window applies to the voice leg and no workspace setting relaxes it, for any message class; a no-show is not an exception. Schedule callbacks inside the window, and let the SMS and WhatsApp legs carry the urgent reach outside it.

​
7. Monitor, roll out, troubleshoot

After go-live, run three reads each week:
  • Delivery log. Filter the delivery log by the campaign value you set in metadata and by lane. Per-hop receipts show which candidates got the RCS card and which fell to SMS, and which shift alerts escalated to the missed-call text.
  • Alerts. Set the insights alerts that matter for a staffing desk: delivery-failure rate above your baseline, inbound confirm-keyword volume as the fill-rate signal, and voice answer rate below the norm for a callback queue of that size.
  • Cost and cadence. Read spend per lane, and watch the re-engagement class against its frequency caps. After each hiring surge, deliver the summary (reached counts per channel against segment size, confirm rates, no-show rate) as a scheduled report so the review exists before anyone asks for it.

​
Rollout checklist

  1. Consent basis written down per pipeline stage; the urgent shift-alert rule signed off.
  2. One candidate suppression list confirmed across pipeline and roster streams, attached to every sender.
  3. Candidate record carries phone in E.164 and pipeline_stage; one segment built per stage with suppressed counts known.
  4. Interview reminder card built in the RCS builder with Confirm and Reschedule actions; SMS fallback decided in fallback chains.
  5. Reminder and nudge scheduled with scheduled_at and tested against a volunteer list.
  6. Shift-alert urgent lane live with missed-call SMS callback validated in the simulator.
  7. SMS keywords and WhatsApp template approved; both routing into the recruiter inbox queue with macros and an SLA.
  8. Onboarding packet split into the transactional email class; attachment delivery verified.
  9. Callback queue rehearsed, including the no-show tag set and the federal dialing window.
  10. Delivery-log filter, insights alerts, and the post-surge scheduled report configured.

​
Troubleshooting

  • STOP replies after a shift blast. A STOP writes to the suppression list of the sender that sent. If pipeline and roster share the sender, one STOP correctly ends both streams. If they use separate senders and a candidate keeps getting the other stream, attach the same opt-out list to both senders.
  • Interview cards falling to SMS more than expected. Check the fallback-chain order and the RCS reach for your candidate demographics before editing the card; the fallback working is the chain doing its job, not a defect.
  • A scheduled reminder never left the scheduled state. Check the scheduled_at format and whether you passed browser-local time where the API expects UTC, per message scheduling.
  • TCPA_FEDERAL_DIALING_WINDOW_BLOCKED on a no-show callback. A schedule fact, not a configuration error: the federal window does not relax for no-shows. Move the dial inside the window and let SMS carry the same-day reach.
  • WhatsApp template rejected. The template category has to match the conversation you open; a shift alert reads as utility, not marketing. Resubmit with the matching category and keep the free-form replies for after the candidate answers.

​
See also