For a long time, Calendly was my default answer whenever a client needed appointment booking on their WordPress site. It was quick to set up, connected to Google Calendar, and handled the confirmation emails. I could configure it in under an hour and move on.
Then a client asked me a question that I didn’t have a good answer for.
The question that changed my thinking
We had just launched a website for a therapist. Clean design, professional copy, carefully chosen fonts and colours. She had invested real money and time into the project. When I showed her how the booking worked, she clicked the “Book a session” button and landed on a page that looked nothing like her website.
She looked at the screen and said: “Why does it take them to a completely different website?”
I explained that it was Calendly, that it was normal, that most booking tools worked this way. She accepted the explanation, but I could tell it bothered her. It bothered me too — I just hadn’t articulated why until that moment.
We had spent weeks building trust through her website. The colours, the photos, the way the copy was written — everything was designed to make a prospective client feel comfortable enough to take the next step. And then the next step sent them somewhere else.
The problems that had been there all along
Once I started paying attention, I noticed the same friction across multiple client sites.
The redirect broke the experience. Not just visually — practically. Some clients reported that their customers got confused, thought they’d been taken to the wrong place, and left without booking. The handoff from a professional website to a generic Calendly page introduced doubt at exactly the wrong moment.
Clients kept asking about the monthly fee. Calendly’s free plan allows one event type. Most of my clients needed more than that, which meant a paid subscription. That’s $10/month minimum — $120/year — for a tool that doesn’t even live on their website. Every renewal, someone would email asking what the charge was for.
The branding was always Calendly’s, not the client’s. Even on paid plans, the booking page is styled by Calendly. You can change the accent colour and add a profile photo. You cannot match fonts, adjust the layout, or remove Calendly’s visual identity. For clients who had invested in a distinctive brand, this felt like a step backwards.
The data wasn’t theirs. Every client’s booking history — their customers’ names, emails, appointment records — lived in Calendly’s database, not on the client’s server. I started to feel uncomfortable recommending a setup where a client’s business data was held by a third party that could change its pricing or terms at any point.
What I tried before finding a real solution
I looked at several alternatives before settling on what I use now.
The Google Calendar iframe embed was the obvious free option. It displays your calendar on the page, which sounds useful until you realise it’s read-only — visitors can see your events but can’t book anything, receive no confirmation, and you get no record of who wanted an appointment. Not a booking tool at all.
Amelia was another option I tested. It’s a well-built plugin with a lot of features — multi-staff scheduling, payment collection, a customer dashboard. But for a solo therapist or consultant, most of those features are unnecessary complexity. More importantly, Amelia’s Google Calendar sync uses OAuth, which means it needs to be reconnected periodically, and availability in the widget doesn’t come directly from Google Calendar — it comes from Amelia’s own database, with Google Calendar as an additional sync layer.
For clients who live in Google Calendar, that distinction matters. They block time in Google Calendar constantly — personal appointments, school runs, working-from-home days. They expect the booking widget to reflect all of that automatically. With a sync-based approach, it sometimes doesn’t.
What I switched to — and why it works
I now use CalNative Booking on client sites where the client uses Google Calendar and needs appointment booking embedded on their WordPress website.
The setup requires creating a Google service account — a one-time process that takes about 20 minutes. It’s the part that sounds technical but is actually straightforward once you’ve done it once. After that, the plugin connects to Google Calendar via the API and stays connected permanently. No OAuth tokens to refresh, no reconnection prompts.
The booking widget sits inside the client’s page — inside their header, their footer, their fonts, their colours. The “Book a session” button doesn’t take anyone anywhere. The booking happens right there. Visitors who were about to leave because they got redirected somewhere unfamiliar now complete the booking without hesitation.
When someone books, a real event appears in the client’s Google Calendar with the customer’s name and contact details in the event description. The client receives an email notification. The customer receives a confirmation email with an ICS file they can save. There’s a cancellation link in the email so customers can cancel themselves if they need to, without contacting the client.
All of this happens on the client’s server. The booking records are in their WordPress database. The events are in their Google Calendar. Nobody else holds their data.
The practical difference for clients
The therapist I mentioned at the start now has a booking widget that matches her site exactly — same fonts, same colours, same rounded corners. When a prospective client clicks “Book a session,” they stay on her page. The transition from browsing to booking is invisible.
She pays $39/year instead of $120/year for Calendly. She no longer asks what the monthly charge is for.
The other thing she mentioned, unprompted, a few weeks after launch: “It just feels like mine now.”
That’s the difference I was trying to describe when I couldn’t answer the question well the first time.
When I still recommend Calendly
I want to be clear: Calendly is a good product. I still recommend it in specific situations:
- When a client needs round-robin scheduling across a team of people
- When they need deep integrations with Salesforce or HubSpot
- When they don’t have a WordPress site and just need a link to share
- When they use Outlook or iCloud, not Google Calendar
For solo practitioners and small teams who use Google Calendar and run a WordPress site, it is no longer my first recommendation. The redirect alone is enough to disqualify it for most of those clients.
What changed my default recommendation
It wasn’t a feature comparison. It was a client asking why the booking took her customers to a different website, and me not having a satisfying answer.
The right answer, it turns out, is: it doesn’t have to.
