Diego's review and location comparison

Step 1: Share with Diego

Email Diego with a description of what you have built. Describe the dashboard: the primary KPI (retention), the location comparison, the filters, the accessibility features. Include enough detail that he can picture it before seeing it.

Diego responds fast. He loves the at-a-glance view. Four locations in one screen -- exactly what he asked for.

But he immediately notices something. Escazu's revenue per member is noticeably higher than the other three locations. He knows why: Escazu charges more. The comparison as it stands makes Escazu look like the best performer when it is really just the most expensive.

"Wait, Escazu is way ahead on revenue per member. That can't be right -- they charge more. Can we adjust for that?"

Step 2: Address the location comparison

You already discovered the Escazu pricing difference in Unit 2. Now Diego is seeing it in the dashboard and asking for a fix.

Two approaches:

1. Normalize by pricing tier. Divide each location's revenue per member by its standard pricing, creating an index where 1.0 means members are paying exactly the standard rate. This removes the pricing difference entirely.

2. Add a pricing-tier indicator. Keep the raw numbers but add a label or annotation showing each location's pricing tier. Escazu shows its higher number but the context is visible.

Both serve Diego's question differently. The first makes comparison easy at the cost of hiding the actual numbers. The second preserves the real numbers at the cost of requiring the reader to do mental adjustment.

This is a genuine design choice. Pick one, implement it, and document why you chose it over the alternative. The documentation is for the next analyst who inherits this dashboard and wonders why revenue per member looks different from the raw data.

Step 3: Handle the class-type request

Diego's enthusiasm leads to a follow-up: "Can we add a section for my classes? I want to know which class types have the best retention -- like, do yoga members stay longer than HIIT members?"

This is a reasonable request. It is also a new analytical dimension -- retention by class type was not in the original requirements. Assess whether it fits:

• Do you have the data? Yes -- class bookings include class type and member ID.
• Does it require a new metric definition? Yes -- class-type retention needs its own definition and test.
• Does it fit on the existing dashboard without breaking the hierarchy? That depends on the design.

If it is straightforward, incorporate it. If it would take the dashboard past what can be read in one screen or require significant new analysis, propose it as a follow-up. Either response is professional. What matters is that you assess the scope before agreeing.

Step 4: Defer the forecasting request

Diego also says: "My investors asked if we can forecast next quarter's revenue."

Revenue forecasting is a different analytical domain. It requires time-series modeling, seasonality analysis, and assumption documentation that go well beyond the current project. The professional response: acknowledge the value, explain what would be needed, and scope it as a separate project.

Diego accepts this easily. He appreciates when someone slows him down on important decisions.

Step 5: Update the dashboard

Implement whatever changes you agreed to. If you adjusted the location comparison, update those panels. If you added class-type retention, add those panels following the same design principles: governed metrics, accessible encoding, durable design.

For every change, confirm the SQL uses your governed metric definitions. Adding a new analytical dimension (class-type retention) requires extending the governance -- write the definition and test before building the panel.

Run all metric validation tests after the updates. If any test flags, investigate.