Otto set the next follow-up for after the event date (how event-driven plays decide something is due)

Modified on Tue, 4 Aug at 4:34 PM

Your gig is on 31 July and Otto has set the next touch point for 2 August. The performer who first reported this wrote it as Followup date is past event date, and spelled it out underneath: event is July 31 but Otto sets next touch point for August 2. The fair reaction is why is it following up after the gig, when the show will already have happened. You are right. It was a real bug, it is fixed, and this article covers what changed, how to get it, and what to do by hand on a gig that is already scheduled wrong. The second half explains the wider behaviour it sits inside: how event-driven plays decide that anything is due at all.

Why the follow-up date is after the event date

When Otto planned the next follow-up, he counted a few quiet days forward from your last touch. That is the ordinary chase rhythm, seven quiet days by default, and for a lead who has gone silent it is the right rhythm. What that sum never did was measure itself against the gig's own date. Nothing in it knew there was a deadline. So on a 31 July event, counting a couple of days past your last touch put touch two on 2 August.

When the follow up is after the event, it is worth nothing. By then the buyer has booked someone else or the night has simply passed. The message can be perfectly written and still cannot win you the booking.

Changing the Quiet for number on Silence Patrol is where most people go first, and it is a dead end. The count was never the problem. There was no ceiling at the event date at all, so a shorter gap only produces a differently wrong date on a tighter gig. Skip that step.

The rule since version 1.11.21

This was fixed and shipped in 1.11.21. From that version on, Otto plans a chase against the event date and not only against the calendar. The rule has three parts:

  • While a lead is still being chased to book, every follow-up must land before the event date.
  • If there is no room left for another touch, Otto sends the final nudge now instead of scheduling one for afterwards.
  • Once the date passes with no yes, Otto calls the lead lost rather than quietly queueing a chase into a date that has gone.

Two edges of the rule matter, and they are the reason it is written this narrowly:

  • A touch that lands on the event day itself still counts as in time. Only a date after the event is late.
  • Gigs you have already booked are untouched by this. Their after-the-event moves, the thank-you, the review ask, the rebook touch that The Flywheel handles, are meant to land later and still do. The rule only ever applies to a lead you are still chasing.

Be clear about what this is not. There is no new setting and nothing to switch on: it is part of how Otto plans, from 1.11.21 onward. And the app does not refuse to save a gig whose Next move due falls after the event. A hard block there would also refuse legitimate saves on booked and completed gigs, where a later date is exactly correct. This is a planning rule for leads still in the chase, not a validation error you will see on screen.

Getting the fix

  1. Click Check for updates in the top bar, near the logo.
  2. Let the update window work through checking and downloading. When it reaches ready, click Restart & install.
  3. The app restarts on the new version. Updates replace only the app itself: your work and saves are never touched.

To see which version you are on, open Settings > General and look at the Updates card. It reads You're running Booked Solid followed by your version number. Anything from 1.11.21 upward already has this fix.

Two ways to put a single gig right by hand

Use these if you have not updated yet, or if a lead is already sitting there with a next date past its event.

  1. If the gig is only a day or two out, tell Otto in chat: send the final nudge before the event. He drafts one now instead of waiting for a date that would be too late to be any use.
  2. Or set the date yourself. Open the Gig Desk tab, click the lead's row to expand it, click Edit gig details, set Next move due to a date before the event, then click Save changes. That is the exact field Otto and your desk both read, so changing it there changes what actually happens and not only what is displayed.

Nothing is lost while this is happening

This is the part worth hearing first, and it usually is not. Nothing is lost. The lead, the quote (in the case that reported this, a $700 quote) and the proposal-sent status all stay on the record exactly as they were. Only the timing of the next touch was wrong. Nothing needs re-entering, and there is no reason to delete the lead and rebuild it.

Turn event-driven plays on, one play at a time

All of the above sits inside a wider behaviour worth understanding: some plays can start themselves when something real happens in your pipeline, such as a lead going quiet, a client accepting, or a show date getting close. That is opt-in, one play at a time. Nothing starts itself unless you switched that play on.

  1. Open Settings and find the card called Plays that may start themselves.
  2. You will see the plays that can react to events, each with its own toggle labeled Allow [play name] to queue itself. Every toggle starts off.
  3. Switch on only the ones you want queued automatically.

What makes a play due

Each play watches for one specific signal:

  • Silence Patrol: a lead you are waiting on has been quiet for 7 days or more.
  • Handle the Reply: a lead needs a reply.
  • Lock It In: a lead moved to accepted.
  • Show Ready: an event date is within 14 days.
  • The Flywheel: a done lead's event date has passed.
  • Warm Desk and Business Check-In: these run on a weekly and monthly rhythm rather than a lead event.

While the app is open, Otto rescans your pipeline for these signals about once a minute. There is no background service, so if the app is closed nothing is being watched.

When a run does fire, its card shows the reason in plain words, for example that a lead has been quiet for 9 days or that a lead said yes, so you are never guessing why it started.

Due does not mean unsupervised

An event-triggered run goes through the exact same rules as a run you start by hand. Your autonomy dial still governs what happens: on Show me everything stays a draft, on Check with me anything that sends, commits, or spends stops for your approval, and even on Run it the uncrossable limits hold. Turning a toggle on decides when a play may start, never what it is allowed to do.

Two more checks run before anything happens:

  • Right before a queued job starts, Otto re-checks the trigger. If the situation changed, say the quiet lead already replied, the job quietly completes as No longer needed; the original trigger has changed. instead of running on stale information.
  • If a play still needs setup, for example it has not learned your voice yet, the automated run is blocked by the same context gate that blocks a manual launch, instead of guessing.

Good to know

  • Only one job runs at a time. A due play waits its turn behind whatever is already running.
  • If the app closed in the middle of a run that may have contacted someone, that job is marked failed and is never replayed automatically. Review it before running the play again so nobody hears from you twice.
  • Your own cap on how many times Otto may follow up a single lead lives under Settings > General, in Most follow-ups per lead. The event-date rule above sits on top of that cap rather than replacing it.

If it still looks wrong

If you are on 1.11.21 or later and a lead you are still chasing shows a next touch dated after its event, tell us rather than working around it. Include the lead's stage, the event date, the date showing under Next move due, and the version from the Updates card in Settings > General. That is enough for us to reproduce it.

Still stuck? Email bookedsolid@kivimedia.freshdesk.com and a person will help.

Was this article helpful?

That’s Great!

Thank you for your feedback

Sorry! We couldn't be helpful

Thank you for your feedback

Let us know how can we improve this article!

Select at least one of the reasons
CAPTCHA verification is required.

Feedback sent

We appreciate your effort and will try to fix the article