Client records
In developmentClient records with contact details, lifecycle stage and tags, with wedding details such as date, venue and party size stored alongside.
Andiamo SMB · Venues
An enquiry for a date, a show round, a deposit that turns a courtesy into a booking, then months of quiet before every detail arrives at once.
How the work runs
Written for Barns, halls, estates, restaurants with a private room and small hotels that let their space for weddings, parties and company events, run by a small office and a duty manager on the night.
Steps marked for approval wait for a person. Andiamo SMB is not yet offered to customers; the parts each step leans on, and how far along they are, are listed further down.
Availability
An enquiry is a date before it is anything else, and the reply either offers that date or offers the ones around it. Holding the date asked for, who is asking and what they are planning on a record from the first message keeps the answer out of a mailbox thread that only one person can search. The reply itself is drafted for you and waits until you have read the exact wording. The diary that decides the answer is still yours: bookings here hang off the hours a team member publishes rather than off a room, so the master calendar for the building sits outside the workspace.
Show round
A viewing is a request for a time against whoever is hosting it, taken from the hours that person publishes, and it lands on the record that already holds the date being asked about. Whether they turn up is settled over text: they can confirm or move it by replying to one, and the booking updates from that reply. Automatic replies stay switched off. Keeping those slots in step with the team's calendar is designed and not built, so a show round booked here still has to be read across to whatever the duty team works from.
Hold
Until money changes hands a held date is a courtesy, and the cost of getting that wrong is a date sold twice with no way back. What turns it is a priced offer the booker can read and choose from, a deposit against that offer, and terms they have signed: the hire period, what the fee covers, cancellation, damage. Proposals with options sit in the portal and wait for a person to approve the wording; delivery is still being built. Sending terms for signature is designed and not built, so that step happens off to the side today. Once the deposit clears, the event can become a card the duty team can see, carrying a starter checklist.
Quiet months
Between the deposit and the month of the event the building hears nothing, and the work in that gap is small enough to drop: the balance date, the supplier insurance, the tasting, the point at which somebody should ask whether the plan has changed. Follow-up drafts are prepared and queued for a person to approve or reject, and sending the approved ones is not built yet. Tasks with an owner and a due date on the booking itself are designed and not built, and so are prepared balance reminders for a person to release.
Final details
A month or so out the booking stops being a date and becomes a plan: the head count, the table layout, the ceremony and service timings, the menu and the dietary requirements, which drinks sit on the tab and which are paid for at the bar. Almost all of it arrives later than you asked and most of it changes what is owed. Collecting it as forms the booker fills in through the portal keeps the answers attached to the booking rather than buried in a chain of replies. Recording each change with the price adjustment it triggers, held for approval, is designed and not built, and so is one record per event that every task, document and message links to.
Access
The florist wants the room the evening before, the band needs the doors open at a set hour, the caterer wants the kitchen from the morning, and the building has to be clear by the time written into your terms. None of them work for you and all of them are bound by your windows. From one description of the day the workspace derives a logistics view of setup, the service blocks and breakdown, and alongside it an experience view for the people whose day it is. That generator is exercised in tests; saving the schedules for a business is switched off by default and sending them out is not built, so today it produces something you read and pass on yourself. Assigning your own duty team to an event by role, with their availability visible, is designed and not built.
Close out
The final bill is rarely the quoted one: the bar ran on, a room was held past the hire period, fewer people came than were catered for, something was damaged. The duty manager knows all of it and is the least likely person to sit down and write it up. A spoken handover becomes proposed changes to the record that wait for someone to apply or reject them, and the review screen for those is not built yet. The closing invoice is raised against the same booking, and the booker can pay it by card or see their payment history by signing in with an emailed link. Connecting a payment account and emailing invoices are still being built.
What the work leaves behind
What this leans on
Each card carries its own status. Parts in development are partly built and exercised in testing; planned parts are designed and not built yet. The full list for Andiamo SMB is on the product page.
Client records with contact details, lifecycle stage and tags, with wedding details such as date, venue and party size stored alongside.
Replies to new client inquiries are drafted from incoming email and held until a person reviews and approves the exact message; sending approved replies is still being built.
Clients request a time from a team member's online booking page; calendar sync is still being built.
Clients can confirm or cancel a consultation by replying to a text, and the booking updates; automatic replies stay switched off.
Keep bookings and claimed jobs in step with the team's Google Calendar.
Proposals with options that clients can review and choose from in the portal; sending a proposal waits for a person's approval, and delivery is still being built.
Create invoices and let clients pay them by card through Stripe checkout; connecting a payment account and emailing invoices are still being built.
Send contracts for electronic signature and keep the signed copy with the client; electronic signing is still being built.
When turned on for a business, a paid deposit creates the job card on the team board with a starter checklist; the checklist content and team notifications are still being built.
An agent prepares client follow-up drafts and queues them for a person to approve or reject; sending approved follow-ups is not built yet.
Assignable tasks with owners and due dates on each engagement, beyond the per-job checklists on the board.
Agents prepare payment reminders and appointment confirmations for a person to release.
Clients sign in with an emailed link to see their invoices and payment history, view their contracts and proposals, and fill in forms their provider publishes; online signing is still being built.
Track scope and schedule changes with the approval and price adjustment they trigger.
One record per wedding or job that every task, document and message links to.
From one description of an event day, two schedules are derived: a logistics view of setup, per-person service slots and breakdown for the crew, and an experience view for the person being served. The generator is exercised in tests; saving the schedules for a business is switched off by default, and delivering them is not built yet.
Assign team members to an engagement by role and see their availability.
A drag-and-drop board of jobs with stages and a checklist on each card; letting team members claim open jobs is built but switched off by default.
A spoken update is turned into proposed changes to the client record, which wait for a person to apply or reject them; the review screen is not built yet.
Questions this work asks
What it runs on today
The grid of dates that decides whether an enquiry is a booking, usually kept where only the office can reach it.
Dates asked for, show rounds requested and questions about how many the room takes, arriving in the order they were sent rather than the order they matter.
The spreadsheet of head count, timings, layout, menu and dietary requirements, re-sent to the kitchen and the duty team every time a single line of it changes.
Access windows, parking, what may be fixed to the walls and when the building has to be clear, agreed one supplier at a time and remembered by whoever agreed it.
The takings on the night, recorded apart from the booking that produced them.
Who is on duty, what is set up in which room, and what has to be turned around before the morning.