KAIZEN Book a call
Open main menu
Book a call

How we run Kaizen

How to automate follow-up when deadlines slip

Deadlines usually slip quietly, and simple reminders do not help: they nag people about finished work and copy managers on everything. Useful follow-up needs to know where each date came from, whether the owner agreed to it, and what has changed since.

By Ashish Tonse 7 min read

Most missed deadlines give no warning. The owner may have known the date was unrealistic, but nobody asked, and the first sign of trouble is that the date has passed. By then, the manager can no longer change the scope or clear the blocker.

Simple automated reminders do not fix this, and often make it worse. They remind people about work that is already done. They treat a date from a contract the same as an internal target. They copy managers on every message, so the one miss that matters gets lost among the rest.

Sending a reminder on a date is easy to automate. Useful follow-up is harder. The system has to know where the date came from, whether the owner agreed to it, what has changed since the reminder was set, and which problems still need a person to decide.

An agent that keeps sending messages until someone answers cannot do this. What works is a record of the work, a short list of written rules, and an agent that applies those rules to the current state of the work.

The agent sends the follow-up. People still make the decisions.

Record where each date came from

Two tasks can both be due on Friday and matter in very different ways.

One date may come from a contract, a client request, a filing requirement or the end of a sprint. Another may be an internal planning target. Each organization decides for itself which kinds of date are fixed and which can move.

Store that with the date. Do not ask the agent to guess it from the task title, the tone of an email or the number of reminders already sent.

A useful record of the work answers four questions:

  • Who owns the work?
  • When is it due?
  • Where did that date come from?
  • What happens if the date is missed?

Without those answers, the model has to make up the rules one task at a time.

Two tasks due on Friday, and what the record adds Two work records side by side. Both answer the same four questions. Task A and Task B each have a named owner and are both due on Friday. They differ on where the date came from: Task A's date came from a client request, and Task B's date is an internal planning target. That source decides what happens if the date is missed. In this example rule, a missed client date goes to a manager straight away, and a missed internal target gets one direct reminder to the owner. Each team writes its own rule. WORK RECORD Task A WORK RECORD Task B WHO OWNS IT A named owner WHO OWNS IT A named owner WHEN IT IS DUE Friday WHEN IT IS DUE Friday DATE CAME FROM A client request DATE CAME FROM An internal target IF IT IS MISSED A manager hears at once IF IT IS MISSED One direct reminder SAME OWNER, SAME DAY. THE SOURCE OF THE DATE DECIDES WHAT A MISS MEANS. THE LAST ROW IS AN EXAMPLE RULE. EACH TEAM WRITES ITS OWN.
Both tasks have an owner and are due on Friday. Only the recorded source of each date tells the agent what a miss means.

Ask the owner to agree to the date

A proposed date is not yet a commitment.

The owner needs a simple way to accept the date, or to object and say why. The reason may be a full sprint, a missing dependency or a clash with other work. When the objection comes early, a manager can still change the scope, reorder the work or clear the dependency.

Without this step, the first signal is a red "overdue" label after the date has passed. That shows the system noticed the miss. It does not show whether the date was ever realistic, or whether anyone agreed to it.

This matters most when the AI proposes the date. The agent can suggest a date, record the owner's answer and track the date they accept. Its own suggestion is not evidence that a person agreed.

When the first warning arrives, with and without agreement Two timelines from the day a date is proposed to the due date. Without agreement, nobody asks the owner, nothing signals a problem while there is still time, and the first signal is an overdue label after the date has passed. With agreement, the owner accepts the date or objects early and says why, for example a full sprint, a missing dependency or a clash with other work. That leaves time before the date for a manager to change the scope, reorder the work or clear the dependency. The agent can propose the date, but its own suggestion is not evidence that a person agreed. DATE PROPOSED DUE DATE Without agreement NOBODY ASKS THE OWNER NO SIGNAL WHILE THERE IS STILL TIME Overdue FIRST SIGNAL: THE DATE HAS PASSED With agreement THE OWNER ACCEPTS OR OBJECTS The owner objects early, and says why TIME TO ACT FULL SPRINT MISSING DEPENDENCY CLASH WITH OTHER WORK A MANAGER CAN STILL change the scope, reorder the work or clear the dependency THE AGENT CAN PROPOSE A DATE. ITS OWN SUGGESTION IS NOT EVIDENCE THAT A PERSON AGREED.
Without agreement, the first warning is an overdue label. When the owner can object early, the problem shows up while a manager still has time to act on it.

Check the current status before sending a reminder

Base each reminder on the work record as it is now. The event that scheduled the reminder may be out of date.

We do this in our own daily briefing. Before the agent repeats an item from the queue, it looks up the record the item refers to again. A meeting acceptance, an out-of-office reply or a warning may have mattered when it arrived and be out of date by the time a person reads the briefing.

Deadline follow-up needs the same check. Before drafting or sending a reminder, read the current status, owner, date, blocker and linked documents. If the work is done, has a new agreed date or is waiting on someone else, the old reminder should not go out as if nothing had changed.

You can test this. Schedule a follow-up, then finish the task or change its date before the follow-up is due. A well-built workflow reads the current record and stays quiet. A simple notification system sends the original reminder anyway.

The test: finish the task before the reminder is due A timeline with three moments: a follow-up reminder is scheduled, the task is marked done, and then the reminder comes due. The work record shows the status as open until the task is marked done, and done after that. A simple notification system sends on a timer, so when the reminder comes due it sends the original reminder that the task is due, which is out of date because the task is done. A workflow that reads the current record first looks up the record when the reminder comes due, sees that the task is done, and stays quiet. THE TEST STEP 1 STEP 2 STEP 3 Reminder scheduled Task marked done Reminder comes due Work record ITS STATUS OPEN DONE Simple notification system SENDS ON A TIMER WAITS FOR THE DATE SENDS THE REMINDER "Your task is due Friday" OUT OF DATE: IT IS DONE Reads the current record first CHECKS WHEN IT IS DUE THEN READS THE RECORD Stays quiet THE RECORD SAYS DONE
Finish the task between scheduling a follow-up and its due time. A timer sends the old reminder anyway. A workflow that reads the record first stays quiet.

Write down when a manager hears about it

Managers do not need a copy of every automatic reminder. They need to hear about the missed dates that put delivery at risk.

Decide those cases before the agent runs. For example, one team might allow one direct reminder for a missed internal target, and send a missed client or regulatory date to a manager straight away. Another team may draw the line somewhere else. What matters is that the rule is written down where people can review it, and the model does not make it up as it goes.

What happens when one reminder comes due When a reminder is due, the agent first reads the current record: status, owner, date, blocker and linked documents. If the work is done, has a new agreed date or is waiting on someone else, it stays quiet, and the outdated reminder does not go out. Otherwise, where the date came from decides what happens. In this example rule, a missed internal target gets one direct reminder to the owner, and a missed client or regulatory date goes to a manager straight away, with an alert that opens the work item. Each team writes its own rule. A reminder is due Read the current record STATUS, OWNER, DATE, BLOCKER AND LINKED DOCUMENTS Done, re-dated or waiting? YES Stay quiet NO OUTDATED REMINDER NO Where did the date come from? INTERNAL TARGET Remind the owner ONE DIRECT REMINDER CLIENT OR REGULATORY Tell a manager STRAIGHT AWAY ALERT OPENS THE WORK ITEM AN EXAMPLE RULE. EACH TEAM WRITES ITS OWN.
The reminder is checked against the current record before it goes anywhere. Then the source of the date decides who hears about it. The split shown is one example, and each team writes down its own.

The message to the manager should open the same work record. In our own system, an alert cannot go to a phone unless it is attached to a work item, so the person who gets it goes straight to the status, the owner and the documents behind it. The manager can act on the record instead of piecing the story together from old notifications.

Count only real signs of progress. A changed status, a delivered document or a recorded blocker is evidence. Silence tells you nothing, and time booked on a calendar does not prove the work is done.

The manager's alert opens the work record A manager's phone shows one alert, about a missed client date, and no copies of routine reminders. Opening the alert goes straight to the work record: its status, owner, due date and where that date came from, any recorded blocker, and the linked documents. Below the record, what counts as progress: a changed status, a delivered document or a recorded blocker. What does not count: silence, and time booked on a calendar. THE MANAGER'S PHONE THE RECORD IT OPENS NO COPIES OF ROUTINE REMINDERS ALERT Client date missed TIED TO A WORK ITEM OPENS WORK RECORD Task A STATUS Open, past its date OWNER A named owner DUE DATE Friday FROM A CLIENT REQUEST BLOCKER Recorded, if there is one DOCUMENTS Linked to the record COUNTS AS PROGRESS Status changed Document delivered Blocker recorded DOES NOT COUNT Silence Time booked on a calendar
The manager gets one alert, not a copy of every reminder, and it opens the work record. Progress is judged on what changed in that record.

Review the workflow before you automate it

If commitments are spread across email, tickets and project plans, first decide which record the follow-up should open. Then write down the rules:

  • Which system holds the status?
  • Who can set or change the date?
  • Where is the source of the date recorded?
  • How does the owner accept the date or object to it?
  • What evidence shows the work is done?
  • What stops an out-of-date reminder from going out?
  • Which missed dates go to a manager?
  • Which record does the manager's alert open?

Our AI Workflow Review is built for these questions. A team brings up to three workflows it wants to automate. Over two weeks, we map each workflow, its data and who signs off, then deliver a written assessment: what to build, what would stand in the way, and which workflow to start with.

Deadline follow-up is a good place to start. Sending the message is the easy part. Most of the work is in the rules and records that decide whether the reminder is still true.

For how we decide which alerts reach a person at all, read How we cut ten alerting agents down to one. Our own follow-up rules are on How we run Kaizen on AI.

Want the same for your company?

Bring us two or three workflows that take up your team's week. We will tell you which one to automate first.

How we implement AI

Book a 30-minute call