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 · Wedding and event planners
One enquiry, a scope drawn on paper, then months as the single point between a couple and every supplier, on a timeline that keeps moving.
How the work runs
Written for Wedding and event planners and coordinators, from full-service planning through to coordination of the day itself, working alone or with associates brought in for one event.
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.
Fit call
A planning enquiry arrives with a date, a venue that may or may not be held, and a couple who want to know what you would actually do for them. That conversation decides whether the work is full planning, partial planning or taking a finished plan over for the final stretch, and the answer belongs on the record from the first message rather than in a mailbox someone searches later. Replies to new enquiries are drafted from the incoming email and held until a person has approved the exact wording; sending the approved reply is still being built.
Scope
One is booking every supplier from nothing; the other is taking over a plan already made and running the day it happens. The proposal is where that line gets drawn, and the fee follows the line rather than the guest list. Clients review the options and choose in the portal; sending a proposal waits for a person to approve it, and delivery is still being built. The retainer is invoiced against the same record and payable by card, though connecting a payment account and emailing invoices are also in development. Sending contracts for signature is planned, so that step sits outside the workspace today.
Suppliers
A venue, a caterer, a florist, a band, a photographer: none of them on your payroll, all of them answering to you on the day. Each thread has its own state, from enquired through quoted and held to booked and paid, and holding them as cards on a board is what keeps a question about the caterer from becoming a search through an inbox. The board and its per-card checklists are in development. Assignable tasks with owners and due dates on each wedding are planned, and so is one record per wedding that every document and message links to, so today the board and the client record are still two places.
Run of show
When the styling team arrives, when the first look happens, when the band can load in, when the cake is cut: each of those moves at least once, and the walkthrough at the venue moves several at a time. From one description of the day the workspace derives a logistics view of setup, service slots and breakdown alongside an experience view for the couple, and the same input always produces the same schedule. That generator is exercised in tests; saving the schedules for a business is switched off by default, and delivering them to suppliers is not built yet. Recording a change with the schedule and price adjustment it triggers, held for approval, is planned.
Between meetings
They ask at night, at the weekend, in the middle of your other wedding, and the answer usually already exists somewhere you wrote it down. Clients sign in with an emailed link to see their invoices, their payment history, their proposals and the forms you publish, which takes the documents out of the reply queue; that portal is in development. Messaging inside the portal with the thread attached to the wedding is planned. Follow-up drafts are prepared and queued for a person to approve or reject, and sending the approved ones is not built yet, so those drafts stop at the review step.
On the floor
Telling the band when to start, the caterer when to clear, the photographer where the family has gone. Whoever is running a part of the day needs the schedule in their hand, and an associate covering a room for you needs it more than you do. The crew schedule comes from the same description of the day as the couple's version, so the two cannot drift apart. Assigning people to a wedding by role, with their availability visible, is planned, and getting the schedule into their hands is not built yet.
Settling up
Overtime agreed standing in a car park, a supplier who bills you later, a balance still outstanding, and the note to yourself about which caterer to recommend and which to stop calling. A spoken update after the day becomes proposed changes to the record that wait for a person to apply or reject them; the review screen for those is not built yet. Invoices and card payments sit on the same record as the wedding, and agents preparing payment reminders for a person to release are planned.
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.
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.
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.
Assignable tasks with owners and due dates on each engagement, beyond the per-job checklists on the board.
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.
Track scope and schedule changes with the approval and price adjustment they trigger.
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.
Message clients inside the portal with the thread attached to their engagement.
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.
Assign team members to an engagement by role and see their availability.
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.
Agents prepare payment reminders and appointment confirmations for a person to release.
Questions this work asks
What it runs on today
The run of show, rebuilt and sent round again each time a supplier moves, with each recipient holding a different version of it.
Every supplier enquiry, quote and confirmation, findable by whoever filed it and by nobody covering for them.
Venue plans, supplier agreements and the seating chart, kept apart from the record of the wedding they belong to.
The address, the parking, the start time and the change made that morning, read by whoever happens to look.
The same list of what happens when, copied again and pruned by hand for a couple whose day looks nothing like the last one.
The agreement and the retainer, recorded away from the plan the couple is paying you to run.