Booking a call: a subscription for a widget you cannot change

They paid for Calendly every month and could not extend it. It knew nothing about the person: not the funnel data, not the income estimate for their flat, not the CRM fields.

Calendly → our own widget

In short

The situation

Booking a consultation lived in Calendly: a monthly subscription and no way to extend it. It did not read what the person had just entered in the funnel, could not show the income estimate for their flat, and did not write into the CRM properties the sales team actually works in. The manager typed the property postcode in by hand.

What we did

We built our own booking screen on our own domain. It carries the funnel data over, shows the income estimate for the flat right before the time picker, and fills in the CRM record itself. The owner edits the copy from a chat with AI, without a developer.

What hurt

The company manages property in the UK. The top of the funnel is a free consultation: the owner leaves a request and picks a time for the call. Booking lived in Calendly, embedded into the page.

It worked, and they paid for it every month. But the subscription was the smaller problem: Calendly cannot be extended. What it does out of the box is all it will ever do.

The first thing it could not do was know the person. The owner had just been through the marketing page: entered the address, the number of bedrooms, the property type, looked at the income estimate. Then Calendly opened and asked for all of it again. Half of them dropped out right there.

The second was showing the one thing that matters. The income estimate for that particular flat is the strongest argument at the moment of booking, and there is no room for it inside Calendly. No room for the plans either, or for a separate short screen for people the team had already spoken to.

The third was the CRM. A contact record has 571 fields, and the sales team lives in specific ones: bedrooms is filled in on 8,495 contacts, rental duration on 1,223, hosting readiness on 970. Calendly does not write to them, and you cannot teach it your fields. The call date arrived as a free-form string. The property postcode was typed in by hand, even though the person had already entered it on the previous screen.

And the fourth was the copy. The booking screen and the confirmation email sell exactly the way a landing page does: you want to test wordings and change them. But a Calendly page cannot be edited at all, and the email only through its own template. Everything else turns into a developer ticket and a wait for a release over a single sentence.

What we built

Our own booking screen, in the exact spot where Calendly used to sit. One thing at a time below.

01.

Nobody types what they already typed

Whatever the person entered on the marketing page moves onto the booking screen by itself: address, bedrooms, property type, contacts. It lives for half an hour and is wiped.

It also attaches the booking to the same CRM contact instead of creating a duplicate next to the existing one.

If everything needed came through the funnel, the extra screens are simply not shown: the person sees their own details and a button. Booking in two clicks. “Change my details” opens the usual steps.

Data from the marketing page moves onto the booking screen
02.

The income estimate on the same screen

From the postcode, the number of bedrooms and the property type, the screen shows the expected monthly income and occupancy. It covers 205 postal districts, and every property type has its own calculation: flat, house, HMO, hotel.

Next to it, a map with “what neighbours earn” markers. The same flat always produces the same picture: nothing flickers or gets recalculated on every page load.

A postcode and a bedroom count turn into an expected income
03.

Nothing on the way to the call can break it

The booking counts as done the moment the meeting appears in the team calendar. Everything else — the CRM lead, the email to the person, the email to the team — follows after. If the CRM or the mail provider goes down, the booking stands: the person already has the invite.

Before connecting anything we went through all 571 contact fields by hand, so as not to breed duplicates next to the working ones. Of the eight new fields planned, two were created.

And we agreed not to touch what belongs to others. Sales notes written after calls (3,024 contacts) stayed sales notes. Agreed commercial terms (188 contacts) stayed terms. Interest in a plan is written elsewhere. The property postcode now arrives with the booking on its own, both into the calendar and into the CRM.

The CRM did not answer — the booking still happened
04.

We moved without a kill switch

Calendly was not switched off on launch day. The new screen put meetings into the same calendar and named them exactly the same way. In the day view the team could not tell where a booking came from. Both systems ran side by side for a while.

Same in the CRM: we wrote into the old field and set the lead status the sales funnel was used to. Our own status came later, once it was clear everything worked.

Moving off a working tool must not break the sales team's reports and habits on day one.

Both systems wrote identical meetings into one calendar
05.

The owner edits the copy — straight from a chat with AI

Every line on the booking screen and in the emails is kept outside the code. The site has a connector (an MCP server) — think of it as a socket an AI assistant plugs into and gets the right to read and change that copy.

The owner opens their usual chat — ChatGPT or Claude — and writes in plain words: “shorten the heading on the booking screen”, “make the confirmation email shorter”, “fix the plan description”. The AI changes the copy on the site itself. A couple of minutes later visitors see it.

No developer ticket, no release, no admin panel to log into. Testing a new wording now costs one line in a chat instead of a week of waiting.

And there is nothing to break: if an edit does not fit, the page falls back to the original wording. The plan name on the site is separate from its code in the CRM, so renaming a card is free, and sales reports do not drift.

One line in the chat — and the copy on the site is different

A few numbers

32hours to build, launch and refine
2clicks to book if the person came through the funnel
205postal districts in the income estimate
0developer tickets to change a line of copy

The same job, as a product

A request is the end of a long path, and it breaks on small things: the person types what they already typed, gets no answer to their question, hits someone else's screen and leaves.

An AI assistant covers this stretch together with the messaging: it fills in what is already known, answers questions before the call and drops the request into the CRM with no manual copying.

Result

Metric
Before
After
Scheduling widget
Calendly, on a subscription
our own, on our own domain
Extending it to fit the process
impossible
anything, the system is ours
Funnel data in the form
re-entered by hand
pre-filled, booking in two clicks
Income estimate on the booking screen
nowhere to put it
205 postal districts
Property postcode in the CRM
typed by hand
arrives with the booking
Editing copy on the site
a release
from a chat with AI, a couple of minutes

Recognise the problem?

Give us 30 minutes and we will tell you which of this can be repeated at your company.