The Loop: Chasing Approvals Across Email and Chat

Welcome to The Loop. Every Wednesday we take one real, repetitive workflow that someone does by hand and unwind it into something you can run. This week it's the hunt for a yes: the follow-ups, the second pings, the thread you reopen on Thursday because Tuesday's message got buried under a launch.

Here's the reframe. Chasing feels like relationship work, so it gets treated as relationship work: read the room, judge the tone, decide who needs a gentle nudge and who needs a deadline. Watch yourself do it for a week and something plainer shows up. You always wait two days before the first follow-up. You always send the second one in whichever app that person really answers in. You always escalate on day five, and you always check the thread before you ask again so you don't look like you weren't listening. Those are rules with dates attached. You've never written them down because you've been busy running them. Write them down once and they become a spec. Describing replaces doing.

So let's watch the chasing loop run at full speed, price it honestly, and turn it into something that does the asking while you do the work you were hired for.

The Loop, in Full

You can't automate a loop you haven't watched closely, so here it is start to finish. It's Wednesday, just after nine, at a ninety-person company that makes warehouse software.

Dana runs operations there, which in a company that size means she owns every process nobody else wants. She opens the tab she calls the graveyard: a sheet with nineteen open requests. A vendor contract sent to legal on the fourth. Two new laptop orders waiting on finance. A discount on a renewal that needs the VP. A security questionnaire that needs a sign-off from a person who has been in Lisbon all week. She sorts by date sent and starts down the list. For each one she opens the original email thread to see whether anyone replied, then opens Slack and searches the approver's name plus the vendor's name in case they answered there instead, which two of them did, one with a thumbs up emoji that she has to decide whether to count. Then she writes the nudges. Different tone for legal than for finance. Different app for the VP, who doesn't read email before noon. Two of the people she pings today she also pinged on Monday. It's ten fifteen. Nothing has been approved. She has produced nineteen decisions about how to ask for decisions.

Written out as steps, the by-hand version looks like this:

1. Open the list of requests you've sent and find the ones with no recorded decision.
2. For each one, check every channel it could have been answered in: the email thread, the chat DM, the group channel, the signing tool.
3. Work out how long it has been waiting and whether that crosses the line where you follow up.
4. Group what is left by approver so one person gets one message rather than four.
5. Write and send the nudge in the channel that person reads, then log that you sent it so Friday's pass doesn't repeat it.

Nothing there is hard. That's the tell. Every step is either a date comparison, a search, or a message written from a shape you've used a hundred times. This is exactly the kind of coordination work that expands to fill a role, and it's what it looks like to automate the follow-up work operations managers absorb on behalf of everyone else.

The Manual Tax

The cost of a loop is never the clock alone. It's the minutes, plus the mistakes that show up when a human is the only index of what is outstanding, plus the days of work that sit still while a request waits to be noticed. Add those together and you get the manual tax.

The scale of the underlying problem is well documented. In Asana's Anatomy of Work Global Index, a survey of 9,615 knowledge workers, leaders reported losing 62 percent of the workday to repetitive, mundane tasks while moving between an average of ten apps a day. Read that next to the loop above and the irony lands: the person you're chasing is buried in the same kind of work that produced the chase, in the same ten apps you're searching.

Then there are the two costs hiding underneath the minutes:

• Errors. Not typos. Blind spots. The request that never gets chased at all because it fell off the bottom of the sheet, and the one chased twice because the approval landed in a channel your process doesn't read. Both cost you credibility with the exact people whose goodwill the next request depends on.
• Latency. This is the expensive one. A contract waiting four days for a signature is four days of a deal not closed, a hire not started, a renewal not booked. The work was finished. It's sitting in a queue behind a person who hasn't looked, which is the same reason teams eventually automate the contract steps that stall before signature rather than trying to sign faster.

Nobody quits chasing approvals because it's hard. They quit because being the memory of a process is a full-time job that nobody put in a job description.

Which reframes the goal. You aren't trying to save the ninety minutes, though you'll save them. You're trying to make sure nothing ever waits five days because the only system tracking it was a person with a busy Wednesday.

Unwinding the Loop

Automating starts with description, not code. Describe the loop tightly enough that something else could run it unsupervised and most of the work is done before anyone opens an editor. The mechanics here are almost nothing: read a list, compare some dates, send some messages. The decisions are the whole game, and this loop has two good ones: what counts as an answer, and how hard to push.

Here's the same loop written as a spec. Read the right-hand column and notice how much of it is judgment you've already made and never said out loud:

That table is the automation. Everything after this is choosing how much of it runs without you in the room. If you would rather build the spec as a conversation than stare at an empty table, that's how BYOBot turns a task into a spec, one question at a time.

The Build: One Loop, Three Ways to Run It

One described loop becomes three builds. The only thing that changes between them is how much runs while you're asleep. Start at the top and move down when the top stops being enough.

The Prompt

The prompt build is zero setup: one saved prompt you paste into any AI chat tool along with your open-request list, copied straight out of the sheet. It won't send anything. It will hand you every message you need to send, already batched and already in the right register, which on a Wednesday morning is most of what you wanted.

You are writing today's approval follow-ups from my open-request list.
Today's date is [DATE].

Step 1. Drop any row where Decision is filled in.
Step 2. Drop any row sent less than 48 hours ago.
Step 3. Drop any row already nudged today.
Step 4. Group what is left by Approver.

For each approver, write ONE message containing all their open items:
- 1 nudge so far  -> friendly reminder, no deadline language
- 2 nudges so far -> name the date it is needed by and what slips
- 3+ nudges       -> same, and note you are copying [BACKUP APPROVER]

Rules:
- One message per person. Never one per request.
- Lead with the ask, not with an apology for asking.
- List items as: what it is | who asked | days waiting.
- Under 90 words. No emoji. No em dashes. American spelling.
- End with the single fastest way for them to answer.

Return a table: Approver | Channel | Message | Items covered.

OPEN REQUESTS:
[paste your sheet: Request | Requester | Approver | Sent | Channel | Last nudge | Decision]

That runs the same in ChatGPT, Claude, or Gemini, because a prompt was never locked to one vendor. Run it for two weeks and you'll notice the model is doing something you could describe exactly: the same filters, the same grouping, the same three escalation levels. Noticing that is the moment you're ready to automate the approval requests you send every week rather than reformat them by hand each morning.

The Script

Now the honest part, and this week it runs against the grain of what people expect from an AI article. This build barely needs AI at runtime. Comparing a sent date to today is arithmetic. Grouping rows by approver is a loop. Writing a nudge from three templates is string formatting. Put a language model in the middle of that and you've added latency, cost, and a small chance of invention to a job that plain code does perfectly every single time.

So the script is code, end to end, and it reads its state from wherever your requests already live: a sheet through the Google Sheets API, a base in Airtable, a table in your own database. To check for answers it searches the thread through the Gmail API and the channel history in Slack, then sends the batched nudge with chat.postMessage, or with Microsoft Graph if your company lives in Teams instead.

// pseudo-shape of the script BYOBot generates for you
const rows  = await tracker.read(OPEN_REQUESTS);      // plain fetch
const today = startOfDay(new Date());

const due = [];
for (const r of rows) {
  if (r.decision) continue;                           // already answered
  if (daysBetween(r.sent, today) < 2) continue;       // too early
  if (sameDay(r.lastNudge, today)) continue;          // one a day, max

  const answered = await findReply(r);                // email + chat
  if (answered) { await tracker.close(r, answered); continue; }

  due.push(r);
}

for (const [approver, items] of groupBy(due, 'approver')) {
  const level = Math.min(maxNudges(items) + 1, 3);    // 1, 2, or 3
  await send(approver, TEMPLATE[level](items));       // no model call
  await tracker.stamp(items, today);                  // so tomorrow knows
}

There's exactly one place a model earns its seat, and it deserves a precise name: findReply. Deciding whether "yeah that looks fine to me" in a thread counts as an approval is a language judgment, not a string match, and that one call is worth making. Everything around it stays code. You don't start from an empty file either. BYOBot writes the full version: the file to create, the tokens to paste, the templates wired to your own escalation rules, and the same wiring that lets you automate the Slack follow-ups you send by hand every morning.

The Schedule

The schedule is the smallest leap left. Chasing is a job with a clock built into it, so it belongs on a timer more than almost any loop we've covered. Run it at nine every weekday, before the day gets loud. A cron job costs nothing, and a GitHub Actions scheduled workflow costs nothing either. Add one more line while you're there: a Friday summary to yourself listing everything still open and how long it has waited, which is the same habit that makes it worth learning to automate the recurring email you send on a rhythm.

Here's how the three stack up, so you can pick your stopping point:

Steal This Build

Here's the whole loop as a spec you can hand to BYOBot or build yourself this afternoon. Copy it, swap in your own waiting period and your own escalation ladder, and it's your build. If you want the wider version that covers routing and recording the decision as well as chasing it, our guide on automating approval workflows with AI picks up where this leaves off.

• Trigger: a weekday morning pass over every request with no recorded decision.
• Check: search every channel the request could have been answered in before assuming silence.
• Age: skip anything under two days old and anything already nudged today.
• Group: one message per approver containing every item they owe, never one per request.
• Escalate: reminder, then deadline, then copy the backup, and stamp the row so tomorrow knows.

Approvals are the example, but look at the shape underneath: you asked somebody for something, the answer hasn't arrived, and you're the only system that remembers. Timesheets before payroll closes. Interview feedback from a panel of five. Overdue invoices from customers who like you. Documents a client owes you before the project can start. It's the same loop with different nouns every time, which is why it pays to learn once and then automate the chasing finance teams do every close with the build you already have.

Frequently Asked Questions

• What is approval chasing? +
  Approval chasing is the follow-up work that happens after you send a request and before anyone decides on it. You track which requests are still open, check whether the approver answered somewhere you haven't looked yet, work out who's overdue, and send another message. None of that is the decision itself. It's the bookkeeping around the decision, and it's the part that quietly becomes a job, whether the thing you're waiting on is a budget line or a signature in a tool like a signing workflow you run every week.
• Does chasing approvals need AI, or can a plain script do it? +
  A plain script does almost all of it. Comparing a date to today is arithmetic. Grouping open requests by approver is a loop. Writing a nudge from a template is string formatting. The one genuinely fuzzy part is reading a free-text reply and deciding whether a casual line like "yeah that's fine" counts as a recorded approval. That single judgment call is where a model earns a seat, and everywhere else a template beats it on cost, speed, and predictability.
• How do I nudge people without annoying them? +
  Batch and time it. One message per person per day containing everything they owe you beats five separate pings scattered through the afternoon. Say what you need, name the deadline and what happens if it passes, and include a one-click way to answer. Then dedupe hard, because the fastest way to lose an approver is to ask twice for something they already approved in a channel your process never checked. Writing those rules down before you build anything is the step most people skip, and our walkthrough of how to write a workflow spec covers how to do it properly.
• What if approvals are scattered across email, Slack, and a signing tool? +
  That's the normal case, and it's exactly why chasing is expensive. The fix isn't forcing everyone into one app, because that fight never ends. It's one tracker that holds the state of every request no matter where it was sent, and a job that reads each source, updates the tracker, and sends from there. The tracker becomes the single answer to what is still open, and the channels go back to being channels. That single source of state is the first thing to build when you automate an approval process that lives in three places.