Practical automation · 4 min read
Keep Keap follow-up in step with booked calls
Stop asking people to book a call they have already booked. Check the Keap stop rule, handle Calendly reschedules, and make repeated notifications safe.
A lead books a call, but your Keap reminders keep arriving, asking them to do something they have already done. Removing a "Needs to book" tag may look like a fix. It does not necessarily stop the messages that are already scheduled. Check the rule that ends the reminder sequence, then decide how bookings, reschedules, and cancellations should change it.
What to take away
- Removing the tag that started a Keap sequence does not stop that sequence. Test the rule that ends the reminders.
- A Calendly reschedule produces both cancellation and creation notifications. Link the old and new invitee records before changing follow-up.
- Decide what a true cancellation should do before you build anything: restart the reminders, wait, or hand the contact to a person.
- Test with real webhook payloads, including a reschedule and a cancellation, before turning the automation on for every contact.
Map booking, rescheduling, and cancellation before changing anything
List what can happen after someone gets a reminder: they book, reschedule, cancel, or never respond. Each needs a different outcome. Booking should stop the reminders. A cancellation might restart them or route the contact to a person. A reschedule usually needs no reminder change at all, since the person still has a call on the calendar.
Calendly sends both invitee.canceled and invitee.created notifications when someone reschedules. The canceled invitee has rescheduled set to true. The old_invitee and new_invitee references live on the invitee records and help connect the two bookings. This tells you how to recognize a reschedule; it does not establish a delivery order your integration can rely on.
If your automation only listens for a cancellation event and treats every one the same way, a simple reschedule will look like a lost customer. Check the rescheduled flag before deciding what to do.
Sources: Calendly Developer Docs: How webhook payloads change when invitees reschedule events
Connect the booking to the right contact
Consider a hypothetical chiropractic practice that sends three emails asking a lead to book a first appointment through Calendly. When the booking arrives, the integration should record it against the right Keap contact and run the tested rule that ends those reminders. The acceptance check is simple: the contact has a booked appointment and no further request to book that same appointment.
Use a confirmed contact link when you already have one. For a first match, an email address can help find candidates, but shared addresses, changed addresses, and duplicate records need care. Route uncertain matches to a person instead of applying tags to the first result or creating another contact automatically.
Keep appointment reminders separate from prompts to book. A reschedule should update the appointment details without putting the person back into the campaign that asks them to choose a time. Test each path, including someone who has more than one active booking.
Decide what a true cancellation should do, and plan for repeat deliveries
A Calendly cancellation with rescheduled set to false is different from a reschedule. Before restarting booking prompts, check whether the person has another active booking. Then apply the agreed policy: wait, offer another time, or assign a person to follow up. A cancellation should not quietly reset unrelated campaigns or contact preferences.
Design the integration to tolerate repeated notifications and uncertain outcomes. Save a processing record with a stable key for the invitee and the business action. That record needs to prevent two workers from doing the same work at once and support a retry after a failure. A note or a single custom field in the CRM can help your team see what happened, but it is not sufficient protection against duplicate work.
Test a repeat notification and a failure after Keap has accepted an update but before your integration receives the response. Also reverse the arrival order of reschedule notifications. The final booking state and reminder state should agree in every case.
Sources: Calendly Developer Docs: How webhook payloads change when invitees reschedule events
Keep this handy
Your pre-project checklist
- Can you show which rule ends each reminder sequence after a booking?
- Does the test confirm that scheduled booking prompts stop, rather than only showing a changed tag?
- Does a reschedule leave the contact booked, whichever notification arrives first?
- Are uncertain contact matches sent to someone who can check them?
- Does a true cancellation account for any other active booking and the agreed follow-up policy?
- Can two workers or a repeated notification cause the same business action twice?
- Can the team see failed or uncertain updates and recover without starting the whole campaign again?
Prefer to write it down? Tell us about your project. No portal account required.
These examples explain how we would approach the work. They are not client results. How we write our guides or send a correction.