One signature on a form, and the whole back office moves.

The form was never the problem. Someone filled it in, signed it, and from that moment on a person had to carry the new member through four different systems by hand. The member saw a confirmation screen. Behind it, nothing had happened yet.

Someone joining for the first time, someone renewing for another year, and someone coming in halfway on a half membership are not variations on a form. They are different amounts, different records, and in one case a company that does not exist in the books yet. So they do not share a form. Each situation has its own, and the member is sent to the right one before they type anything.

And enrolling is only the first half. Being a member means turning up to things, which is its own flow with its own confirmation.

Concretely: the Tally form posts straight into Make.com. Make.com looks the member up, checks the company against the official VAT registry when it does not know it yet, creates or finds the customer in Billit, raises the invoice with a fourteen day term, generates the subsidy document from a Google Docs template with that member's own amount in it, sends the welcome mail from the community's own Microsoft 365 address with both PDFs attached, hands the invoice to Peppol, and opens the follow-up work in Asana with the invoice itself attached to the task.

Four connected scenarios. The sign-up chain alone is forty-six steps. They already paid for every one of these tools. I did not replace anything. I made them talk.

These members are businesses, and a business invoice has to name the business correctly. Not roughly correctly. The legal name, the street, the number, the postcode and the country all have to match what sits against that VAT number, or the invoice is wrong in the books and the Peppol delivery has nothing solid to land against. People do not type their own company name the way the registry holds it. They abbreviate, they drop the legal form, they give the office they work from rather than the seat of the company.

So the automation does not build the customer record from the form. When the company is already a customer, it uses the record that exists and creates nothing. When it is not, it takes the VAT number to the official registry, and builds the customer in Billit out of the answer that comes back. The form supplies the person. The registry supplies the company.

The nicest part of this build is not the invoicing. It is that the community can help a member claim part of their membership back through a public subsidy scheme, and used to do it by filling in the same document by hand for every single person. Now the automation reads the amount off the invoice it just raised, drops it into the template with the member's company name, exports it as a PDF, and sends it out attached to the welcome.

Welcoming someone into a community is not a system job. Adding them to the group chat is a person with a login. Introducing them to the other members is a person writing a message. Those are exactly the two things that slip, because they happen days after the payment, when the sign-up no longer feels new.

So the automation schedules them. Not as vague reminders, but as tasks that already carry everything the person needs to do them.

The sign-up forms live in their Tally account, where they can change a question without telling me. What a membership costs, and what it is made of, lives in Billit, where their bookkeeping already sits. Change the product there and the next member is invoiced the new way. There is nothing to sync and nothing to send over.

What still comes back to me is the wording of the welcome mail and a kind of membership that does not exist yet. 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.