An ICT service provider consists of layers of work that have little to do with each other. There is the building and maintenance of code, there is the resolving of tickets and incidents, there is architecture and design, there is project management towards the client, and there is presales: proposals, proof of concepts, technical substantiation of a tender. Between these categories the hours differ enormously per assignment. A support department runs on volume and repetition. An architecture team runs on a small number of people with a lot of experience. The outcome of a deal is steered by which of these layers the client weighs most heavily, and that differs per tender, per client, and per moment in the project.
The three categories that play everywhere — AI takes over the task, AI works towards it with a human who approves or rejects, or the work remains human work — run straight through the ICT sector, and not evenly. Ticket handling for known problems can partly be automated; the initial triage, recognising a pattern, putting forward a solution from earlier cases. Code generation for routine pieces of software is shifting towards AI with a reviewer who approves the output. Architecture decisions, the translation of a vague client wish into a working system, and maintaining trust with a client remain, for now, human work, because this requires judgement that cannot be derived from a pattern in existing data.
The shift this causes is not about whether AI is good at coding. It is about what happens to the comparison between suppliers once part of that work does itself. Response time on support used to be a result of staffing and planning; if triage largely runs automated, speed is no longer proof of a good team, but of a well-configured system, and that system can just as easily be bought or built by competitors. What then remains as a distinguishing factor is not the speed itself, but what happens in the cases where the system does not solve it — who does get through those and who leaves a client waiting.
The same pattern is present in proposal processes. Assembling a technical proposal from existing components is work that can partly be automated. Once this happens at multiple parties in a tender, it shifts where a client still sees a difference: not in the speed of the proposal, but in whether the proposal is correct for this specific situation, and in who can explain that without falling back on a template.
Whether an ICT company has already organised this way depends on where it puts its people. A party that still largely deploys its experienced architects on writing standard code has little capacity left for the conversation with the client where the deal is decided. A party that has already shifted that work — AI for the routine part, people for the judgement — has freed up those hours for exactly the part on which is now being won. That is not a choice made within a quarter; it follows from earlier decisions about tooling, about who does which type of work, and about how much trust an organisation has in the oversight of automated output. What an employer does with its workforce in this respect is up to the employer; separate statutory requirements apply to that, apart from the question of which work is technically transferable.
This dynamic is not unique to ICT. The same shift — from volume and speed to judgement and explanation — plays out differently in financial services, where advice and risk assessment are the point of leverage, and differently again in construction, where planning and calculation are shifting but execution on the building site remains human work. The question of which work in this specific company has already shifted and which has not can be answered with a [work scan that assesses per task whether AI takes it over, partly takes it over with oversight, or does not](https://ftetoai.nl) — a separate step, apart from the comparison with competitors.
The risk of this shift is not that a supplier loses, but that it does not know on what. A proposal that claims to be faster, a website that promises stability, a sales pitch that leans on expertise — those are all claims, and claims are only an advantage if they can be substantiated against what a client sees elsewhere. Anyone who has established a lagging position on a dimension can read about the options at an approach for closing a gap on a specific dimension, and anyone who wants to make a claim solid before a client asks about it will find at a review of your own quality claims for substantiation how to do that systematically.
Identify what your company believes it wins on — speed, price, expertise, reliability — and test which of those claims you can support with evidence today against a competitor. That is exactly what the free dimension check does: not a full benchmark, but an initial picture of which claims stand firm and which are still hanging loose. The full competitive benchmark, with an evidence matrix per dimension, is under development.