One customer record instead of disconnected systems.
Sign-ups, tennis school, summer camp and events: an office receiving requests from website, email and phone, rebuilding by hand who was who.
The challenge
The website was separate from the office: forms arrived by email, the same person appeared several times with slightly different data, and the history in the previous system had never made it into the new one. Nobody could say how many people really used the club.
The approach
First the map: where a person’s data comes from, and which fields reliably say two rows are the same person. Then a fast static website and a CRM sharing the same database. Staff don’t link anything: the system does.
Live
Real screens.
The website, the app and the tools as customers and staff use them today. Tap a screen to enlarge it.
Three requests, three different names.
One person.
Behind the login
Tennis Club Ambrosiano
What you only see from inside — the CRM, the member app — rebuilt and animated with anonymised sample data.
Members, tennis school and revenue
How many members, how many in the tennis school and summer camp, how much comes in month by month: after de-duplication these are people, not forms.
Monthly revenue (€)
Active memberships by type
- Members49%
- Tennis school25%
- Summer camp11%
- Events15%
Latest payments
- LLuca V.Tennis school · adult course€420.00
The same person, only once
A website form, a tennis-school sign-up, a contact from the archive: three rows, one person. The system recognises and merges them; staff see it already done.
The person’s record
Everything that happened with a person, in order: requests, sign-ups, events, who followed up. The office answers without searching three places.
- OctEvent sign-upClub doubles tournament
- JulSummer campSon · 2 weeks
- MayInvite a friendInvited 2 people
- SepTennis schoolAdult course · Tuesday
- 2023First contactFrom the imported archive
Where people come from
Junior and adult requests, month by month, after de-duplication: finally people, not forms.
What we built
- 01Fast public website with a CMS for the office
- 02Request normalisation and de-duplication: one row per person
- 03Import of past events from the previous system
- 04Office CRM: people, opportunities, shared calendar, tasks
- 05Tennis school, summer camp and event sign-ups
- 06“Invite a friend” pipeline, newsletter, notifications
- 07Sync with the club’s back office
Technology
How it’s built
Under the hood.
The website stays static and very fast; the office works in a separate CRM with logins and live data. Two projects, one database: it’s the database that holds the people together.
The architecture, layer by layer
The pieces, one by one
Astro
The website
Generated ahead of time: no server to maintain, ready HTML pages, minimal CSS. Content is updated from a visual editor.
Why two applications
Website and CRM apart
The website is static; the CRM needs logins and data that’s current to the second. Keeping them apart, on the same database, keeps the website simple and leaves the CRM free to grow.
De-duplication
One row per person
Rules on normalised name, email and phone decide when two rows are the same person. Requests stay many, the person is one; opportunities belong to the person.
n8n
Automation
Website forms go through n8n flows that normalise them and write them to the right tables, with nobody in between.
Supabase + RLS
Who sees what
Access rules live in the database, row by row: every operator sees what their role allows, whatever page they use.
In numbers