Sales & Revenue Performance Analytics Questions

Direct answer

Match the chart to the question the executive is asking. 24 months of MRR (monthly recurring revenue, the subscription revenue billed per month) is a trend question, so use a single line with a few annotated events. The current pipeline by stage is a "how much sits where" question, so use horizontal bars ordered by stage. A funnel is a "where do we lose people" question, so use bars of each stage with the conversion rate between stages labelled. Avoid anything that makes the reader decode shapes, colours or two axes instead of reading a number.

Choices and what to avoid

MRR chart in detail

• Trend versus composition: a line answers "is it growing, and how fast?" A movement chart answers "why?" Putting both on one chart makes neither readable, so show the line large and the movement chart beneath it on the same time axis.
• Color: one muted colour for the MRR line, one accent colour for the annotated points. For movement bars use a colour-blind-safe pair (blue for additions, orange for losses) and rely on the zero line as the cue as well as colour.
• Annotation: label three or four real events directly on the line (for example, a price change month), and the latest value and growth in the title. The reader should not have to hunt for the story.
• Axis: a line may start above zero because it shows rate of change; bar charts must start at zero.

Example headline: MRR grew from $400k to $640k over 24 months. Over 23 monthly intervals that is (640 / 400)^(1/23) - 1, about 2.1% compound monthly growth. Compound growth means the same percentage rate applied each month to the previous month's value. 24 monthly readings contain 23 gaps between them, hence the exponent 1/23 (the 23rd root of the total growth factor 1.6). Check: 400 x 1.0207^23 is about 640. The title states "MRR up 60% in 24 months" and the line shows whether growth was steady or came in steps.

Pipeline by stage example

Stages run in the order a deal travels through the sales process: Qualified (confirmed worth pursuing), Demo, Proposal, Negotiation.

Bars sorted in stage order, not by size, because the order carries meaning. If one stage holds a disproportionate share, annotate it rather than adding a second chart.

Funnel example

Leads 10,000, marketing-qualified leads (MQL, leads marketing judges worth passing on) 2,000, sales-qualified leads (SQL, accepted by sales as real prospects) 800, opportunities 300, won 90.

Executives get the end-to-end figure in the title and the step with the largest drop highlighted. Conversions should use the same cohort of leads, not stage counts from different time windows.

Other metric types on the same page

Pitfalls

• Choosing the chart before knowing the decision.
• Letting a tool default pick the palette: a rainbow suggests categories that do not exist.
• Truncated bars that exaggerate small differences.
• Hiding the denominator (the number a percentage is out of): always say what the percentages are out of, for example conversion of 2,000 MQLs, not of all leads.

Direct answer

ARPA (average revenue per account) is ARR (annual recurring revenue) divided by the number of accounts: 2,400,000 / 200 = $12,000 per account per year, or $1,000 per month. ACV (annual contract value) is the average annualised value of a contract. With one contract per customer, all recurring, it also comes out at $12,000, but it can legitimately differ, and both averages move when the mix of enterprise and small-business accounts changes without any single customer changing what they pay.

Computing both

ARPA = ARR / accounts = 2,400,000 / 200 = 12,000 USD per year (1,000 USD per month)
ACV  = annualised contract value / contracts

State the basis every time: ARPA is per account and often quoted per month, ACV is per contract and quoted per year. Mixing the two bases is the most common error here.

How ACV and ARPA can legitimately differ

Reading them as the mix shifts

An average hides its mix. Illustrate with 200 accounts that are 8 enterprise accounts at $150,000 and 192 small-business accounts at $6,250:

• Enterprise ARR: 8 x 150,000 = 1,200,000. Small-business ARR: 192 x 6,250 = 1,200,000. Total 2,400,000 and ARPA 12,000.
• Half of ARR comes from 4% of accounts (8 of 200). The typical (median) account pays $6,250, about half the average. The "average customer" of $12,000 does not exist.

Now add 40 small-business accounts and no enterprise accounts:

• ARR becomes 2,400,000 + 40 x 6,250 = 2,650,000 (up 10.4%) across 240 accounts.
• ARPA becomes 2,650,000 / 240 = about $11,042, down 8.0%.

ARR grew and ARPA fell, with no price change and no customer paying less. The reverse also holds: adding one $150,000 enterprise account instead gives 2,550,000 / 201 = about $12,687, up 5.7%.

What I would do with them

• Segment before concluding. Report ARPA and ACV per segment (enterprise, mid-market, small business), plus the segment mix as its own series. A falling blended ARPA with stable segment ARPA means mix shift, which may be intended (a self-serve push), not a pricing problem.
• Use ACV for sales-motion questions: a high ACV can fund a field sales team and long cycles; a low one needs self-serve or low-touch acquisition. Use ARPA for monetisation questions: is the product earning more per account?
• Show a distribution or the median alongside the mean, because a handful of large accounts drag the mean away from the typical customer.
• Compare like with like over time: new-deal ACV this quarter against new-deal ACV last quarter, and ARPA of a cohort (a group of customers who started in the same period) against the same cohort later.

Pitfalls

• Quoting ARPA monthly and ACV annually in the same sentence.
• Concluding "pricing power improved" from a rising blended ARPA when one enterprise deal landed.
• Using ACV without removing multi-year totals or one-time fees, which inflates it.
• Treating the average as a target: setting a goal of "$12,000 per account" while the base is a barbell of two very different groups.

Direct answer

A drop of ten points in every region at once points to a cause shared by all regions, so I would suspect measurement or a global change (scoring rules, lead sources, routing, definitions) before regional sales or marketing performance. My order: (1) confirm the drop is real and not an artefact of how it is calculated, (2) find the date it started, (3) audit what changed on or near that date, (4) split by lead mix and score to see whether the quality of what is entering changed, (5) check sales capacity and speed of follow-up, (6) only then consider market or seasonality.

Terms: an MQL (marketing-qualified lead) is a lead that crossed marketing's scoring threshold. An SQL (sales-qualified lead) is an MQL that sales accepted as worth pursuing. MQL-to-SQL conversion is the share of MQLs that become SQLs.

Step by step, with what each result tells you

1. Is it real? Recompute from raw rows using a fixed window per MQL cohort (the MQLs created in the same week or month; for example "became an SQL within 14 days of becoming an MQL") and only include cohorts old enough to have had the full window. A ratio of "SQLs created this month divided by MQLs created this month" drops mechanically when MQL volume spikes late in the month, because the recent MQLs have not had time to convert. Also check that the numerator still fires: if the SQL timestamp or lifecycle field (the CRM field recording which stage a lead is in) stopped populating after a CRM (customer relationship management) workflow change, SQL counts fall with nothing wrong in the market.
   • SQL count flat, MQL count up: a denominator story (more, weaker MQLs).
   • SQL count down, MQL count flat: a numerator story (fewer accepted, or a field no longer being written).
2. Find the shape and date. Plot weekly cohort conversion. A step on one week means an event (release, scoring change, form change, routing rule, CRM migration). A slow slide means mix, capacity or market drift. If the fall is sharp, for example 30% week over week, work at weekly grain with a dashboard of conversion by week and by lead source, plus a database query that cuts it by score band like the ones in the worked example below. If it is a slide over two quarters, the question becomes what drifted: source mix, scoring calibration, SDR (sales development rep) headcount.
3. Audit the change log. List everything that changed in the 2 to 3 weeks before the step: MQL score threshold, new campaigns or gated content, imported event lists, SDR routing or round-robin rules (rules that hand incoming leads to reps in turn), SQL acceptance criteria, lifecycle automation (workflows that move leads between stages automatically).
4. Split by score band and source. If conversion inside each band is unchanged but the share of low-score MQLs grew, the composition changed and sales did not get worse. This is the classic mix shift (a composition, or mix-shift, effect: the blended rate falls while each group's rate holds. It is related to Simpson's paradox, in which a pattern seen in every group reverses in the combined data, but here nothing reverses: the weights between the groups simply moved).
5. Sales side. Time to first touch, open MQLs per SDR, and the rejection reasons recorded on non-converted leads ("no response" versus "not a fit"). Uniform decline in all regions is unlikely to come from regional rep behaviour, but a global SLA (service-level agreement, a promised response time) change or a hiring freeze would hit every region.
6. External. Compare with the same weeks last year and with other top-of-funnel signals (traffic, form fills).

What to rule out before blaming sales or marketing

Worked example (illustrative synthetic data, seeded so it reruns identically)

The data has three regions, 12 weeks, and a scoring change in week 8 that lowers the MQL threshold from 60 to 50, adding low-score leads that convert at about 5% while score 60+ leads convert at about 30%.

import random, sqlite3

rng = random.Random(7)
db = sqlite3.connect(":memory:")
db.execute("""CREATE TABLE mqls (mql_id INTEGER PRIMARY KEY, region TEXT, mql_day INTEGER,
              score INTEGER, sql_day INTEGER)""")

rows, next_id = [], 1
for week in range(12):                      # 12 weeks, day 0 = first Monday
    for region in ("NA", "EMEA", "APAC"):
        n_high = 40
        n_low = 0 if week < 8 else 40       # scoring threshold lowered from 60 to 50 in week 8
        for score_band, n, p in (("high", n_high, 0.30), ("low", n_low, 0.05)):
            for _ in range(n):
                day = week * 7 + rng.randrange(7)
                score = rng.randint(60, 100) if score_band == "high" else rng.randint(50, 59)
                converted = rng.random() < p
                sql_day = day + rng.randint(1, 14) if converted else None
                rows.append((next_id, region, day, score, sql_day))
                next_id += 1
db.executemany("INSERT INTO mqls VALUES (?,?,?,?,?)", rows)

# Fixed 14-day window per MQL cohort, so recent MQLs are not penalised for being young.
weekly = """
SELECT mql_day / 7 AS week, COUNT(*) AS mqls,
       SUM(sql_day IS NOT NULL AND sql_day - mql_day <= 14) AS sqls_14d,
       ROUND(100.0 * SUM(sql_day IS NOT NULL AND sql_day - mql_day <= 14) / COUNT(*), 1) AS conv_pct
FROM mqls WHERE mql_day <= 76            -- the extract is taken at day 90 (MQLs were created through day 83) and 90 - 14 = 76: only MQLs from day 76 or earlier have had the full 14 days
GROUP BY week ORDER BY week"""
print("week mqls sqls conv%")
for r in db.execute(weekly): print(*r)

by_band = """
SELECT CASE WHEN mql_day < 56 THEN 'weeks 0-7' ELSE 'weeks 8-10' END AS period,
       CASE WHEN score >= 60 THEN 'score>=60' ELSE 'score 50-59' END AS band,
       COUNT(*) AS mqls,
       ROUND(100.0 * SUM(sql_day IS NOT NULL AND sql_day - mql_day <= 14) / COUNT(*), 1) AS conv_pct
FROM mqls WHERE mql_day <= 76 GROUP BY period, band ORDER BY period, band"""
print("period band mqls conv%")
for r in db.execute(by_band): print(*r)

by_region = """
SELECT region,
       ROUND(100.0 * SUM(mql_day < 56 AND sql_day IS NOT NULL AND sql_day - mql_day <= 14) / SUM(mql_day < 56), 1) AS before_pct,
       ROUND(100.0 * SUM(mql_day >= 56 AND sql_day IS NOT NULL AND sql_day - mql_day <= 14) / SUM(mql_day >= 56), 1) AS after_pct
FROM mqls WHERE mql_day <= 76 GROUP BY region ORDER BY region"""
print("region before% after%")
for r in db.execute(by_region): print(*r)

What the three queries do: the first (weekly) counts MQLs per week and how many became an SQL within 14 days, and divides. The second (by_band) does the same but splits by whether the score was 60 or more, and by before or after week 8 (day 56). The third (by_region) gives each region's rate before and after day 56. All three use only MQLs from day 76 or earlier, so each had the full 14 days to convert before the day-90 extract; this is why week 11 (days 77 to 83) is left out of the printed table.

Printed output:

week mqls sqls conv%
0 120 36 30.0
1 120 40 33.3
2 120 49 40.8
3 120 47 39.2
4 120 34 28.3
5 120 32 26.7
6 120 41 34.2
7 120 38 31.7
8 240 51 21.3
9 240 40 16.7
10 240 41 17.1
period band mqls conv%
weeks 0-7 score>=60 960 33.0
weeks 8-10 score 50-59 360 5.0
weeks 8-10 score>=60 360 31.7
region before% after%
APAC 31.6 22.9
EMEA 34.4 15.8
NA 33.1 16.3

Reading it: weekly conversion falls from roughly 27 to 41% to about 17 to 21% from week 8, exactly when MQL volume doubles (120 to 240). In the band split, score 60+ leads converted at 33.0% before and 31.7% after, so sales follow-up did not deteriorate; the new 50 to 59 band converts at 5.0% and drags the blend down. In blended terms, weeks 0 to 7 convert 33.0% (317 SQLs from 960 MQLs) and weeks 8 to 10 convert 18.3% (132 from 720), although the 60+ band held at 33.0% and 31.7%. Half of the later MQLs sit in the 5% band, so the blend falls without any group getting worse: a pure mix-shift effect (the weights moved, the group rates did not). Every region fell together, which is what a global threshold change produces (the region figures differ in size only because each cell holds a few hundred MQLs, so they carry sampling noise).

One operational change to recommend

If the cause is a lowered MQL threshold, as in the worked example, I would keep the broader MQL definition (it brings real pipeline) but route the 50 to 59 band to automated nurture instead of the SDR queue, and report conversion by band from then on. SDR time goes to the band that converts, and the blended rate stops being a misleading single number. Trade-off: some real buyers in the low band wait longer; handle that with an upgrade rule when they show buying behaviour.

Pitfalls

• Blaming a region or team when all regions moved together.
• Using a period ratio during a volume spike.
• Quietly restating history on the new definition without labelling it, which makes the trend unreadable.
• Concluding "lead quality fell" from the blend without the band split.

Direct answer

Group opportunities (or leads) by the month they were created, then follow each group forward and measure what share reaches each outcome by fixed ages: converted within 30 days, won within 90 days, and so on. Compare cohorts at the same age, never at the same calendar date. A cohort is a group of records that share a starting event and month. Win rate is the share of records that end as won; always say whether the denominator is all records created or only those already decided. In-flight means still open, with no outcome yet. Conversion is improving only if later cohorts beat earlier ones at equal age. The biggest ways to be fooled are in-flight deals that have not had time to resolve, changes in lead mix, and slicing by close date instead of creation date.

How to set it up

• Grouping. Cohort = creation month of the lead or opportunity. Add cuts that explain differences: source channel, segment, deal size band, region, and rep tenure.
• Measure. Per cohort, per age bucket: share reaching the next stage; share closed-won (won out of all created, and won out of decided); median days to close; average deal size. Use a "within N days" rule so cohorts of different ages are comparable. Pick N from the long-run sales cycle.
• Display. A triangle: rows are cohorts, columns are age (30, 60, 90 days). Cells beyond the data's edge stay blank rather than showing partial numbers.
• Decision. If the 90-day win rate for the last four mature cohorts is lower than for the four before, conversion is deteriorating, and the segment cuts then say where.

Illustrative example of the in-flight trap

Suppose a cohort of 100 opportunities will eventually win 20 and lose 80. Typical losses close around day 45 and typical wins around day 90. Checking at day 60, imagine 60 have been lost, 4 have been won, and 36 are still open (16 of them will eventually win). The naive "won out of created" is 4 / 100 = 4%, which looks like collapse versus an older cohort's final 20%. The "won out of decided" is 4 / (4 + 60) = 6.3%, which also looks like collapse, because the quick losses have closed and the slow wins have not. Both understate for the same reason: the open deals have not had time to resolve. (If wins closed faster than losses, the decided-only rate would overstate instead.) The fix is to compare to older cohorts at the same age (what share of the older cohort had won by day 60?) or to wait until the cohort matures.

The triangle below, as of the end of June, shows what that comparison looks like. Each cell is cumulative closed-won as a share of all records created (illustrative):

Read down a column, never across a row. At day 60 the April cohort is at 3% against 4% to 5% for earlier cohorts, a small gap worth watching but not a collapse; its day-90 cell does not exist yet, so it stays blank.

What can fool you

Cohort by created date versus snapshot by close date

Created-date cohorts answer "is our process converting better?". Close-date snapshots answer "how much did we win this quarter?". They give different numbers for the same data and both are valid, so label which one a chart uses.

Trade-offs

Fixed-window rates are comparable but throw away deals that close later; survival curves use all the data but are harder to explain. A survival curve plots how the share of records still undecided falls with age, and it treats a still-open deal as "not decided yet, observed this long" instead of counting it as a loss; that treatment is called censoring.

Direct answer

Healthy coverage on paper means the total looked big enough; it says nothing about whether the dollars will close in the period. I would look at the pipeline's quality in six places, in this order: (1) what actually happened to the pipeline that existed at the start of the period, (2) funnel conversion against what the coverage target assumed, (3) deal aging and slippage, (4) stage inflation, (5) activity and engagement data, (6) concentration and timing. The usual finding is that the pipeline was inflated by stale or pushed deals, not that there was too little of it.

Terms: coverage is open pipeline (deals in progress in the CRM, the customer relationship management system) divided by target. Slippage is a deal whose expected close date is pushed into a later period. Stage inflation means opportunities sit in later stages than the buyer's real progress justifies. Bookings are the contract value signed. An economic buyer is the person who controls the budget and can approve the purchase. Exit criteria are the evidence a deal must show before it may move to the next stage. Stage-to-stage conversion is the share of deals in one stage that reach the next. A leading indicator is a signal that moves before the outcome does.

Worked example (illustrative): coverage 3.2x, bookings missed

At the start of the quarter, $6.4M of pipeline was expected to close against a $2.0M target, so coverage was 6.4 / 2.0 = 3.2x. Here is where that $6.4M ended up:

Bookings of $1.4M missed the $2.0M target. The plan assumed about 31% of coverage dollars would close (1 / 3.2 needed); actual yield was 21.9%. The largest bucket was not losses but slippage (46.9%), so the problem is not "we lost too many deals" but "deals dated this quarter were not really closing this quarter".

What each check tells you

1. Snapshot yield (as above). Take the pipeline as of week 1 for the last four to six quarters and measure the share that closed-won in period. If yield is falling, coverage requirements were stale. This is the base for everything else.
2. Funnel conversion by stage versus assumption. Compare this quarter's stage-to-stage conversion with the history your coverage target was built on. A fall at one stage locates the leak.
3. Aging. Compare each open deal's age with the typical age at which won deals close (for example the 75th percentile of won-deal age for that segment). A deal much older than that is unlikely to close this quarter. Illustrative numbers: if won mid-market deals closed within 90 days in three cases out of four (the 75th percentile of won-deal age is 90 days), an open deal that is 140 days old with its close date pushed three times is 50 days past that mark and should be heavily discounted or removed from coverage, while a 60-day-old deal with no pushes is inside the normal range. Also count how many times each deal's close date was pushed: repeated pushes are a leading indicator of slip.
4. Stage inflation. Check whether deals advanced without the buyer actions that define the stage (for example "proposal" with no pricing discussion). Signs: a stage where conversion to the next is far lower than historical, a jump in deals entering late stages in the last two weeks, short time in stage followed by long stalls. For example, a deal logged as moving through Qualify, Demo and Proposal in four days, then sitting in Proposal for 45 days with no pricing discussion and no reply from the buyer: the speed reflected data entry, not buyer progress.
5. Activity and engagement data. Last meeting date and next scheduled step, number of buyer contacts involved, whether an economic buyer is engaged. A late-stage deal with no buyer contact for 30 days is not late stage.
6. Concentration and timing. If three deals make up 60% of the pipeline, coverage hides single-deal risk. If most pipeline was created in the last four weeks of a quarter, it cannot close in the same quarter.

What I would change

Report coverage on a cleaned basis (exclude deals older than the typical cycle for their segment and deals with no recent buyer activity), set the required multiple from measured yield, and add exit criteria for each stage so it takes evidence to advance. Then track slippage rate as its own metric.

Pitfalls

Looking only at the total, trusting rep-assigned stages and dates without cross-checking activity data, using a single yield for all segments, and blaming sales execution when the pipeline was never real.