When the human is the UI
The human is the UI is a useful mental model is this: the vendor’s humans are the user interface.
Connections

Other articles exploring a different angle of Top-down FinOps and personification
- When good top-down structure is on the other side
- When the human is the UI
- AWS sells to the tribe, not the board
- Borrowed leverage: partners, resellers, and the myth of ‘direct’
The context
- Audience: leaders who think escalation is a strategy.
- Situation: ‘Our account manager will sort it’ becomes a dependency.
- Decision on the table: how to engage vendors without outsourcing accountability.
A useful mental model is this: the vendor’s humans are the user interface.
They are there to help you navigate the system. They are not the system.
This sounds obvious until you watch how many organisations behave as if the person on the call can rewrite contracts, bend pricing, and override policy by force of charm.
In large companies, the power of the individual is limited on purpose.
That is the point of a system. It scales. It is consistent. It reduces risk. It also reduces flexibility.
So when you have an ‘enterprise negotiation’ and it feels like there is almost no room to move, you are not imagining it. You are hitting a machine designed to minimise exceptions.
The human can explain the policy, interpret the rules, and suggest paths. They can also advocate internally. Sometimes they can unlock small concessions. Often they cannot.
And even when they can, they will do it for reasons that match their incentives.
This is the moment where top-down FinOps needs to be slightly unromantic.
Sales people are not there to help you spend less. They are there to help you spend in a way that keeps you as a customer, and ideally increases your lifetime value.
That is why ‘help’ often arrives in the shape of an upgrade.
Need better outcomes? Try a managed service. Need higher availability? Try the premium tier. Need someone dedicated? Buy enterprise support. Need cost optimisation? Let’s talk about a new commitment vehicle.
Some of these are genuinely valuable. The point is not that they are bad. The point is that they are commercial moves, not favours.
So what do you do with this?
First, stop asking for kindness. Ask for mechanisms.
Instead of ‘Can you look after us?’, ask:
- ‘What is the policy here?’
- ‘What are the options the policy allows?’
- ‘What is the escalation path, and what evidence do we need?’
- ‘What is the timeline of decisions on your side?’
- ‘Which levers are commercial, and which are technical?’
Second, map decision rights explicitly.
Top-down FinOps fails when vendor relationships replace internal governance. If your cost outcome depends on a vendor person being unusually helpful, you do not have an operating model. You have a pen pal.
Write down who owns:
- commitments and duration risk
- support tier choices
- contract renewals and negotiation stance
- architectural trade-offs that increase cost
- decommissioning and workload hygiene
If you cannot name an owner, the system will choose one for you. It will usually be ‘whoever shouted last’.
Third, buy attention deliberately.
If you need a dedicated person, treat it like any other investment. Measure it.
- What do you expect for that spend?
- What is the alternative if you do not pay?
- Which outcomes become faster, safer, or more predictable?
Finally, keep a clean boundary between relationship and responsibility.
It is fine to have a good relationship with your account team. It is even helpful. But it is not a substitute for procurement discipline, architectural clarity, or internal accountability.
The human is the UI. Your job is to understand the system behind it, then build your own system to meet it.