Stations set a target and a shape. The system fills every day of the year from that station's own history: its weekday rhythm, its holiday calendar, its seasonal pattern, and any period marked as a disruption. Weeks and months are aggregations of those days, so they cannot disagree with each other. Volumes and labour hours are budgeted together, in the definitions the payroll system already uses.
Everyone says they do bottom-up budgeting. Almost nobody actually does.
What really happens is counter-current: HQ sends down a target, stations build up a number, and the two spend three months converging. The tooling supports neither direction properly. The templates are built for the upward pass, and the target that started it all lives in a slide deck nobody can trace back to.
The interesting question isn't bottom-up or top-down. It's whether anyone can explain, in November, how the number that came down and the number that went up became the number you're now committed to.
Budgets are entered by month. The operation runs by week. No split between the two is ever right, so the number people actually steer on is the one the budget never produced.
Actuals, forecasts and budgets are compiled at different levels, and a flight, a tonne, an FTE and a month each come to mean something slightly different at each of them.
The history that would answer most of these questions already exists, at daily granularity, and is almost never read during a budget cycle.
Actual months so far, plus the remaining months from a source you choose, times a growth target. One number per metric, per station.
Last year, a multi-year average, or last year's budget. This decides how the year is distributed across months and customers.
Every day of the coming year receives a weight, and the days are scaled so they sum exactly to the annual value.
Median volume per weekday within each month, so a Tuesday in July is not treated like a Tuesday in January. Held per station, or per customer where their rhythms differ.
Each holiday measured against comparable days, the same weekday in the weeks around it. Held by name, so a moving date carries to next year, and covering the day before and after.
Month and customer in a single factor, so the monthly level and the customer split are the same number rather than two that must be reconciled.
A named period marked abnormal is excluded from learning, so a one-off event does not become next year's pattern.
Three years of a station's own daily history already contains its weekday rhythm, its holiday effects, its seasonality and its absence profile. The system proposes all of it. Managers review and correct rather than enter, and the parts they correct are recorded as corrections.
A period can be flat in tonnage while annual leave doubles. Budgeting both from the same daily grain means the staffing answer follows the hours, not a proxy.
The volume budget, converted to hours at the productivity you are targeting, per department and per month. One productivity definition throughout, volume over total worked hours, so the ratio means the same thing in every report.
A paid base from headcount and contracted weekly hours. Absence deducted by type, as monthly percentages seeded from that station's own history. Then overtime, third party and subcontracted hours added on top. The result is total worked hours.
The gap between demand and supply is shown per month, and never closed automatically. It is the staffing conversation, not an answer the system imposes.
The target still descends and the build-up still ascends. What changes is that the convergence has a structure.
A budget period holds as many rounds as the cycle needs. Each round has its own start and end date, and its own status per station.
A round is issued, not announced. Invitations, reminders and escalation belong to the round rather than to somebody's calendar.
Entry and approval are separate roles, and access is granted by country. One version per station, throughout.
Progress is visible while the round is open, per station and per metric: what has been entered, where day-level overrides were used, and what has been submitted.
A second round reopens without disturbing what the first one produced. The target can descend again, and what the stations built is still there, still traceable.
A handful of numbers to start, with the rest proposed.
Months arrive pre-filled, so the work is review rather than construction.
Day-level detail is available when it is wanted and out of the way when it is not.
New and departing customers are handled as ordinary monthly values, with no separate contract screen.
Analysis updates while stations are still working, because values land in the database as they are entered.
One version per station, with entry and approval separated and access granted by country.
Full daily detail available to reporting tools, broken down by mode and direction, with no re-keying.
A budget expressed at the grain rosters are actually built on.
Labour hours in the same hour-type structure the payroll system uses, so budget and actual compare line by line.
The demand and supply gap shown per month rather than assumed away.
Nothing has to be split, and the levels cannot contradict each other.
The day factors are normalised so the year averages to one.
Month length, working days, leap years and moving holidays such as Easter are handled without anyone maintaining them.
A day resolves on screen through the stored factors that produced it: the annual value, the month and customer factor, the weekday factor, the holiday factor, and any override. In November, the number can be traced rather than defended.
The calculated output can be discarded and rebuilt at any time. Everything a user typed is held separately and is never touched.
We will set up a 30-minute conversation. Cohelion running on a scenario close to yours.