A custom quote in their inbox before the form even closes.

You cannot publish a price list for events, because there is no such thing as a standard event. What kind is it, on what date, for how many people, how many of those are children, do they want breakfast, lunch, dinner, drinks, all of it or only some of it, are they bringing their own caterer, does the building need cleaning afterwards. Every one of those answers moves the price.

So every enquiry opened a thread, and the thread ran for days before anybody could put a number on paper.

There was software for this. Proper quoting software, with a licence fee to match, and it wanted to become the place where their events lived. Which meant it would have pushed Asana out, and Asana is where the team actually works. Buying it would have solved the quote and broken the workflow around the quote.

So the job was never "build them a quoting tool." It was: let the guest answer the questions themselves, and let the tools they already pay for do the rest. What makes that hard is that no single answer sets a price. The event type, the date, the season, the day of the week, the number of days, and whether that date happens to be a public holiday all combine into one hire rate out of thirteen. Then the food is priced per head, split between adults and children, across thirty-three separate lines.

Concretely: the Tally form posts straight into Make.com. Make.com reads the answers, works out how long that particular event actually holds the building, and asks Google Calendar whether it is free for exactly that window. If it is, it checks whether the date is a Belgian public holiday, resolves which of the thirteen hire rates applies, and turns every box the guest ticked into a quote line. It looks each line up in the client's own invoicing catalogue, so the wording, the unit price and the VAT come from there rather than from the form. If a VAT number was given, it strips it down to digits, validates it against the official register, and finds or creates the company as a customer. Then it creates the quote, has the invoicing system mail it to the guest ready to sign, opens a task on the Asana board carrying the head count, the totals and a link to the quote, and attaches the quote PDF to that task.

Sixty-two steps in a single scenario. They already paid for Tally, for the calendar, for the invoicing tool and for Asana. Nothing new was bought and nothing was replaced. I made them talk.

An instant quote is only a good idea if the venue is actually available. Otherwise the automation gets faster at making a promise the client has to take back, which is worse than being slow.

So before anything is priced, the scenario works out what the requested event really costs in calendar time. A wedding does not occupy an afternoon, it holds the building from the evening before to the day after, and from sixteen hours earlier again if the couple booked the morning. A corporate day occupies exactly the half days it was booked for, morning, afternoon, evening, or a run of days. Only once that window exists does it ask the venue's own Google Calendar whether anything is already sitting inside it.

If something is, no quote is made. The guest gets a mail the same minute: the date has gone, here are the free dates, and here is the form again if you can move.

There are no prices in the form. Every question on it is named after a product code in the client's own invoicing catalogue. Tick the dessert buffet and the form does not send back "dessert buffet, fourteen euro a head." It sends back a code, and the word true.

Make.com takes every code that came back true, looks it up in the catalogue, and builds the quote line out of what it finds there: the wording, the unit price, the VAT rate. Children are priced off their own separate set of codes, so a table of forty with twelve children at it gets twelve lines at the children's rate without anybody counting heads twice.

Which means a price change happens where it always happened, in the tool where their bookkeeping already sits. The next quote uses it. Nobody has to open the automation.

A quote sitting in an inbox is not a booking. Somebody has to call. And the whole reason the client would not give up Asana is that Asana is where "somebody has to call" turns into somebody actually calling.

So the last thing the scenario does is open the work. Not a notification. A task with everything already in it.

What an event costs lives in their invoicing tool, next to their bookkeeping. What the guest is asked lives in their Tally form. Both were already theirs before I arrived, and changing either one takes effect on the very next enquiry. There is nothing to sync and nothing to send over.

What still comes back to me is a genuinely new kind of event, or a new rule about how a date is priced. That is deliberate, and it is the line I try to hold on every build. An automation nobody but its builder can change is not an asset, it is a dependency.