Every September I see the same pattern. A business owner realizes Q4 is here, next year's technology budget is due to the finance team in six weeks, and the plan is still a list of half-remembered ideas from meetings nobody wrote down. Q4 technology budget planning done this way produces a number, but not a good one. It gets padded, or it gets slashed, and either way it stops reflecting what the business actually needs.
The fix isn't a bigger spreadsheet. It's starting the ranking exercise now, while there's still time to price things honestly instead of guessing under deadline pressure.
Why Q4 Is the Wrong Time to Start From Zero
If your first draft of next year's technology budget happens in the last two weeks of Q4, you're not budgeting, you're forecasting under duress. Vendors know this too. Software renewals cluster in December, and a rushed buyer signs whatever contract lands on their desk instead of negotiating.
Start the exercise in September or October instead. That gives you time to:
- Get real quotes instead of rough estimates
- Talk to the team about what actually broke or slowed them down this year
- Cross-check requests against what you're already paying for
The 70-20-10 Split
I tell every client the same allocation to start from, then adjust based on their situation.
| Bucket | Share | What it covers |
|---|---|---|
| Keep the lights on | 70% | Hosting, licenses, security patches, backups, support contracts |
| Improvement | 20% | Upgrades to existing systems: faster checkout, better reporting, mobile app updates |
| Experiments | 10% | New tools, AI pilots, anything unproven |
Most owners get this backwards. They see a shiny AI tool in a LinkedIn post and want to allocate 40% of the technology budget to it, while the "keep the lights on" bucket, the thing that actually keeps revenue flowing, gets squeezed to make room. A retail chain in Tangerang I worked with had this exact problem two years running: exciting pilot projects funded, then server costs and SSL renewals treated as an afterthought that got paid from petty cash mid-year, disrupting other plans.
Protect the 70% first. It's not exciting, but it's the difference between a business that runs and one that has outages.
Rank Initiatives, Don't Just List Them
A list of ten technology initiatives with no ranking means all ten get watered-down budgets, and none get done properly. Instead, force a ranking using three questions per item:
- Does this reduce a cost we already pay? (e.g., manual reconciliation hours, cloud bills that keep creeping up)
- Does this reduce risk? (security patch, backup system, disaster recovery)
- Does this generate revenue or retention? (new feature customers are asking for, faster response time)
Anything that doesn't hit at least one of these hard is a "nice to have" and goes in the 10% experiments bucket, not the main plan. This alone usually cuts a bloated 20-item wishlist down to 6-8 fundable initiatives.
Price Things Honestly
The single biggest budgeting mistake I see is estimating cost from the sales page instead of the real implementation. A CRM plan advertised at 500,000 IDR per month rarely stays at that price once you add users, integrations, and the internal hours needed to migrate data and train staff.
For every initiative on your shortlist, price three things separately:
- License or subscription cost (the number on the invoice)
- Implementation cost (internal hours or a contractor's fee to set it up properly)
- Ongoing maintenance cost (someone has to own it after launch)
Skipping the second and third numbers is how a "cheap" tool becomes an expensive mistake six months in. If you don't have a way to estimate implementation and maintenance hours accurately, that's usually a sign you need outside technical judgment before committing budget, not after.
The December Spending Spree Trap
Year-end budget-or-lose-it thinking is real in bigger organizations, but small and mid-sized businesses fall into a milder version of it too: a rush to "use up" allocated funds before December 31, buying tools that were never properly scoped just because the money was sitting there.
Every unscoped tool bought in December becomes a January problem: nobody assigned to configure it, no clear owner, and a renewal invoice in twelve months for something half the team forgot exists. If an initiative wasn't ranked and scoped by mid-Q4 using the process above, it shouldn't get funded just because there's budget left. Push it into next year's Q1 review instead, properly scoped.
Reserve Room for the Unplanned
However careful the plan, something unplanned will hit in Q1 or Q2: a security patch, a vendor price increase, a critical bug in a system nobody planned to touch. Budgets with zero slack force a bad choice later: skip the fix, or blow the budget and explain it awkwardly at the next review.
Build in a 5-10% contingency inside the "keep the lights on" bucket specifically for this. It's not padding, it's the same logic as an emergency fund, and it means the technology budget survives contact with reality.
Practical Takeaway
Q4 technology budget planning that works starts in September, not December, and it starts with ranking against real business impact, not vendor sales pages. Protect the 70% that keeps operations running, price initiatives honestly including implementation and maintenance hours, and refuse to fund anything unscoped just because the money is available. Do this once properly and next year's budget conversation gets a lot shorter, and a lot more credible.