A droid that runs the overnight tracking desk on a schedule: every two hours it checks in, writes the update back to your apps, escalates only what’s off-track — and remembers every carrier so the next round picks up where the last left off.
24/7
the desk is covered — including the hours no one's on shift
~60 / night
driver check-ins handled without anyone lifting a finger
10+ caught
off-track loads flagged early — before the dock, not after
Does
Chases overnight load statuses & check-ins
Where
Logistics brokerage, ~40-person desk
Reaches people on
SMS, email, Slack
Works inside
Airtable, Gmail, Google Calendar
Runs
Every 2h · 20:00–06:00
The situation
The job nobody wants.
Someone always has to keep poking people for updates and copying the answers into a system. Carriers needed chasing for an ETA, shippers needed telling, and the tracking board only stayed current while a human sat there refreshing it.
After hours it simply stopped. The desk started each day rebuilding the board from voicemails and texts — and the off-track loads, the ones worth catching early, only surfaced when they were already late. Staffing an overnight just to re-type statuses was never going to pencil out.
Rather than staff an overnight, the team simply handed the job over. The droid set itself up to wake every couple of hours through the night, do the rounds, and pull in a person only when something was genuinely off-track — so the work kept happening with no one watching it.
TASK#182Overnight load trackingscheduled
schedule
First run 20:00, local to the lane
repeat
Every 2 hours · until 06:00
scope
Every open load on the board
runs as
A contained droid action per fire — instance 0, 1, 2…
memory
Per-carrier rolling summary, carried run to run
Created once, in plain language — “every two hours overnight, check each open load and update the board.” The droid turned that into a standing task: no cron expression, no glue code, no extra service to babysit.
Every couple of hours it wakes up and walks the same loop:
01Task firesEvery 2h, overnight
02Droid wakesJust for this task
03Reads loads + memoryOpen loads + each carrier's history
04Texts driversSMS check-in
05Updates the boardAirtable + shipper email
06On track?On track → remember it · Off-track → escalate to Slack
07Arms next runSchedules the next instance
…then the next run picks it up, two hours later.
Ongoing handling
How it ran, night after night.
Here’s the night as it actually unfolded — run by run, down to how it reached for each app. Only the off-track loads ever made it to a human.
20:00run #1
First round of the night — every open load checked and the board brought current.
SMSTexted all 12 drivers for a status; 11 replied.
AirtableWrote 11 fresh ETAs to the board; flagged the 1 non-reply to retry next run.
22:00run #2escalated
Caught the one exception of the night — a dock delay — and handled it end to end.
SMSChecked the Dallas driver — got a 90-minute dock delay.
Google CalendarCross-checked the 10:00 delivery window; the new ETA misses it.
AirtableUpdated the load to “delayed”, ETA 11:10, marked at-risk.
GmailEmailed the shipper the revised ETA.
SlackFlagged the exception in #ops-night for the desk.
00:00run #3
All rolling — but two delivery windows had shifted, so it kept the shippers in sync.
SMSRe-checked all 12 loads — all confirmed rolling.
Google CalendarSpotted two delivery windows had moved.
AirtableRefreshed those two ETAs on the board.
GmailNotified both shippers of the change.
02:00run #4
Quiet round — one load delivered and closed out, nothing else to do.
SMSChecked the 11 still-active loads.
AirtableClosed out the one delivered load on the board.
04:00run #5
Last full round before dawn — everything on track, no changes needed.
SMSChecked the remaining 10 loads — all on track.
AirtableBoard already current; nothing to update.
06:00window closes
Recurring window ends. Night summary posted to #ops-night — every load tracked, one exception caught early, board clean before the day shift logged in.
Watch a run
One run, end to end.
Run #2, replayed the way the droid handled it — the check-in, the apps it touched, the cross-check, and the call to pull in a human.
Run #2 · 22:00 · one load, start to finish
Scheduled task #182 fired · run #2 of the night
AirtablePulled the 12 open loads from the board to work through.
Google CalendarChecked the delivery window for each — so it knows what “on time” means.
Working the Dallas load — texting the driver
DroidHi! Quick check on the Dallas load — are you loaded and rolling?
DriverYeah but I'm stuck at the dock, looking at another 90 minutes.
DroidThanks for the heads up — sorry about the wait. That pushes your ETA to ~11:10. I'll let the shipper know and flag it to the desk.
Google CalendarCross-checked the 10:00 delivery window — 11:10 misses it, so this load is now at risk.
AirtableUpdated load #4821: status “delayed at dock”, new ETA 11:10, flagged at-risk.
GmailEmailed the shipper the revised 11:10 ETA before they had to ask.
SlackPosted the exception to #ops-night with the load, the delay, and the new ETA.
Run #2 logged · 12 checked · 1 escalated · next run armed for 00:00
Why it’s different
Not your average AI agent.
A chatbot answers when you open it. A droid owns the job — on a schedule, across your apps, with a memory that builds. Here’s what sets it apart.
It works on its own clock
Most AI agents wait to be opened and asked. This one runs on a schedule — it wakes itself up, does the rounds, and only comes to you when something needs a decision.
It acts — it doesn’t just answer
No drafts handed back for you to go and send. It takes the actions itself — texting drivers, updating the board, emailing shippers, escalating exceptions — right across the tools you already use.
It remembers
Context sticks. Every carrier, lane, and quirk carries from one run to the next, so it never starts a conversation cold or asks the same question twice.
We didn't automate a chatbot — we handed off a standing job. It wakes itself up every couple of hours, does the rounds, and only taps us when something's actually wrong. By the time the desk logs in, the board's already clean.
Dana R.VP Operations, logistics brokerage
An illustrative workflow based on real product mechanics. Tool names and cadence reflect how a droid actually schedules tasks and calls connected apps; operational figures are directional.
Try it with your droid
Run this workflow yourself.
Copy the brief below and paste it to your droid. It’ll walk you through the prerequisites, connect what it needs, and stand the workflow up with you.
Workflow brief
I run the overnight tracking desk at a freight brokerage. Every night someone has to chase carriers for status updates and copy the answers into our load board; after hours it stops, so mornings start by rebuilding the board from voicemails — and slipping loads only surface once they're already late.
Own the overnight status-chase. Apps/channels: Airtable (load board — open loads, statuses, ETAs), Google Calendar (delivery windows), Gmail (shipper updates), SMS (texting drivers), Slack #ops-night (exceptions).
Schedule a recurring task every 2 hours, 20:00–06:00. Each run:
1. Pull the open loads from Airtable and read each delivery window.
2. Text each driver for a status + ETA, and read the reply.
3. Write the status and updated ETA back to Airtable.
4. If an ETA misses its window, mark the load at-risk, email the shipper the new ETA, and post it to #ops-night.
5. Keep on-track loads current and move on.
Carry context between runs (how each carrier prefers to be reached, their usual patterns) so each round picks up where the last left off. Only bring me in for off-track loads.
What would a droid take off your desk?
Tell us the job that never gets done before close. We'll wire up a droid on a call and you can watch it work.
