Catch fake Calendly bookings before your AE wastes the slot

Build me an agent workflow that triages every new Calendly booking so my AEs do not waste demo slots on fake or low-intent invitees.

Trigger: Calendly webhook on the invitee.created event. When Calendly fires the webhook, the agent should run with the invitee's name, email, the meeting time, the event type, and the user who owns the calendar.

Step 1. Check the email with ZeroBounce. Call ZeroBounce Validate Email on the invitee's email address. Then call ZeroBounce Get Activity Data on the same address to see if the mailbox has shown recent inbox activity. Keep both results.

Step 2. Decide a risk level. Mark the booking as high risk if any of the following are true: the email status from Validate Email is invalid, the sub-status flags it as disposable or role_based, or Get Activity Data returns no recent activity at all. Otherwise mark it as low risk.

Step 3. Update Attio either way. Use Attio Assert a Record (Upsert) on the People object, matching on email_addresses, to create or update the person with their name, email, and a booking_risk attribute set to either high or low. Always do this step so the AE has CRM context when they open the meeting.

Step 4. If the booking is high risk, also do these two things. First, use Attio Create a Task linked to that person record, assigned to the Attio user that matches the Calendly meeting owner's email, with a short title like "Confirm Calendly booking with <invitee> before prep" and a deadline 30 minutes before the meeting. Second, use Slack Send a Message (via the Slack Bot integration) to ping the AE who owns the calendar. Pick the channel by mapping the Calendly meeting owner to a Slack user and DMing them, or post into a shared #booking-triage channel if I configure one. The Slack message should say who booked, the meeting time, the event type, and one short line explaining which ZeroBounce signal raised the flag (for example: "flagged as disposable" or "no recent inbox activity").

If the booking is low risk, do not send any Slack message and do not create a task. The silent Attio upsert in step 3 is enough.

Use an agent because the Slack copy and the reason line should read naturally and reflect whichever ZeroBounce signal actually fired, instead of a templated one size fits all message.