One dashboard for ads, sales and cash: what to agree first

A few weeks after a client's dashboard went live, we read how their team was using it. Every number on the page was calculated correctly. The page was still wrong in three ways that nothing on it showed. A sale with no booked call behind it had nowhere to land, so it was missing. The sales team had started booking calls on a third calendar that the dashboard did not read. And a stack of finished calls had no outcome filed, so they sat in no rate at all.

We wrote in the review that none of it was a fault in the build. All three were gaps in what we had told the team to do. The page looked equally finished with the gaps and without them, and that is the problem this post is about.

What a wrong Monday number costs

A Monday review is where a team decides where the money goes that week: which ad set keeps its budget, which setter gets coached, whether a closer needs better leads. It runs on one page, or on three tabs somebody pastes into one.

If the page cannot say how complete it is, the meeting does one of two things. It argues about the number, or it believes the number. Either way a decision gets made on a figure nobody could check, and the next Monday starts with a spreadsheet beside the dashboard.

What one dashboard has to join

"One dashboard for marketing, sales and payments" is a join across three systems that keep different clocks and different keys. The ad platform dates a lead by the ad. The booking tool dates it by the slot. The payment processor dates it by the payment. Each tool also has its own idea of what "today" means.

Stripe's report options say a financial report can be viewed in the account's time zone or in UTC, and that the choice changes both which transactions the date range picks up and how the dates in the report read. The same page says that for its balance and payout reports a day's data is normally available by noon the following day, so a sale made last night may not be in yesterday's report when the meeting starts (Stripe, report configuration).

Google Analytics has the same trap. Its help page on comparing reports with a BigQuery export says that if the two are set to different time zones, you might be comparing data from different time periods and not realize it. It adds that the export is based on device ID, so a property set to another reporting identity will not match (Google Analytics Help).

Joining the sources is the next place a number moves. Looker Studio, which Google's own documentation now calls Data Studio, blends sources on a join key. By default it keeps every record from the leftmost source and only the matched records from the sources to its right, which is a left outer join (Google, join key). Put bookings on the left and payments on the right, and a payment that matches no booking does not appear in the blend. Put payments on the left and the unmatched booking shows as empty cells instead. Neither is a bug. Each is a choice, and it is made by whoever drags the sources in.

Every tool is correct by its own rule. The dashboard inherits whichever rule nobody wrote down.

Six things to agree before the first chart

1. What a number counts: people or calls. On our client pages, results count people and logging counts calls. A person who books three times counts once in sales, cash and show rate, and three times in the list of calls that still need an outcome. The trade is that the show rate answers "did this person ever turn up" and cannot answer "how many booked slots got used". Every label on the page says which count it is. The other counting rules are in the show rate post.

2. Which day a number belongs to. A sale counts on the day it closed. Calls, shows and no-shows count on the day of the call. Cash counts on the day the money arrived. Days and totals follow one business time zone, so everyone sees the same figures, and clock times display in the viewer's own zone.

3. The key between a booking and a payment. One field, written down, that joins them, and the fallbacks below it for when the field is empty. The longer version of this is in the trail post. Check which side of your blend each source sits on, and count the rows that fall out.

4. Who gets the credit. One setter and one source per person, chosen by an order the page prints. "No setter" is a value on the page. A blank is a gap somebody will fill with a guess. The credit rules for setters are in the setter post.

5. Which money word. Cash collected is what arrived. Contract value is what was agreed. They get separate cards with separate names, so a payment plan never reads as a shortfall.

6. How much is missing. The first line on the page counts what is not in it: calls with no outcome, bookings with no setter or source, and the time the data is current to. We show the time of the oldest feed, not the time the page was loaded. On our client pages an amber box under the filters says how many calls still need an outcome, and the guide tells the team that when the count is high they should not fully trust the rest of the page.

One screen per question

A Monday review asks the same questions in the same order, so the page follows them. How much came in. Where did it come from. Who is doing the work. Where do people drop out. What is unfinished.

Each question gets its own block of cards. Every card carries an "i" that says what the number means, how it is worked out with the live figures, and the catch. Tap a number and the people or calls behind it open as rows. That rule ends more arguments than any definition does, because five records on a screen settle what a debate over a total cannot.

Small samples are muted. A rate whose denominator is under ten shows as a fraction such as "3/3", so a tiny sample never looks like a star.

A worked example

This is a made-up example. It names no client, and it shows what happens when a page does not say which day it counts on.

Four sales touch last week. Ask the page "how many sales last week" and it can answer three or two, depending on a rule.

By call day the page says three, because three of last week's calls ended in a sale. By close day it says two, because only two sales closed last week. Both answers are right. A page that does not say which day it uses will be read as wrong by whoever expected the other.

Money questions want the close day, and cash wants the day the payment landed. A show rate wants the day of the call. Our client pages use both and say so under each number. One consequence is that a last-week view can read zero deals and no cash in a week with plenty of calls, because the sales landed on other days. The rule is working. A reader who does not know the rule sees a broken page.

Now add the sixth item. Two of last week's calls have no outcome filed. The page opens with "2 calls to log", because either of them could be a sale that moves the answer to three or four. Without that line the page shows its two answers with the same confidence whether the week is complete or not.

What to do this week

1. Write the unit and the day under every number you review: "people, by close day", "calls, by call day". One short line each.
2. Pick one business time zone for days and totals. Then check that your payment tool's report zone and your analytics property's zone match it.
3. Name the field that joins a booking to a payment. Look at which source sits on the left of any blend, and count the records that do not appear.
4. Put a completeness line at the top: calls with no outcome, bookings with no source or setter, and the time your oldest feed is current to.
5. Make every number open to the rows behind it, or keep a CSV of those rows beside the page.
6. Decide where sales calls get booked, and count anything booked somewhere else.

If you want to see which of these you can answer today, the Revenue Blind-Spot Score takes about a minute.

The page we read that day had nothing on it that would have told you a calendar was missing. Today it opens with a count of what is not in it, and the definition sits one tap under each number.