I use Calendly to book meetings. I also use it to grow my newsletter list, with a marketing consent checkbox tucked into the booking form. On every event type I have, that checkbox is optional. Tick it if you want the newsletter, leave it if you do not.
Except on one of my newer event types, it was not optional, it was mandatory (the HORROR). Anyone booking that particular meeting had no way to get through the form without agreeing to marketing emails. That's not consent, that's coercion, and it's something I lecture my clients on repeatedly.
Ultimately, a #Facepalm moment if ever there was one, doubly so because it was a privacy colleague who caught it, not me.
How Did This Even Happen?
That is the question worth spending time with, because the honest answer is: easily. I did not decide to make consent mandatory, I did not think it through and get it wrong. I built a new event type, copied and pasted the very clear consent wording, and I moved on with my day without malice or taking a shortcut, just a default setting I did not check.
Ask yourself the same question about your own stack. When was the last time someone on your team added a new form, a new event type, a new signup flow, and simply accepted whatever the tool defaulted to? Did anyone check whether that default matched your actual consent posture, or did everyone assume it would behave like the last one?
Under most privacy laws, consent that is not freely given is not valid consent. A mandatory checkbox tied to something unrelated to the service being requested, in my case, booking a meeting, is exactly the kind of bundled, non-optional "consent" that regulators take issue with. It does not matter that I never intended it, intent is not a defence when someone has already been forced through that checkbox.
Config Drift Is the Real Story Here
This was not a policy failure, my policy on marketing consent was fine. It was a configuration failure, and configuration failures do not send you a notification before they happen. They sit quietly in a settings page until someone clicks through a booking flow, an onboarding screen, or a cookie banner and notices something is off.
Every tool you add to your stack ships with its own defaults, and those defaults change with updates, new features, and new templates. A setting you configured correctly a year ago does not stay configured. It drifts, silently, until your actual practice no longer matches what you told your customers or put in your privacy notice.
A few questions worth asking your own team this week:
Who is responsible for reviewing consent settings when a new form, event type, or integration gets added? Is there a checklist, or is it "common knowledge"? When did anyone last audit the booking tools, signup forms, and marketing integrations you already have live?
Thankfully, mine had only caught one booking before it was flagged, and it was flagged by someone who knew it was a mistake. I couldn't have asked for a better notification. It could just as easily have gone unnoticed for months and dozens of bookings.
This is a prime example that makes team training valuable and relatable, and I am always happy to bring this topic to a team offsite or all-hands. These types of things tend to land well precisely because it is a mistake I made myself, and it's one your team could make easily. Reach out to find out more.