Decide what Analytics should help an appointment business owner decide, and which numbers Everwood can trust enough to show.
The research framed analytics as an interpretation problem, and I assumed our numbers were fine. Our beta shows the gap is further down: what gets counted, over which dates, and against what.
An analytics number is only worth showing an owner when we can say exactly what it counted and what it was divided by. For Everwood, that means a few questions with inputs we can defend, and a plain statement of the questions we cannot answer yet.
The Build
Nothing shipped from this research. Analytics is listed as a Beta product, not generally released, and this note is about what it should become.
The roadmap sentence for Analytics is short. Bookings, customers and reviews turned into answers: which services fill the calendar, which days run empty, who the regulars are. Built for owners, not analysts.
The research was long and sure of itself. Its main argument was that booking software buries owners in charts and leaves them to work out what the charts mean. It recommended skipping that stage. Watch for changes, describe each one in a sentence, and offer an action underneath. Tuesday afternoons have run emptier than the rest of the week for a month; want to adjust hours? Then it listed the metrics behind those sentences: staff utilization, revenue per available hour, rebooking rate, new versus returning customers, lifetime value. Its first version was an end-of-day cash report, basic utilization, new versus returning customers, and three rule-based insights a week.
Before ranking any of that, I went back through what we already run.
The Problem
There is already an Analytics page in the dashboard. It has no link in the menu, it is switched on by default only for our top plan, and without it the page shows an add-on badge.
The page has a range picker for the last 7, 30 or 90 days. Under it sits a card for each appointment status, labelled with the system's raw status name, plus a count of assistant conversations. Then a bar chart of appointments per day. Then two tables, Top Services and Top Workers, each the top five by number of bookings.
That is a reasonable first screen. The problem shows up when you follow one booking through it.
A customer books on September 1 for a haircut on October 3, then cancels. On September 14, in the 30-day view, that booking appears in the cancelled card. It also counts toward the haircut in Top Services and toward the stylist in Top Workers. It does not appear on the chart, because the chart stops at today. On October 20, in the same 30-day view, the booking has vanished from everything. The range does not select appointments by when they happen. It selects them by when the booking was created.
That one choice bends the chart the roadmap cares about most. Pick the last 7 days and every appointment that happened this week but was booked before the range started is missing. A busy week of regulars who book ahead looks like a quiet week.
The days are also cut in the wrong place. The chart splits days at midnight UTC. Every business has its own time zone stored, and the page does not use it. For a salon in California, a 6 PM appointment lands on the next day's bar.
Then the rankings. Top Services and Top Workers count every booking, whatever happened to it. A service people book and then cancel ranks as high as one they book and show up for. A booking with two services counts as two bookings. An appointment with no staff member assigned, which is what a no-preference booking creates, is left out of Top Workers without a note.
Everything else we store goes unused. Every appointment has a start and end time. Services have a length and an optional listed price. Staff have weekly working hours. None of it reaches the page. There is nothing about customers, nothing about reviews, and nothing about how full the calendar was.
The one automated test that calls the page's data checks that access switches on and off with the account setting, and that the response has the right shape. No test checks what gets counted.
Assumption vs Reality
The research had a clear story. Owners do not lack data, they lack time to interpret it. Our beta page was a dashboard, dashboards were the problem, and the obvious move was to add the explanation layer. I assumed the numbers underneath were fine.
The numbers underneath were the problem. An explanation engine reads whatever number it is handed. Tuesday is your emptiest day, computed from UTC days of bookings made in the last week, is a confident sentence about the wrong thing. Adding AI would make it read better without making it more true. So I went back to the three questions in the roadmap sentence and checked each one against what Everwood records. Which services fill the calendar. This one we can answer now. It needs the date range to follow the appointment date, cancelled and no-show bookings kept out, and services weighed by the time their appointments take, because every appointment stores its start and end. My guess is that ranking by hours booked instead of bookings made will reorder the list for any business with a mix of short and long services. That is a hypothesis. Computing both from real calendars would settle it. Which days run empty. Empty needs a denominator: the time that could have been booked. We store weekly opening hours and each staff member's weekly working hours, and a day can be split around a regular break. We store blocked days for the business and for each staff member, but a block is always a whole day. Anything in between has nowhere to go: a dentist appointment at 2, or leaving early one Friday. And as Build Note #019 found in the availability code, a booking with no staff preference reserves nobody's time. Each of those gaps bends the denominator, and not always in the same direction. A fullness percentage built on it would look exact, and I could not tell an owner what it was divided by. We cannot defend that number yet. Who the regulars are. This is the weakest of the three. Customer records are matched by phone number first, and by email only when no phone was given. A booking with neither creates no customer at all. Nothing in the data guarantees one record per person. Someone who gives only a phone number one time and only an email the next becomes two customers. Bookings made before customer records existed stay unlinked until a backfill runs, and I have not checked whether it has run in production. Any repeat-customer number today would undercount regulars by an amount I cannot state. The research's own first version needed things we do not have. Everwood does not collect payments from customers, so there is no till to balance when the doors close. Services have a listed price, but that is not what anyone paid. And Build Note #018 already found that we record a cancellation but not when it happened, so an early cancellation and a late one look identical. The code also had things the research did not look for. Completed means someone said so. An appointment is never marked complete just because its time has passed. Someone at the business has to mark it. That is the right rule, and review requests depend on it: they only go to appointments marked complete. It also means a completed count is well defined but not necessarily complete. It measures visits and how consistently staff mark them at the same time, and a finished week can still change days later when someone catches up. No-shows are recorded as their own outcome, separate from cancellations. They depend on someone marking them in the same way. Bookings made through the assistant record which conversation they came from. So we could say how many assistant conversations turned into a booking. The current page shows only the first half of that. And businesses with our Google review management add-on already see their average rating, how many reviews are awaiting a response, and their response rate. It lives on the reviews page, not in Analytics.
The Fix
What changed is the design, not the code. This is the direction I would build toward.
Fix what gets counted before adding anything. Select appointments by when they happen. Split days at the business's own midnight. Keep cancelled and no-show bookings out of the rankings and show them on their own. Replace raw status names with plain words. None of this needs data we do not already store.
Say when a period is unfinished. The current week is in progress, and a chart that ends today should say so. Future days show what is booked so far, not how the day went. Compare a finished week with a finished week. Because staff can mark appointments complete or no-show later, a past week also needs a point after which we treat it as settled. How long that should be depends on how late the marks arrive, which we have not measured.
Answer a few questions, not a catalog. Each question gets one sentence, one number or small chart, and the inputs it used. These are the ones I think the data can hold up today.
What is already booked for the next two weeks? Booked hours per day, on the business's own dates, counting appointments that are not cancelled. Appointments with nobody assigned count toward the day and show as unassigned, not handed to a staff member. There is no percentage and no fullness score, because the available time underneath is not complete. The card says so and names what is missing: staff with no weekly hours set, and part-day time off, which cannot be recorded. Booked against available can come back as its own question once that time off can be recorded.
Which services take up the calendar? Ranked by appointment hours over finished weeks, not bookings made.
Where do appointments fall through? Cancellations and no-shows, compared with this business's own recent weeks, never with an industry figure.
What changed? One or two sentences comparing the last finished week with the ones before it.
Put the data gaps next to the number. A line saying how many of this month's bookings have no customer attached, or which staff have no hours set on a given day, is part of the answer. My bet is that owners trust a number more when they can see its limits, not less. That is a hypothesis for owner conversations to confirm.
Keep AI away from the numbers. Every number comes from ordinary code with a written definition and a test. The explanation starts as fixed sentences filled in with those numbers. If AI is used later, it rephrases numbers it is handed and never produces one. Any action offered underneath links to something Everwood can already change, like a staff member's hours or a blocked day.
Hold the rest back, and say so. No utilization or fullness percentages, for the business or per staff member. No repeat-customer or rebooking rates until customer linking is complete and we can show how complete it is. No revenue, lifetime value or cash reports, because Everwood does not collect customer payments. No industry benchmarks, forecasting, custom report builder, or chat over your data. The research reports that other platforms already offer AI summaries and ask-a-question reports. I am not saying they are wrong to. For us, each depends on inputs we have just found are unreliable.
A count is not an answer until you can say what was counted. The beta page was not careless. Every number on it is a correct count of something. The trouble is that the something is not what the label promises, and no explanation written on top can close that gap. The research framed analytics as an interpretation problem. For Everwood it is a definition problem first. Once the definitions are right, a sentence explaining a number is easy. Before that, a good sentence only hides the problem better.
For an owner, here is where things stand. Analytics is in beta and is not generally released. If you have seen the Analytics page, read Top Services as services booked during the dates you picked, including cancelled ones. Read the chart as bookings made in that range, placed on the day of the appointment in UTC. Neither is wrong. Neither is what the label suggests. Two habits will make any future report about your business more accurate. Keep each staff member's working hours current, including days off. Mark appointments complete or no-show when they happen. Everwood never guesses that an appointment took place, and I think that is the right rule. If there is one question you open a report to answer, I would like to hear it. That decides which question Analytics answers first.
Builder Notes
A research pass on analytics that became an audit of the Analytics beta page we already have. Nothing was built.
Technical Note 1
Built and in beta: a single Analytics page with a 7, 30 or 90 day range, a card per appointment status, a count of assistant conversations, appointments per day, and the top five services and staff by bookings. It has no link in the dashboard menu and is on by default only for our top plan.
Technical Note 2
Built, and the main finding: the range selects appointments by when they were booked, not when they happen. Future appointments created within the range are counted in the cards and tables but never charted.
Technical Note 3
Built: days are split at midnight UTC. Each business's time zone is stored and not used here.
Technical Note 4
Built: Top Services and Top Workers count every booking regardless of outcome. A booking with two services counts as two bookings, and appointments with no staff member assigned are left out of Top Workers.
Technical Note 5
Built and unused by Analytics: appointment start and end times, service length, optional listed price, weekly business and staff hours that can be split around a regular break, and whole-day blocks for the business and for each staff member.
Technical Note 6
Built: an appointment is only marked complete when someone marks it. No-shows are recorded separately from cancellations and are marked the same way, so both are well defined but can be incomplete.
Technical Note 7
Built: bookings made through the assistant record the conversation they came from.
Technical Note 8
Built elsewhere: businesses with Google review management see their average rating, reviews awaiting a response, and response rate on the reviews page.
Technical Note 9
Missing: part-day time off that is not a weekly pattern, a record of when a cancellation happened, and customer payments.
Technical Note 10
Not recommended yet: any fullness or utilization percentage. The proposed next-two-weeks view shows booked hours only, with the missing inputs named.
Technical Note 11
Missing: a guarantee of one customer record per person. Matching is by phone first and by email only without a phone, and older bookings stay unlinked until a backfill runs. Whether that backfill has run in production is unchecked.
Technical Note 12
Missing: any test of what the Analytics page counts. The existing test covers access and response shape.
Technical Note 13
Reported by the research and not verified: owners export reports to spreadsheets, stop trusting totals that do not match their bank, and tire of dashboards full of widgets. Some platforms add AI summaries or ask-a-question reporting on top of dashboards. Platform names are left out because no sources came with them.
Technical Note 14
Cut from the research and kept in the ledger: every utilization, rebooking and percentage example, the revenue per hour and lifetime value formulas, retail, payroll and commission reporting, the cash report, the competitor table, and the success-metric plan.
Technical Note 15
Hypotheses of mine: owners bring a handful of recurring questions rather than browsing charts, ranking by hours booked reorders top services for mixed menus, and showing data gaps next to a number raises trust. Owner conversations and a recompute on real calendars would confirm or kill them.
Before / After
- Analytics needs an explanation layer on top of the dashboard
- The date range is about when appointments happen
- Top Services shows what fills the calendar
- Utilization and repeat customers are the next metrics to add
- AI is the interesting part
- Analytics needs definitions first, because an explanation of a miscounted number is still wrong
- The range follows booking dates today, and it should follow appointment dates
- Top Services shows bookings made, including cancelled ones
- Both rest on inputs we only half have, so they wait and say why
- AI may phrase a sentence, but ordinary code produces every number
What I'd Do Differently
I would have written one sentence defining each number before building its card.
Top Services means services from appointments that took place in the selected dates and were not cancelled. Writing that sentence forces the decisions the page skipped: which date, which outcomes, which time zone. It also makes the test obvious. One cancelled booking, one future booking, one evening appointment, and a check that each lands where the sentence says.
Like the last few notes, this research was written without a plain description of what we already run. The page it would have replaced was small enough to read line by line in an afternoon, and that reading changed the recommendation more than the whole competitor survey did.