GTM Reporting Foundations (Part 1): Reporting Workstreams

Introduction

Reporting is one of those critical elements of business infrastructure that often goes unnoticed until something goes wrong.

When it works seamlessly, business users tend to assume everything comes together like magic—much like how we expect light when we flip a switch or water when we turn on a tap.

But when reporting doesn’t meet expectations...well, we’ve all been there.

Unfortunately, there’s no easy mode for building robust reporting capabilities. While AI might alleviate some of the pain over time, there will always be a need for good planning, careful stewardship, and a bit of grit.

I began writing an article to consolidate some frameworks and routines that I’ve found useful. However, I quickly realized it would be far too long and time-consuming for a single piece.

So, in an effort to resist my tendency towards monolithic and comprehensive posts, I've decided to break this into a multi-part series. It’s probably for the best.

This series will primarily focus on scale-up stage companies, which is my area of expertise.

Note, I recently appeared on Beyond the Pipeline with Vivin Vergis , whose questions helped me distill some of this content. He’s a great host—check it out .

Roadmap

It’s still hypothetical, but here is roughly how I see this series playing out over time.

I’d love feedback on other topics you’d find interesting or useful.

• Reporting Workstreams (today’s post)
• Reporting Systems and the Single Source of Truth
• Dashboard Development Process
• Defining, Modelling, and Documenting Your Data
• Data Culture and Communication
• Common Challenges

On to today’s topic.

GTM Reporting Workstreams

Not every report or dashboard is created equal.

There are various types of reporting needs, each with implications for how and where you build them, the level of data quality required, and prioritization.

Keeping these distinctions clear brings order and structure to your reporting universe.

Core Operating Reports

These reports contain the primary business KPIs for each function (e.g., funnel metrics, channel performance, new bookings, churn, sales forecast, etc.).

These metrics reflect each team’s core accountabilities and how the business is managed.

Audience

• Company wide, manager and executive level.
• Every relevant person should know that a particular dashboard is the source of truth for a specific KPI.

Design

• Clear and simple, foregrounding the most important information and free of extraneous detail.
• Aside from filters on time range or market, they offer limited interactivity. You want each stakeholder to see the same thing.

Maturity

• These reports are mature and should be viewed as a trusted source of truth.
• They provide consistency and stability, delivering reliable insights each time. They are relatively slow to change.

Data Quality

• The tolerance for data discrepancies or errors is very low.
• The underlying data should be kept pristine. Definitions are very well-documented.
• Mature processes for governing and cleaning this data are essential.

Development

• These core operating dashboards are managed like a product, either by RevOps or the data team, depending on org structure.
• They evolve iteratively based on business needs and feature requests.

Reporting Environment

• Most early-stage businesses will start off building these reports in CRM.
• However, past a certain inflection point, CRM capabilities may be exceeded.
• For example, integrating targets into CRM reporting can be challenging, but targets vs. actuals should be a fundamental view in operational reports.
• For this reason, core operating reports are best built in a BI tool connected to your warehouse.

Performance Management Reports

Unlike core operating reports, which focus on a consistent set of KPIs that are intrinsically important to the business, performance management reports address issues in the revenue engine. They delve into the underlying causes of changes in your primary KPIs and are typically focused a few levels deeper in your KPI tree .

These reports aim to provide answers to specific questions, like

• Why is conversion dropping for our organic handraisers WoW?
• What’s contributing to a slower SLA for our SDR team in the US market?
• How many demo requests don’t have a meeting booked and require follow up?

Audience

• These reports are designed to enable functional team members to troubleshoot and manage their part of the business.
• They are typically more granular and detailed than core operational reports, which have cross-functional audiences.

Design

• It’s impossible to pre-build every report to answer every question, so these reports should be flexible and filterable.
• They need to enable functional owners to drill, filter, and pivot by whatever dimensions they care about to answer questions based on the needs of the moment.

Maturity

• These reports tend to have a spectrum of maturity.
• For established channels and business functions, there is likely to be a well-defined process for troubleshooting and analyzing the business, with mature reporting interfaces.
• Reporting for newer business activities may be more ad-hoc, only becoming crystallized as the business process matures.

Data Quality

• Data still needs to be clean enough to drive accurate decision-making, but the acceptable margin of error is slightly larger.
• More mature reports will have greater data quality, whereas newer areas of investigation may rely on less certain data.

Development

• Mature reports should be productized, similar to core operating reports.
• Ad-hoc reporting requests should be prioritized based on ease of development and business impact.

Reporting Environment

• Typically these reports begin in an ad-hoc way, e.g., “I wonder how much of x is y,” etc. You don’t initially know whether that question is useful, so you want to build the report as quickly and easily as possible. Typically this means doing a v1 in a source system like Salesforce, unless the data has already been operationalized inside a BI tool that makes it easy to explore.
• Once a report becomes “established” as part of a team’s optimization and troubleshooting methodology, it makes more sense to formalize it in a BI tool, where you can add more powerful filtering and drilling capabilities or integrate additional datasets.

Innovation / Ad-hoc Reporting

These reporting requests are usually exploratory in nature—evaluating “what if” scenarios or new ideas.

For example, they could be aimed at identifying the most valuable segments or markets, testing a hypothesis, evaluating opportunities, etc.

Audience

• Varies from individual contributors optimizing a specific channel to executive-level audiences developing business strategy.

Design

• Generally more simple and focused on answering a specific question—e.g., “Should we expand into the ANZ market? Let’s review how many hand-raisers we’ve had in the past 12 months and whether any of them became opportunities.

Maturity

• By their nature, these reports are answering new business questions and tend to be immature.

Data Quality

• Because this analysis is new, the data typically won’t be perfect. The insights here are typically directional rather than absolute.
• Either the source fields may not be clean, or the data may only be available in a sub-optimal format (a concatenated or overwritten field, for example).
• It’s not wise to invest too much time in producing perfect data when the report may not be useful in the long-term. Instead, get comfortable delivering the report with caveats (this is missing, this is approximate, this may lack fidelity, etc.).
• Your stakeholders will usually understand, and if the data is truly useful in that state, you can then feel more confident prioritizing additional effort to clean it up.

Development

• Depending on the availability of the underlying data, developing these reports can be expensive and time consuming.
• Also, the long-term usefulness of ad-hoc reporting is unknown.
• So it’s important for the team responsible to vet these requests carefully, interrogate the potential for impact, and prioritize them accordingly.
• Prioritize a quick-and-dirty v1 over something perfect.

Reporting Environment

• Because it’s far from certain this analysis is useful on an ongoing basis, focus on building a v1 as quickly and cheaply as possible.
• Typically this means doing it in source systems like CRM where possible, unless the data has already been operationalized inside a BI tool that makes it easy to explore.

Originally published on RevOps FM . Please subscribe to support my work.