How to forecast revenue from HubSpot or Salesforce data when you only have two years of history

A revenue forecast built on two years of history can be useful but not precise, because each season has been observed only twice, so state an error margin before the first number ships, save every forecast so accuracy can be measured, and forecast one month before you forecast six.

The request usually arrives as a deadline. In one engagement we worked on, a usage-based company that is paid for each order its customers ship wanted a framework forecasting model by the end of the quarter and a working version the following year. Its order system had gone live less than two years earlier, so the history was, as the client lead put it, two data sets. Its own data scientist said there was not enough data to build a forecasting model yet. Both statements were true. The work was deciding what could responsibly be built anyway.

The arithmetic of the problem is simple. A forecast that has to handle November has seen November twice. A holiday week or a shopping event that moved by a few days has at most two observations, and two points cannot tell you whether the second one was normal. Whatever pattern you fit will look convincing and carry a margin of error you cannot see. As the consultant put it on the call, no one can expect perfect accuracy when you don't have a lot of data. More history narrows the margin. Nothing else does.

The accuracy check. This company had no stored snapshots of past forecasts. Sales recorded a declared monthly volume for each customer in HubSpot, and operations made occasional capacity estimates before peak season, but nothing had been saved that could later be compared with what happened. Without that record you can build a model and never learn whether it is any good.

The consultant's advice was blunt: from the beginning, measure the accuracy of the forecast model. In practice that is a small log. Each row holds the date the forecast was made, the horizon it covers, the customer segment, the forecast value, and, once the period closes, the actual value and the error. Build that table before the model. Every later decision, including whether to trust the model at all, depends on it.

If your team already forecasts from a spreadsheet each week, the log can start today by saving a dated copy of each number you publish. The first rows are not useful. By the fourth month they are the only evidence you have.

Because a one-month forecast shows its error in a few weeks, and a six-month forecast shows its first readable error half a year later, after decisions have already been made on it. The advice in this engagement was to forecast the coming month, check it against actuals when the month closes, and extend the horizon only after that check. For this client that meant a 30-day forecast first, with accuracy reviewed once the first month was in, before anyone quoted a six-month view.

A short horizon also lets you be honest with leadership. You can state the margin on a month because you have tested it. You cannot state one for a half-year you have not yet seen, and the right answer to that request is to say so and give the date when you will be able to.

Build them as two separate sections of the model. The consultant's wording was two different sections, internal signals and external signals.

Internal signals describe how a customer behaves: how steadily they ship and how many regions they reach. The client lead offered examples of this kind, and the client's own analyst called some of the candidates not conclusive. That is the honest state of a short history. A behavior that precedes hitting a goal in two years of data is a lead worth testing, and it has not yet been shown to cause anything.

External signals come from outside the business: holidays, retail peaks, a shopping event that moved on the calendar. Each of these happens once a year, so each has very few observations, and each affects some customer profiles and not others. Tie every external event to the profile it touches.

The reason to keep the two apart is testability. Internal signals can be checked on every customer all year. External events can be checked once a year at best. Blend them and the strong, frequent signal absorbs credit that belongs to the rare one, and a bad holiday week gets blamed on customer behavior.

Because an average curve across both fits neither. The consultant said patterns for small customers will be different from patterns for enterprise ones, and the client lead had the same suspicion: enterprise customers reach their goal, but over a longer period than the first few months the model was counting. That hypothesis was still unverified, and the data scientist was asked to split the segment out and look.

The mechanics matter. The client counted ramp from the first full month of shipping and sorted customers into fast and late ramps by when they reached goal. If a long enterprise ramp sits in the same bucket as the rest, it makes the whole group look late. The blended curve then misleads the people trying to decide which customers need help.

Splitting has a cost with two years of data: each segment gets thinner. The analysis handled this by greying out any segment with too few customers, which is the right instinct. A number from a handful of customers is not a curve, and showing it invites someone to act on it.

Sales set an expected monthly volume for each customer during the deal cycle, and it sits in the CRM. It is the only forward-looking number the company had, so it earns a place in the model. It is also an estimate made by the person who closed the deal, so it works better as a baseline than as the forecast.

Compare each customer's actual ramp with the declared volume, by segment. A customer far below their declared volume is a customer worth a conversation, and that was the second goal the client set for the model: flagging customers who are not performing as expected. Used this way the declared volume does a job it can do well, and the forecast does not have to inherit its optimism.

Start with the question the consultant asked: what is the primary objective of this forecast model? In this engagement there were two answers. Forecast revenue, and flag customers who are off track. Churn was explicitly out of scope and upsell was a bonus. Because the company is paid per order, orders tie directly to revenue, and both sides agreed to call the output revenue.

Then agree four things before anything ships. The horizon, which starts at one month. The error margin you are willing to be held to, stated as a range. The review cadence: the client wanted the customer success managers on the highest-priority accounts to review every two weeks and leadership to review monthly. And the decision the forecast is meant to inform, because a forecast with no decision attached gets read as a promise.

Ask also whether older records exist in a system the company retired. In this case an engineer was looking for order history from before the current system, and every extra year does more for the margin than any modeling choice.

This week, before you build anything, create the forecast log, save today's forecast for next month, and write the margin you will accept next to it.