Business systems owner
The person who owns the system the business runs inside — the CRM or order system: how the process is shaped in it, whether its records still mean anything, and what the numbers coming out of it are allowed to claim.
This is not a probability of losing your job. It combines how much of the role's task load is exposed to automation with how far adoption has actually gone — useful for comparing occupations on one consistent basis, and for nothing else.
The internal owner of a company's CRM, order or workflow system — often called sales ops, revenue operations or business systems, and in smaller firms simply the CRM team. Not the vendor's support desk, and not a software engineer building the product the company sells: this role configures, governs and explains a system somebody else built.
The evidence base holds verified records for other occupations, but not one for this one yet. Until it does, the analysis below is reasoning about task structure and known technical capability — for this job in particular it is not backed by traceable sources, and we would rather say so than cite things we have not verified. An empty section here is a gap in our coverage, not a finding about the work.
What is actually changing#
The unit of analysis is the task, not the job title. A role is not replaced — its task mix shifts.
Shaping the process inside the system
Being augmented≈ Platform inferenceTurning how the business actually works into stages, fields, rules and permissions — and deciding what the system will refuse to let someone do.
Building the configuration got much cheaper: describing a workflow in words and getting the objects and automations back is squarely what these tools do. Knowing which of the described steps is the one people actually skip, and why, did not — that is learned by watching the team, not by reading the process document.
Faster configuration means more configuration, not less work. Every rule added is a rule that will later be wrong and have to be found — so the role's hours move from building to untangling, and untangling is invisible on a roadmap.
Keeping the records worth trusting
Automating≈ Platform inferenceDuplicates, half-filled fields, statuses nobody updates, three spellings of the same customer — finding them and deciding which version is the real one.
Matching records that refer to the same real thing is entity resolution, and it is one of the clearest places current models beat rules — they handle the messy cases string matching never could. Deciding which duplicate survives when the two disagree on a number that matters is still a business call.
Cleaner data makes everything downstream more trustworthy, which is the point — and it also removes the only visible artefact of this job. Nobody notices records that were never wrong, so the work reads as an absence, which is a poor position when the budget is set.
Deciding what the system may decide alone
New task≈ Platform inferenceWhich actions the automation takes without a person — assigning an owner, scoring a lead, sending a message, closing a record — and what happens when it is unsure.
When the system only stored what people did, this decision did not exist. Now that it acts, someone has to set the boundary, and the person who understands both the configuration and the business consequence is this one. The duty arrived with the capability and was assigned to nobody.
Setting the boundary is not the same as being allowed to hold it. This role usually has the knowledge and not the authority: when sales wants the automation to send more, the person who can say no is further up, and being overruled repeatedly is how the boundary erodes without any decision ever being recorded.
Making the numbers mean something
Automating≈ Platform inferenceBuilding the reports management steers by, and being the one who knows which of those numbers is solid and which is held together by an assumption.
Writing the query and drafting the commentary are both commodity now, and asking a question in plain language and getting a chart back removes most of the request queue this role used to carry.
Self-service reporting does not remove the person who knows the number is wrong. It multiplies the number of people confidently quoting a figure whose caveat they never saw — so the work shifts from producing reports to correcting them in meetings, which is slower and harder to defend as a headcount.
Getting the team to use it properly
Still human-led≈ Platform inferenceTraining, answering the same question for the fifth time, and finding out that the reason a field is always empty is that filling it costs someone twenty seconds they do not have.
In-product help and assistants answer the how questions well. They cannot answer the why-should-I question, which is the one that actually determines whether the field gets filled — and that answer requires knowing what the person is measured on and being able to change it.
This is the first task cut when the role is under pressure, because it produces nothing shippable. Cutting it does not show up as a problem for two quarters, and then shows up as data nobody trusts — by which time the cause is no longer attributable.
Which technologies matter here#
Four separate signals. They are deliberately not added together — a job exposed to two technologies is not twice as exposed.
How it got here#
The index is not a static number. This is where it would have sat at each capability checkpoint since ChatGPT — reconstructed, and labelled as such.
● 1 verified event for this occupation, plotted at the date it happened — the parts of the line near a marker are anchored to something checkable.
A high start, because the system this job owns is itself the automation of an older way of working — CRMs replaced the filing cabinet and the spreadsheet decades ago, and the role was created to run that replacement. The 2023-2024 step is configuration and reporting becoming things you can ask for in words. It flattens after 2025 for a reason worth noticing: what remains is not technically hard, it is organisationally hard — knowing why a process is shaped the way it is, and which numbers are load-bearing. That knowledge lives in people and in arguments, not in the system, so no amount of capability reaches it.
A flat line is not a forecast of safety. It says which tasks automation has reached so far — the occupations that moved least here are the ones where the constraint is physical or regulatory, and both of those can change.
Recent changes#
The EU, and only for deployers of high-risk AI systems. What it establishes is that on the input side of these systems, clean data has moved from an internal good habit to a legal obligation — and in most companies the party controlling that input data is the person who owns the system. Article 26(1) additionally requires deployers to use such systems in accordance with the instructions for use that accompany them, which puts how the system may be used on a documented footing too. What it does not establish: the law names no job title and does not require a dedicated data owner, so attaching the duty to this occupation is our inference about where it lands in practice. It also covers only systems classified as high-risk, not every system a company runs.
Regulation, subsidy or public procurement is requiring or funding adoption — the mirror of a constraint. It shows adoption is being required, not that it has happened, so one mandate is never enough on its own; two independent ones are.
What this means for you#
This has been one of the reliable ways into a commercial career without a technical degree: learn the system, become the person who knows where everything is, move into operations or analysis. The learn-the-system part is exactly what assistants now do well, so the rung has thinned. What is still scarce, and still learned only by being there, is knowing why the process is shaped the way it is — including the parts that exist because of an argument three years ago.
You are the only person who knows which numbers are load-bearing and which are decoration, and that knowledge is not in the system you administer. The risk is that your value looks like maintenance from outside: when the data is clean and the reports run, the work is invisible, and invisible work is what gets outsourced to the vendor's support plan.
Your options#
Four directions, each with its real constraints and one thing you can test this week. Continuing as you are is a legitimate choice — it just has to be a chosen one.
Own an outcome, not an instance
Administering a system is a cost line; moving a business number is not. The systems owners who stay are the ones whose remit is stated as the number the system exists to move, with the configuration as the means rather than the job.
It means being accountable for a number other people also affect, and giving up the defensible position of having done exactly what was asked.
Write down the three numbers your system is supposed to move and where each one currently stands. If you cannot fill in the second column without asking someone, you are administering an instance rather than owning an outcome — and that gap is the whole conversation.
Write down what the automation may do
Now that the system acts rather than records, someone has to set and hold that boundary. You are the only person who can see both the configuration and the business consequence — and in most companies this has been settled by default rather than decided.
You will be overruled by whoever owns the revenue number, repeatedly. A boundary without a written rule and a named approver erodes quietly, and the erosion is only visible after an incident.
List every automated action your system takes today without a person: assignments, scores, messages, status changes. Mark each one fine, should be reviewed, or should never have been automatic. Bring three counts, not an opinion.
Move to the function you have been serving
You already know a function's process in more detail than most people working in it, because you encoded it. Sales, finance and operations all now need someone who understands both the work and the system it runs in.
You trade a position where correctness is provable for one where judgement is argued, and you will be junior in domain terms for a year even though you know the plumbing better than anyone.
Take the last ten change requests you received from one team and write what each was really trying to achieve, underneath what it asked for. If your version is consistently better than theirs, you already understand their job — which is the whole case.
Cross into data governance
Whose record is authoritative, what a field is allowed to mean, who may change it and what gets logged — those questions are becoming a function of their own as more decisions get made automatically from that data, and you have been answering them informally for years.
It is a policy job with a compliance flavour, measured over years rather than sprints, and it exists as a funded role mainly in regulated industries or companies large enough to have been burned.
Pick the one field in your system that most decisions depend on and try to write its definition in two sentences — what it means, who may set it, when it is wrong. Then show it to two people who use it. If they disagree with each other, you have found the job.
Common questions#
The parts that are building and fetching — configuring objects, cleaning duplicates, writing the query behind a report — are automating quickly, and they are a large share of the week. The part that is not is knowing why the process is shaped the way it is and which numbers are load-bearing. Expect fewer of these roles, held by people closer to the business, and expect the first cut to be the person who only administers.
Count the requests. Take the change and report requests your team received last quarter and compare them with the same quarter a year ago. If the count has fallen while the business has not shrunk, the self-service tooling is absorbing your queue — and that shows up a year or more before anyone reconsiders the headcount. What it does not tell you is whether the requests stopped or just stopped reaching you, so check where they went before you read the drop either way.
It removes the queue and keeps the liability. More people now quote figures whose caveats they have never seen, and you remain the only person who knows which ones are held together by an assumption. That is more valuable work and less visible work at the same time — so the practical move is to make the caveats part of the report rather than part of your memory.
Yes for ranking, carefully for anything that closes a record or sends something out, and never without writing down what happens when it is unsure. The expensive failures in this job are not wrong scores, they are silent state changes: a record closed, an owner reassigned, a message sent, each of which looks like a normal row afterwards. Decide the boundary in writing while nothing has gone wrong, because after an incident it gets decided for you.
Method and sources#
- Assessment date
- 2026-09-11
- Basis of the task judgements
- 0 evidence-backed · 5 platform inference · 0 not enough evidence
- Verified events
- 1