What does a commercial analyst actually do?

I don't write SQL. Not by hand anyway. That might sound like a confession, but it's true of most analysts (and engineers) now.

In the 9 months since joining incident.io I have built headcount models for hiring decisions, a Slack bot for assigning new customers, guidance for our AI data analyst, and a couple of internal web apps. If you asked me which of those counted as "analysing data", I'd struggle to say.

A lot of that comes down to the "commercial" part of the job title. Commercial analysts work with the teams that bring in and keep revenue: Sales, Customer Success, RevOps and Finance, plus Revenue Leadership.

The common asks include:

Questions that on the surface are pretty straightforward.

The answers are usually not.

None of these can be answered with a query alone. They need business context: how the current process works, what's costing people time, what's changing next year, and usually a string of followup questions that haven't been uncovered yet.

Another thing that sets the role apart is that the data is different. A product analyst for example might have millions of user interaction events or alert data to dig into. Commercial analysts work with much smaller datasets, and because so much depends on people, the answer is never exact. Being directionally correct is more useful than being precisely incorrect.

That changes which skills matter. Some of the key ones are:

• Framing the problem. Turning a vague question into something you can model, and being clear about which parts are guesses.
• Knowing how the commercial side works. Comp plans, territories, handovers, renewals and every quirk of Salesforce.
• Changing the process, not just reporting on it. The analysis often shows the process is the problem, and the fix is a new way of working.
• Earning trust. The output decides whose book gets which accounts, or whether a team gets another hire. If people don't think it's fair, they won't use it.

None of those are new, but they have now become the bulk of the role, whereas a few years ago a good chunk of my time went on turning questions into queries. That part is now mostly done for me, and plenty of questions get answered by our AI data analyst before they reach me at all. What's left is the context and the judgement.

So you likely won't find any commercial analysts running an A/B test. While more maths-based analysis is part of certain projects, I am more likely to be working on a whiteboard with a stakeholder to scope the question, redesign a process, scenario plan or decide how deep to go before a decision can be made.

Three projects from the last few months show what that looks like in practice. Each one is a step further from anything you'd call analysing data.

How many people should we hire next year?

Our Expansion Account Managers (XAMs) work with existing customers to grow their accounts, whether that's a renewal, more seats or adding a new product. Next year the shape of that work is changing. We're launching Investigations, which brings a new type of deal, and the mix of deals the team works on is shifting too. So it's not as simple as modelling out growth and productivity.

That came down to a few decisions. First, breaking the deals XAMs work into types, from a simple renewal through to selling in a new product. Then giving each type a unit of work, so a quick renewal and a long, multi-team expansion don't count the same. From there, scenario plan the flow of accounts coming to the team and how much more work selling a new product type might take, and turn that into how many people we'd need under each scenario.

None of those steps needed heavy data analysis, you could probably have gotten pretty far with a pen and paper in a day. They needed someone to decide what mattered and be clear about which numbers were guesses.

How much uplift will Investigations bring? What will pricing look like?

Nobody knew yet, and no amount of historical data was going to tell us.

That also changed what to deliver. A single number would have looked confident and been wrong as soon as an assumption moved. Instead I built a model for our decision makers (along with my recommendations and caveats), where they can change the uplift and pricing assumptions and see how the hiring picture plays out.

The output isn't one answer but a range of scenarios, and helping the people making the decision see exactly what they are dependent on.

This is the closest of the three to analysing data, and even here I handed the modelling to AI. The real work was deciding how to approach the problem, thinking through the different ways next year could play out, and choosing the best thing to put in front of leadership so they could make the call.

We have a new customer. Who should look after them?

An ever-increasing stream of incoming customers means a growing team of Customer Success Managers (CSMs), and a harder job knowing who has the most on their plate and who to hand accounts to. Eventually a manager can't keep up, and checking with everyone isn't practical when more assignments come in every week.

The idea for fixing this was pretty simple: decide a proxy for who has the most capacity, and assign new customers based on that (with some other rules in there). Working with our Head of CS, we built a score for each customer to approximate how much effort it takes to manage them. In simple terms, customers with a lot of users and a complicated setup require more capacity to look after.

We settled on six data points to represent this to keep it explainable.

Because there is no true answer for how much work a customer will be, what you suggest needs to make sense to the people it's impacting and be defensible. Sum up the scores on someone's book and you get a ranking of who has the most capacity.

So now we have a way of knowing who should probably get the next customer, represented in a dbt model, but this is as far as you can get with quantitative data in a lot of cases - "probably". You can't capture everything in a score (things like personal relationships or CSM industry expertise). Data can tell you a lot, but here it shouldn't be taken as gospel.

As much as I would love it, we don't have a BigQuery table which tracks all the ins and outs of our CSMs' industry knowledge (yet).

Building an automatic assignment workflow in Salesforce would have made things seamless, but the score is only directional, so we still wanted to give the final call to a person. Instead we built a Slack bot that posts in the team's channel with the two best assignment choices, and a link out to a dashboard showing the current spread of capacity scores across the team.

Our Head of CS now gets a Slack message with the key information (e.g. revenue and working region) and two solid suggestions. What was a few messages back and forth is now a ten second decision, and still leaves room for the things we can't put into data (yet).

Looking back on this project, it didn't really involve any analytics. The real value came from serving up existing data and enabling a process change.

How many tools does it take to answer one question about a customer?

For our XAMs and CSMs, the answer was about six. Salesforce for the deal, Gong for the last call, Pylon for support tickets, a dashboard for health, DocuSign for pricing history and a Slack channel for everything else. A lot of the team had started building their own Claude Artifacts to stitch it all together, which tells you how much of a pain it was.

What they needed was one place to see an account and, eventually, act on it.

I am now effectively functioning as a product owner, building out an app on our own internal tooling to bring all of the key information into one place. I'm working closely with both sales teams and our Applied AI team on a command centre that lets them do more of their work from one place. That means users, a roadmap, deciding what gets built first, and owning it once it's live.

None of that is in a typical analyst job description, but it's where the role ends up. The analyst already knows the data, knows the people using it and knows what's slowing them down. That's most of what a product owner needs. Of course, for me, none of this would be possible without AI.

So, what does a commercial analyst do?

Across all three projects, the value didn't sit in the analysis. It sat in what got delivered: a decision guide, a faster process, a tool people start their day in. Data is at the core of each one, but in the commercial world it's only part of what makes the work useful.

The important skills haven't changed. Understanding the business, and making sure you're solving the problem someone is actually facing. Commercial analysts do a bit of everything, but they don't write much SQL…