How to Use AI to Document a Revenue Planning Process

The best time to find out what your revenue model needs is before you build it.

Dimensions become expensive when you discover them late

Let's take something as simple as revenue by customer.

Perhaps you initially build the model by product.

Everything works.

Then someone asks to analyse the plan by customer.

Fine.

Then geography.

Then salesperson.

Then perhaps customer group.



None of those requests sounds unreasonable.

The problem is that every one of them has implications for the model.

• How will the data be entered?
• At what level will actuals come in?
• How will the dimensions interact?
• What level of detail does the sales team realistically want to plan at?
• How much granularity is actually useful?

Those are business questions before they are system questions.

Donovan describes this quite well in the episode. Before building, the team asks whether revenue needs to be planned by customer, product, geography or sales representative, and at what level actual results should be brought into the model for comparison.

That conversation is much cheaper before development than after it.

Then there is everything around the calculation

Revenue planning sounds like a calculation problem.

Volume multiplied by price.

Perhaps discounts.

Maybe rebates.

Transport.

Commission.

But that isn't really the process.

• Someone has to supply the volume.
• Someone has to determine the price.
• Someone reviews the assumptions.
• Someone approves the plan.

There may be templates involved.

There may be risks in those templates.

There may be specific management requirements.

There may also be KPIs that tell us whether the planning process itself is working.

That is why Donovan's process documentation captures more than the obvious model logic.

It looks at:

• Steps.
• Roles.
• Inputs.
• Outputs.
• KPIs and metrics.
• Requirements.
• Risks.

In his revenue example, inputs might include sales volumes, pricing information and discount drivers. Outputs might include annual or quarterly revenue. A risk might be a sales template containing blank columns or incomplete periods.

Suddenly the model looks slightly different.

We aren't just asking:

How do we calculate revenue?

We're asking:

How does the organisation plan revenue?

Those are not the same question.

There's nothing particularly new about documenting a process

The methodology Donovan uses has its origins in Lean Six Sigma and the SIPOC framework.

• Suppliers.
• Inputs.
• Process.
• Outputs.
• Customers.

None of that is particularly new.

And that's probably a good thing.

The objective isn't to invent another framework.

It's to make sure we understand the big picture before jumping into the detail.

At KPI, that framework has been adapted into something more practical for documenting finance processes. What are the steps? Who is involved? What goes in? What comes out? What are the KPIs? What are the requirements and risks?

The interesting part is what AI now does to the effort involved.

Because documenting all of this can be painful

This is probably why we sometimes skip the documentation.

It takes time.

You sit in a room with the commercial team.

• Someone explains the process.
  
• Someone else corrects them.
  
• Then someone remembers another step.
  
• Someone takes notes.
  
• Someone has to turn those notes into something sensible.
  
• It gets circulated.
  
• There are comments.
  
• The document gets updated.
  
• Eventually everyone agrees that this is more or less how the process works.
  
• By that stage, the person building the model has probably started anyway.

So I can understand why people are tempted to skip ahead.

But this is where the AI demonstration becomes useful.

What if the meeting became the documentation?

Imagine you're sitting with the sales and commercial teams discussing the revenue planning process.

Instead of trying to listen, ask questions and document everything at the same time, you record the conversation.

You still ask the questions.

• Who owns this?
• Where does this information come from?
• What happens next?
• How long does that take?
• Who approves it?
• What happens if this input is wrong?

But the recording becomes part of the input.

You could also upload existing process documentation.

Or enter the information manually.

The AI then has something to work with.

Donovan demonstrates exactly that. The information can come from an uploaded document, recorded audio or a structured discussion, provided the conversation captures the roles, tools, outputs, steps, duration, KPIs and risks that matter.



That's a much more interesting use of AI to me than simply asking it to write a process.

AI still needs you to know what to ask

There is a catch.

There usually is.

If the conversation is vague, the documentation will probably be vague.

If nobody asks about approvals, the AI cannot magically know that an approval matters.

If nobody discusses dimensions, it may miss them.

If the roles are unclear, the process will reflect that uncertainty.

This is why the WBS chatbot asks clarifying questions before producing the document.

What process are we documenting?

Who are the people involved?

Are there company-specific standards?

What outputs are required?

Which systems and templates are used?

In Donovan's example, he tells the bot that the process involves selling multiple SKUs and that the key people include the commercial executive, national sales manager, sales representatives and commercial finance business partner.

He also tells it that the revenue plan will drive discounts, rebates, commissions, logistics and transport costs and will feed into management reporting.

That context matters.

A lot.

AI can structure the thinking.

It can't replace the thinking.

Then something useful happens

Once the chatbot has enough information, it starts turning the conversation into a structured process.

• It identifies roles.
• It identifies the steps.
• It identifies outputs.
• It adds supporting notes.
• It can also produce an Excel version.

KPI then takes that output and moves it into Smartsheet, where the process can be organised hierarchically and reviewed properly.

In Donovan's demonstration, the high-level process includes capturing revenue planning drivers, building the revenue plan, reviewing and approving it, monitoring performance and reporting on KPIs.

That's quite a lot to get from what began as a conversation.

But I think the important part comes next.

The users still need to review it.

They still need to say:

Yes, that's how we work.

Or:

No, you've missed something.

That review is important because the objective isn't to get AI to produce a clever document.

The objective is to agree the process before we build against it.

I particularly liked the KPI part

One of the things the chatbot does is suggest KPIs.

Not just financial KPIs.

Process KPIs too.

For example, Donovan shows percentage of revenue plans approved on the first pass.

I like that one.

Imagine your revenue budget is only approved on the third or fourth attempt every year.

That tells you something.

Perhaps the assumptions aren't clear.

Perhaps sales and finance aren't aligned.

Perhaps the review process isn't working.

Perhaps the inputs arrive incomplete.

We normally measure the output of the plan.

Revenue versus budget.

Margin.

Discount percentage.

But there is also value in measuring how well the planning process itself works.

The bot suggests examples including revenue versus plan and percentage discount leakage, and can identify where integrations such as actuals coming from an ERP system fit into the process.

That starts moving us from process documentation into process improvement.



The document isn't really the point

I don't think anybody particularly wants more process documents.

Finance departments already have enough documents.

The value is what happens next.

Once the business has agreed:

• These are the dimensions.
• These are the roles.
• These are the inputs.
• These are the outputs.
• These are the KPIs.
• These are the approvals.
• These are the risks.

Then the person building the model has something much more useful than a vague instruction to "build us a revenue model".

They have a blueprint.

In Donovan's example, the next step is to take that documented process and build the revenue planning model in Prophix.

And I think that's the larger point.

The purpose of using AI here isn't really to create documentation faster.

That's useful.

But the bigger benefit is that it gives us a practical way to spend more time understanding what we're supposed to build before we build it.

The question I'd ask your finance team

Pick one planning model you currently use.

Revenue is an obvious one.

But it could be headcount.

Operating expenses.

Capital expenditure.

Cash flow.

Now ask someone who isn't involved in the process to explain how it works.

Who provides the inputs?

At what level?

Who reviews them?

Who approves the plan?

Which KPIs matter?

What are the major risks?

Why is the model structured the way it is?

If those answers exist mainly in the heads of two or three people, then you may have a modelling problem waiting to happen.

Perhaps the first thing you need isn't another model.

Perhaps you need a better understanding of the process behind it.

And that is where AI may be rather useful.



Frequently Asked Questions

Why should you document a revenue planning process before building the model?

Documenting the process helps finance understand the required dimensions, level of detail, inputs, outputs, KPIs, roles and approvals before development begins. This reduces the risk of discovering important requirements after the model has already been built.

What should be included in a revenue planning process?

The documentation should include the process steps, roles, inputs, outputs, KPIs and metrics, requirements and risks. For revenue planning, this may include sales volumes, pricing, discount drivers, approvals and reporting requirements.

How can AI help document a finance process?

AI can take information from manual inputs, existing documents or recorded discussions and convert it into structured process documentation. It can also ask clarifying questions to identify missing information before producing the output.

Can AI suggest KPIs for a revenue planning process?

Yes. In Donovan's demonstration, the chatbot suggests KPIs including revenue versus plan, percentage discount leakage and percentage of revenue plans approved on the first pass.

How does process documentation help when building a revenue model?

The documented process creates a clearer blueprint for the model. It allows the development team to understand the dimensions, business requirements, process steps, inputs, approvals and outputs before development starts.

Listen to Episode 15 of the FP&Ai Podcast

In Episode 15 of the FP&Ai Podcast, Donovan Moses demonstrates how AI can help document a revenue planning process, from capturing the initial requirements through to creating a structured WBS, exporting it into Excel and managing the process in Smartsheet.

He also explains how that documentation becomes the starting point for building the revenue planning model in Prophix.

If your team normally starts building models before everyone has agreed exactly what those models need to support, the episode is worth watching.