This work is covered by a non-disclosure agreement with Smoothops Consulting and their client. The client is not named and not described. What is described is the shape of the system and the rules it runs on.
How Abhiman Labs built a nine database operations system for a Smoothops Consulting client
The data was all there. Nothing in it knew about anything else.
The Problem
Bookings and revenue came out of Semper, the property management system the team runs on. The rest of the operation, the venues, the customers, the contacts, was tracked outside it. Each place was correct about its own slice and knew nothing about any other.
So every question that crossed a boundary was answered by a person with two tabs open. Which venue earned that revenue. How many bookings that customer has made. Whether the contact on the reservation is the same person as the one in the other sheet. Those answers existed, but only after someone went and assembled them.
Nine databases that know about each other
The fix was not another dashboard. It was giving the records a way to point at each other, so that the connection is stored rather than reassembled each time someone needs it.
- BookingsWho stayed, when, and against which reservation.links to Customers
- CustomersOne record per guest, not one per booking.links to Venues
- VenuesThe property a booking and a customer belong to.links to Revenue
- RevenueFigures that roll up to the venue that earned them.end of the chain
How the sync runs
A record changes at the source and a webhook goes out. n8n picks it up immediately, so the workspace is never waiting on a nightly batch to be right.
- 01Source data collectedBooking records, revenue figures, customer and contact data, read out of the system that already holds them.
- 02Webhook fires on changeA record changes and an event goes out immediately. Nothing waits for a nightly batch.
- 03Matched on a unique keyEach Notion database is checked on its own key before anything is written.
- 04Updated or createdAn existing record updates in place. A genuinely new one is created. Never both.
- 05Relations appliedThe booking is linked to its customer, the customer to its venue, the venue to its revenue.
- 06Notion AI reads itStructured and relational, so the data can be queried rather than exported.
The step that matters is the third one. Every database is checked on a unique key before anything is written, so a record that already exists is updated in place rather than added again. That is the difference between a sync you can leave running and one that quietly fills a workspace with duplicates.
What sits on top
Notion AI reads this workspace directly. It can do that because the data underneath is structured, relational and consistently formatted, which is a property of how it was built rather than something switched on afterwards.
So the team asks about revenue patterns and booking trends in the workspace they already work in, and the answer comes back from live records. Nothing is exported to a spreadsheet to be analysed and then go stale.
Before and After
The Result
One workspace holds the operation. A booking knows its customer, a customer knows its venue, a venue knows its revenue, and none of those links has to be rebuilt by a person again.
Smoothops scoped it and held the client. Abhiman Labs designed the schema, built the sync and shipped it. The sync system is the other project on this engagement, and it goes considerably deeper into the automation side.