Give the budget to someone who can change the work.
Imagine a sales team drafting proposals with AI. Some colleagues prepare several a day; others mainly review them. A shared service also prepares background material overnight. Dividing the monthly pot equally among employees is simple, but the allowance can run out for the person handling the busiest queue while money assigned to occasional users sits untouched. This is an invented situation, not a report of a MING client.
We would first agree what the team is funding and who can adjust it. The sales lead can prioritise proposals; the system owner can investigate repeated requests; Finance can approve a change to the allowance. A budget needs those decisions attached to it. FinOps guidance similarly connects approved funding with a defined scope, accountable owners and a process for exceptions.[S2]
| Budget unit | When it helps | What needs a separate decision |
|---|---|---|
| Person | Someone controls their own optional use within an approved tool. | Shared workloads and unusually busy roles need an exception route; consumption is not an individual performance score. |
| Team | A lead can move capacity between colleagues doing related work. | Identify which tasks used the money so a busy shared service does not hide inside one total. |
| Use case | A recurring service has a clear owner, workload and accepted result. | Agree how shared licences, support and review time are assigned, including any amount kept centrally. |
These units can coexist. For the proposal team, we suggest a team envelope with a separate usage allowance for the shared service. Personal experimentation can have its own smaller, bounded pot. Use the least detail that still lets the owner explain a change in spending. FinOps describes several ways to allocate shared costs, including explicitly central funding; it does not prescribe one universal split.[S3]
The remaining proposals reveal a gap before the allowance is exhausted.
Suppose the team has an approved monthly envelope of €3,000: €1,200 for fixed access, €900 for variable model usage, €600 for human review and €300 held in reserve. Every amount is chosen to explain the method. Review funding does not guarantee that people have time available. This is a limited operating example, excluding setup, taxes and other costs; use the full running-cost answer to decide which items your own budget needs.[S1]
Midway through the month, the usage records show €540. Another €30 relates to requests already made but not yet included in that figure. The owner estimates €450 for the remaining planned proposals. Those are three separate amounts: no request appears in more than one. The estimate includes expected retries; it is not a multiplication of a token price by employee count.
| Assumed monthly usage calculation | Amount |
|---|---|
| Recorded usage | €540 |
| Already incurred, not yet recorded above | €30 |
| Estimated remaining work | €450 |
| Expected total: 540 + 30 + 450 | €1,020 |
| Approved usage allowance | €900 |
| Expected gap: 1,020 − 900 | €120 |
The team has €570 of recorded and pending usage, yet already expects to exceed the €900 allowance. A warning tied only to most of the money being spent would miss this decision. Our proposed rule is to review a forecast overrun when it becomes visible, while retaining a consumption alert that leaves enough time to react. Neither the figures nor a particular percentage is a recommended limit.[S1]
Approve the extra work before releasing the reserve.
The system owner first checks what changed. More proposals may justify more funding; repeated failures call for investigation. The sales lead then confirms which remaining proposals still matter and whether the review capacity exists. If useful work needs another €120, the request names that work, the forecast, the proposed transfer and its expiry at month end.
In this example, Finance is the chosen approver. Approving €120 moves the usage allowance to €1,020 and leaves €180 in reserve. The total envelope stays €3,000: €1,200 + €1,020 + €600 + €180. Record the decision and update the forecast. If the request is declined, the sales lead prioritises or reschedules the work and agrees the alternative with the people affected. A reserve is not permission to keep spending without that decision.[S1]
Set a response time and a deputy when agreeing the budget. A proposed next-working-day response may suit internal drafting; it can be far too slow for a live customer service. If no approver responds, follow the previously agreed pause or fallback rule instead of treating silence as approval. Our token-cost comparison can help investigate inefficiency without quietly lowering the required quality.
Check whether the provider warns, pauses or keeps charging.
An approved budget is an internal agreement. A provider control has its own behaviour. Google Cloud explicitly says its alerts-only budgets do not automatically cap spending.[S4] Its separate spend cap budgets can pause new usage for an eligible service in one project, but enforcement is not instant; in-flight requests and some persistent costs can continue.[S5] Do not turn either feature into a promise that the final invoice cannot exceed a chosen amount.
For the proposal service, document which requests a limit would block, how the team sees unfinished work and who may change the setting. Test the stop and restart behaviour in an authorised safe environment before relying on it. A finance approval to release €120 does not itself change a provider limit. The authorised operator must make and verify that technical change separately.
At the next review, compare the forecast with the bill and the work accepted for use. Return unneeded reserve through the agreed process. A low bill with an unanswered proposal queue is not success, and spending every euro is not evidence of useful adoption.
Evidence and limits
- The team, amounts and approval example are invented. They illustrate allocation and arithmetic, not a MING price, recommended allowance, saving or tested operating result.
- The example covers fixed access, variable usage, planned review funding and a reserve. It excludes setup, taxes and other costs and assumes review capacity is checked separately.
- FinOps provides budgeting and allocation guidance. Google documents its own controls as read on 21 October 2026; other providers and account arrangements need their own checks.
Take one shared AI task to the person who owns its budget. Put the current allowance, remaining work, pending charges and approval route on the same page. That is enough to find out whether the next problem is a funding decision, waste to investigate or work that should wait.
