Pipeline deal values & forecasting

Jasper McEwan

Good morning.

I'm wondering if someone can help me with pipeline deal values and forecast reports.

Currently, when we set up a deal we annualise the potential contract amount so for example if the contract value is worth £100,000 annually that is the figure we would input into the deal value. However, the first order could be as small as £1,000 and once mobilised the client would spend in the region of £8-£9k per month to make up the annualised £100k.

This hasn't been an issue until we come to look at pipeline forecasts which now take the £100,000 as the deal value and it puts the whole of that value into the month it is due to close. Which isn't particulalrly useful for pipeline forecasting as it won't all land in the the month in which the deal close date is set.

Is there a better way of managing this or something I need to set up to enable this to work better for pipeline forecasting?

Many thanks in advance.

Axel

Hi @Jasper McEwan ,

It is possible if you set up Products for your deals. More infomation here :

https://support.pipedrive.com/en/article/recurring-products

For the first payment you could use the "Installement" feature in this Products tab.

Let me know if that works for you,

Axel

CatDad007

Hi there @Axel

Jumping on the back of this wagon, hopefully thats OK.
Similarly to Jasper's use case (https://community.pipedrive.com/discussion/16980/0/#Form_Comment) , we are a SaaS company that essentially has 2 x categories in our portfolio.1. Platform SaaS Products2. Services

There is a list / subset of SaaS products that falls under Category #1 as noted above (above). - The most common delivery/commercial model for our SaaS products, is a monthly usage/billing model - 2nd most common is an annual subscription paid in the first month of the contracted term (min 12months)

I have created these SaaS Products in Pipedrive succesfully.However, here is where I am stuck and need find a solution, in how this translates to our Revenue Forecast

Screenshot Attachment #1:Products that I have configured in Pipedrive. Note the first three rows -they reflect some of the SaaS solutions sell The 4th row = a fictitious product I created to see if I could solve my problem with the instalments feature

Screenshot Attachment #2:The Add Products pop-up box on a DEAL

Here is the scenario for this deal - Term of Deal = 36 Months - Total Deal Value over full 36 months needs balance to $150k - The deal is made up of 2 x of our SasS offerings

Monthly recurring revenue (MRR)$4,166.67. (2 products in this deal, each have an MRR of $2083.33)
Annual recurring revenue (ARR)$50,000.04
Annual contract value (ACV)$50,000.04
Total contract value (TCV)$150,000.12

Great, the breakdown above is 100% correct - so really pleased that it balances accurately.

Now… Revenue Forecast (which is probably the #1 reason that we are trialing Pipedive)

If I create a Revenue Forecast, and filter the data to only include THIS DEAL :
- At the moment, this deal is in the earliest stage of our Sales Cycle (Prospect).
- As such, the TCV revenue for this deal is $150k,
- but the weighted revenue = $7,500 (5% of TCV)
- Which would make the weighted ARR = $2,500 ; MRR = $208 ;
- and then each product would have MRR of $104.

I would expect the $208, to - reflect in every single month - from the start date (March 2025) - plus +35 months thereafter - with every month having $208 reflected.

See screenshot attachment #3

As you can see, the full weighted revenue total for the 36 months is being allocated to only March 2025, making the revenue forecast in Pipedrive completely inaccurate.I tried testing the Installments approach, but this is not a one time payment product, and I cant see why I would need to use that approach, when the way that pipedrive has configured our products above is absolutely the right way to do it - but then doesnt seem to do what it should by allocating by month.

Please help quite urgent

mac@datomni.com

Hi @CatDad007 @Jasper McEwan

We faced the same issue while implementing Pipedrive for an advertising client with multi-month campaigns. Pipedrive lumped the entire deal value into the close month, which skewed pipeline forecasts when revenue should be spread over time.

We used webhooks and the Pipedrive API to allocate deal values proportionally across the deal duration, resulting in accurate monthly reports.

Unfortunately, we couldn’t resolve this with Pipedrive’s workflow/formula fields or automations, but the API approach worked well for us.

Feel free to reach out at mac@datomni.com or schedule a call with me, and I’ll share insights on how to implement it and show a demo if you'd like.

https://calendly.com/datomni-consulting/demo

Axel

Hi @CatDad007 ,

That's okay, but only because of your user name :'D

I don't have a definitive answer but probably :

Revenue Forecast Reports base themselves on "expected close date" (in the deal).

So check if your expected close date is in march and please tell me if that's the case

Then I would suggest you do instead a Product report and try isolating this deal in the filters.

If that don't work, please send me also the filters you used in your screenshot

Let me know,

Axel

CatDad007

Hi Axel - I'm more Cat servant than Dad, but I'll take what I can get ;-)

Yes, understood and agree re: Expected Close date. If we were selling bread and milk, that would make sense and an accurate method for forecasting the revenue, because the transaction occurs on the specific date, paid in full.

But for the SaaS products I described above, customer is invoiced/invoice is paid monthly (similar example would be purchasing a new cellphone, no one in my country purchases a phone as one time cash/charge, its paid off over a contracted term, 24-36 months, via monthly instalments).

Revenue recognition principles do not permit revenue to be recognised in full upfront in a single period (month), unless it was contracted as such.

So to forecast revenue in 1 month is incorrect.In this example, estimated start date = revenue / services commencement date, and MRR should show in every single month for the contracted period (my example is 36 months).Otherwise this is not revenue forecasting. Its deal/signature forecasting.

Sorry if I'm telling you what you already know, this is just a deal breaker for us, as the revenue forecasting was a major reason for considering pipedrive before any other similar CRM

Axel

@CatDad007 Yes I see,

I ran a test and I could get results that might answer your problem :

I created a deal with similar billing conditions as yours :

• 100$ each month for 36 months
• 3600$ TCV
• Billing start date in march 2025 (note that in your screenshot it starts in June, not march)

And then a Product revenue forecast report :

Let me know if that works, but you're right to say that expected close date is deal signature forecast, not revenue forecast.

Axel

CatDad007

Hi @Axel - I responded to the comment you left earlier today, but does not seem to have worked.

Trying again.

Essentially, your guidance seems to accurately achieve my desired outcome, brilliant and thank you.

I now need to spend some time understand what limitations there are, if any, to using product revenue forecast report types vs Deal Revenue forecast reports.

In my view, there shouldnt be a difference, unless
1. Deal Revenue forecasts are intended to forecast signatures, on an estimated close date, using TCV as the amount/value field. Whereas
2. Product Revenue Forecasts apply a weighting to the deals in the pipe based on Sales Stage, and then use that weighted value + the period/term of the deal/contract to calculate MRR, ARR etc which are them allocated over xxx term to produce rev forecast

Agree/Disagree ?

Thanks again

Axel

@CatDad007 ,

Glad I could help

Indeed the 1 and 2 you distinguish are accurate.

Deal forecast are based on Expected close date and seem to count the TCV, no matter if the product is monthly billed

Product forecast are based on Billing start date (written inside the parameters of the product attached to a particular deal)

It would be great if a Pipedrive admin could elaborate on this subject :)

@Manuel Oliveira ?

Axel