Decide what Messaging should own inside Everwood, given what already sends messages and what already lets people talk.
The research treated Messaging as a product to build from scratch, with text messages as its eventual channel. The code shows Everwood is not starting from zero: appointment conversations already exist inside Booking, while the automatic messages answer to whichever screen made a change.
Everwood is not starting Messaging from zero. What is missing is consistent ownership of the messages a booking change should produce. Booking, Review Capture, Rebooking and Cancellation Recovery should own why a message exists. Shared Messaging should own delivery, replies and history, and later the channels. Adding SMS before that repeats today's gaps in a second place.
The Build
Nothing shipped from this research. Messaging is the last node on the Everwood roadmap, and it is marked Planned.
The roadmap describes it as dedicated reminders and follow-ups, including text messages and campaign-style sends, built on the confirmations and reminders Booking already sends by email. The product page promises SMS confirmations and post-visit follow-ups.
The research I brought to it was long. It split communication into booking notices, appointment conversations, and a future product for follow-ups and marketing. It compared how other booking platforms price two-way texting, and spent pages on text message registration, consent, quiet hours and opt-outs. Its recommendation was reasonable. Treat Messaging as shared plumbing, start with the web and email, and add SMS later.
Its picture of what Everwood already had was vague. It said some appointment messaging existed and needed hardening, and filled in the rest with guesses. So I read what we run before agreeing with any of it.
The Problem
The first surprise is that Everwood is not starting Messaging from zero. One piece of it, conversations about an appointment, shipped inside Booking this month.
A customer signed in to their Everwood account opens an appointment, on the web or in our mobile app, and writes to the business. The owner sees an unread count next to Appointments in the dashboard, opens that appointment's conversation, and replies. Both sides update live. There is one conversation per appointment. Once the business marks the appointment complete, the conversation stays open for a set number of days, seven unless the business changes it, and then turns read-only. The history stays.
Our roadmap, product catalog and product page still describe Messaging as something to come. The texts, follow-ups and campaigns they describe are still unbuilt, but none of them mention the conversations that already work. The product page also disagrees with itself: the badge says Planned and the first line says Beta.
The second surprise sits in the half everyone assumes is finished, the email Everwood sends without anyone pressing send.
Follow one appointment. A customer books a haircut for Friday at 2 PM and gets a confirmation email. On Wednesday they ask the booking assistant to cancel. The assistant cancels it, emails the customer, and emails the business if it has a notification address set.
Run it again with one change. The customer calls the salon instead, and the owner presses Cancel on the dashboard calendar. The appointment is cancelled. No email goes out.
Run it a third time. The customer calls to move to Saturday, and the owner changes the time in the dashboard. The customer gets nothing. The only email in their inbox still says Friday at 2 PM.
Same appointment, same change, different outcomes. What decides whether the customer hears about it is which screen made the change.
Then the reminder. The reminder code is scheduled for roughly half an hour before the appointment; until a change in May it aimed for a day ahead. Its subject line still says the appointment is tomorrow, and our public description still promises a day-before reminder. Whether that job is currently running in production is unresolved.
The reminder code does get one thing right. It checks that the appointment is still confirmed at the moment it would send, so a cancelled appointment is skipped. There is also a stored switch for turning reminders off. Nothing reads it, and the setting that would change it is disabled.
Assumption vs Reality
I read the roadmap literally. Messaging was planned, so it was unbuilt. Booking notices were live, so they were done. The research agreed on both points and spent its effort on the future product: which channel, what consent, how to price texts. I expected this note to be about where SMS sits in the order.
Both halves of that were off, in opposite directions. Part of what was called unbuilt exists. Part of what was called done has gaps. The conversation work is careful where it matters. Only the customer on the booking and the owning business can read or write a conversation, and sending is limited. Messages arrive live, and if a connection drops, the screen catches up on what it missed. Closing is worked out from the completion time every time someone reads or writes, so there is no separate close date to drift out of sync. What it lacks is what makes a conversation dependable for a business. Nobody is told a message arrived. There is no email and no phone notification. The owner sees the unread count only with the dashboard open. A customer who writes on Tuesday evening about Wednesday morning cannot know whether anyone will read it in time. Only the business owner's login can read and reply. The read tracking was written with staff logins in mind, for when those exist. Our mobile app shows customers the conversation, but the business side of the app has no conversation view. Only a customer signed in to an Everwood account, with the booking linked to that account, can write. Someone who booked as a guest cannot, until they create an account and link the booking. A conversation lives on its appointment, and the customer's CRM record does not show it. A regular's questions across ten visits sit in ten separate places. Closing only follows completion. A cancelled appointment, or one marked no-show, keeps an open conversation with no end date. There is also no way for a business to block a customer. None of that is a reason to rebuild. It is the distance between a feature that exists and one an owner can rely on. Other products talk to customers too, and each carries its own rule. Review Capture sends a review request only for an appointment marked complete, one per appointment, with a link that works once. The business chooses to send it. Rebooking flags when a customer is due back after a completed visit, and clears that flag by itself when the customer books the same service again. It does not send anything itself. The business records the call or email it made. Cancellation Recovery is still an idea. Build Note #017 found its hard part is the offer, not the alert. Inbox connects a business's Gmail and shows the mail. It cannot reply. Read together, the products that decide whether a message is owed are already careful. Review Capture checks the appointment was completed. Rebooking checks whether the customer already came back. The reminder code checks the appointment is still confirmed. The gap is in Booking's own change notices, where the decision to tell the customer was written into the screens that change an appointment, and among today's business-facing ways to cancel or move one, only the booking assistant got it. Build Note #018 found we record that an appointment was cancelled but not when or by whom. That matters here too. A notice cannot say who cancelled when nothing recorded it. No part of Everwood sends a text message today. There is no SMS work to extend.
The Fix
What changed is the design, not the code. This is the direction I would build toward.
Separate who decides from who delivers. Every message has one product that owns the reason it exists. Messaging owns getting it there and keeping a record of it.
Here is how I would assign the messages we send now or plan to.
Booking confirmations, change notices, cancellation notices and reminders belong to Booking. They follow the appointment, not the screen. Whatever changes an appointment, whether the assistant, the dashboard, the mobile app or a future cancel button for customers, the change itself produces the notice. And the notice is written from the appointment as it stands when the email goes out, so a moved appointment is not announced with its old time.
A customer's question about an appointment, and the reply, belong to that appointment's conversation. This is the part of Messaging we already have. Messaging owns the thread, the unread count, telling the other side that something is waiting, and the history.
A review request belongs to Review Capture. It already owns the rule. Messaging would carry the request and record that it went out.
A rebooking reminder belongs to Rebooking. If Everwood ever sends one automatically, Rebooking checks at the moment of sending that the customer has not already booked, the same check that clears the flag today.
A waitlist offer belongs to Cancellation Recovery, which has to confirm the opening is still there when someone claims it, not when the email was written.
Preparation instructions, like what to avoid before a facial, would belong to the service. We store nothing like that today, so it waits.
A marketing campaign does not belong to Messaging at all, for now. Consent, frequency and audience work differently from a reminder, and a customer who opts out of promotions must never lose their appointment notices.
So should Messaging be a standalone product? Not yet, and not in the shape the roadmap describes. The conversation already lives inside Booking, next to the appointment, which is where an owner looks for it. What should become Messaging is the shared layer underneath: one way to send, one record of what was sent and said, and one way to tell a person a reply is waiting. The products that decide keep deciding.
Keep AI out of the decision. Later, AI could draft a reply for the owner to edit, summarize a long conversation before a visit, or label a message as running late or wanting a different time. It would not cancel, move an appointment, promise an opening, quote a policy the business never wrote, or send a booking notice by itself. The booking assistant can already cancel and reschedule, but only for a customer it has verified, and through the same booking rules as everything else. A conversation between a customer and a person is different. An AI reading along should not act on it.
Hold channels back. SMS is a delivery choice, and it comes later. Added now, it would copy each screen's gaps into a second template and bring registration, consent and opt-out work along with it. The order is: make ownership of these messages correct, make conversations reliably tell people a message is waiting, and only then consider another way to deliver them.
Find where a message is decided before choosing how it travels. In Everwood the conversation feature was new, and its rules sat in one place. The booking notices were older, and their rules were spread across every screen that could change an appointment. The research asked which channel to add next. The code asked a smaller question first: when an appointment changes, who is responsible for telling the customer? Today the answer is whoever built that screen.
For a business owner, here is where things stand. If your customers have Everwood accounts, they can already message you about an appointment, and you can reply from that appointment in your dashboard. You will not get an email when they write. Keep an eye on the unread count next to Appointments. If you cancel or move an appointment from the dashboard, Everwood does not tell the customer. Let them know yourself for now. The reminder is set up to go out roughly half an hour before the visit, even though its subject line says tomorrow. I have not confirmed that it is currently running. Text messages are not next. Getting these notices right comes first, because a text sent under the wrong rules is the same mistake, delivered faster.
Builder Notes
A research pass on Messaging that became an audit of the conversation feature and booking notices we already run. Nothing was built.
Technical Note 1
Built, inside Booking: one conversation per appointment between a signed-in customer and the business owner, on the customer web account, in the customer mobile app, and in the business dashboard on the web.
Technical Note 2
Built: live updates on both sides, catch-up after a dropped connection, unread counts per reader, and an unread badge in the dashboard menu.
Technical Note 3
Built: a conversation turns read-only a set number of days after the appointment is marked complete, seven by default, and keeps its history. Cancelled and no-show appointments never start that clock.
Technical Note 4
Built: access limited to the customer on the booking and the owning business, and limits on sending.
Technical Note 5
Missing from conversations: any email or phone notification of a new message, staff access, a business view in the mobile app, customer-level history in CRM, guest access, and a way to block a customer.
Technical Note 6
Built, booking notices: confirmations when a booking is made through the widget, the assistant or the dashboard (the quick booking form emails the customer only when they ask for it), cancellation and change notices only when the booking assistant makes the change, and reminder code aimed at roughly half an hour before, for confirmed appointments only.
Technical Note 7
Found: cancelling or moving an appointment from the dashboard sends the customer nothing. A moved appointment does not get a fresh reminder if one already went out.
Technical Note 8
Found: the reminder code moved from a day ahead to roughly half an hour before in May, while its subject line and public copy still say day-before. Whether it currently runs in production is unresolved.
Technical Note 9
Found: a stored switch to turn reminders off is read by nothing, and the setting that would change it is disabled.
Technical Note 10
Built elsewhere: Review Capture sends one single-use request per completed appointment when the business chooses. Rebooking tracks who is due back and clears the flag on its own when they book, but sends nothing. Inbox reads a connected Gmail account and cannot reply.
Technical Note 11
Not built: SMS in any form, waitlist offers, preparation instructions, and marketing sends.
Technical Note 12
Not checked: how many businesses and customers use conversations in production, and whether reminders are going out on schedule there.
Technical Note 13
Reported by the research and not verified: plan limits and prices for two-way texting on other platforms, state-by-state quiet hours, and a security advisory about text message callbacks. The figures are left out because no sources came with them.
Technical Note 14
Hypotheses of mine: owners miss customer messages that arrive while the dashboard is closed; customers use conversations mostly to ask for changes, because their account page tells them to contact the business for that; one notice per booking change removes the mismatch between screens. Production usage and a few weeks of owner feedback would confirm or kill them.
Before / After
- Messaging is planned, so none of it exists
- Booking notices are live, so they are done
- The next question is which channel to add
- Messaging should own every message
- Text messages would make reminders better
- Appointment conversations already ship inside Booking, and the rest of Messaging is still planned
- Whether a customer hears about a change depends on the screen that made it
- The next question is who owns each message
- Products own the reason, and Messaging owns delivery and the record
- A text message delivers whatever the rules produce, mistakes included
What I'd Do Differently
I would have given appointment changes one place to announce themselves before building a second way to make them.
The booking assistant came first and got its notices. The dashboard's cancel button and time editing came from different work. Each one changed the appointment correctly. Telling the customer was never written down as part of changing an appointment, so nothing checked for it.
I would also have updated the roadmap in the same change that shipped conversations. The public page still describes Messaging as something to come while customers can already use part of it. That is the same drift as the reminder subject line, one level up.