100% Output. 25% Workforce - Stop Hiring People to Move Information Between Systems - Part 3

Before you approve another hire, look at what you're asking that person to do.

Are they making decisions the business needs? Or are they checking one system, copying information into another and chasing someone to confirm what should happen next?

That second kind of work can fill an entire day. Build enough of it into a process and eventually you need a team. When the volume increases, you hire more people to keep up.

The hiring request sounds reasonable. Everyone is overloaded and customers are waiting.

But the request leaves an important question unanswered: why does serving another customer require someone to move the same information through the same systems again?

In Part 1, I questioned the work the company creates. In Part 2, I argued for organizing around outcomes with someone responsible for delivering them.

Now those people need systems that let them do it.

You cannot expect a much smaller team to own an entire outcome while leaving them to collect the facts, reconcile the records and manually carry out every routine decision.

If every additional customer creates another round of copying, checking and chasing, that is part of the business you need to rebuild.

Your employees are doing the integration

Consider a hypothetical software company.

A customer contacts support because they cannot access a feature they purchased.

The support person opens the ticket. They find the customer in the sales system, read the agreement and ask someone to confirm whether the feature should be enabled. Then they check the product configuration.

The records use different account names, so they ask a colleague whether they are looking at the right customer. Once that is settled, they send an engineer the details. The engineer changes a supported setting. Support checks the result and replies to the customer.

The actual correction was small. Getting to it required several people to reconstruct what the company already knew.

Someone had to establish which records belonged together. Someone had to decide which record was authoritative. Someone had to carry the approved decision into the product.

Those are real responsibilities. A mistake could enable the wrong feature or change the wrong customer's account.

But why should people repeat that investigation every time the same class of problem occurs?

If this is a standard configuration correction, the company should have an agreed way to identify the account, check the entitlement and apply the permitted change.

The employee who currently does that work may be excellent at it. They may catch mistakes that nobody else notices.

Learn from them. Find out which checks matter and which exceptions they recognize. Their knowledge is part of what you need to build into the replacement.

Simply recording their clicks would miss the decisions that make the process work.

A faster answer can leave the work untouched

Now give that support person an AI assistant.

It summarizes the ticket, finds a relevant help article and drafts a polite response. That can be useful. The person still has to establish which account is affected, confirm what was purchased and arrange the change.

Even an assistant that correctly says "this customer needs setting X enabled" may leave most of the operational work with the employee.

Someone still needs to act on the recommendation and verify the result.

This is where I would challenge an AI investment: show me what happens after the answer.

Does the workflow move forward? Does the approved action happen? Does anyone check that the customer's problem is actually resolved?

If a person has to copy the answer into a ticket for another person to execute, include that work in the result you report.

Better access to information is a useful first step. The workforce requirement changes when the process can use that information to complete work reliably.

Decide which records the workflow can trust

Before a workflow changes anything, it needs a dependable account of the situation.

Start with identity. The customer in the support tool must map to the correct account in the product and the correct agreement in the sales system. Similar names are not enough, especially when a customer has several accounts or subsidiaries.

Make those relationships explicit. Do not ask an AI model to guess which account someone meant when a wrong guess could affect another customer.

Then decide where each business fact is maintained.

The product may own the current configuration. An approved entitlement record may define which features the customer can use. The support system may own the history of the reported problem.

Those records can remain in different systems. What matters is that the workflow knows which source to use for each decision.

A sales note saying "we discussed the advanced package" should not grant access to that package. A customer's email saying "this was approved" should prompt a check against the approval record.

Being able to find a statement does not make that statement permission to act.

The information also has to be current enough for the decision. Yesterday's copy of the account configuration may help explain a problem. A change should check the live account before proceeding.

When records disagree, the company needs someone responsible for resolving the disagreement. The system should show them the conflicting evidence and pause the affected action.

You cannot automate a business rule that leadership has never settled by asking the model to choose the most convincing document.

Give the workflow a way to finish

Reading information and changing the business are separate capabilities.

For the support example, the workflow needs specific operations: check the customer's entitlement, inspect the relevant setting and apply an approved correction when the conditions are satisfied.

Each operation should enforce its own limits.

The change should be restricted to the verified customer and the supported setting. It should check the current state before writing and record what changed. If approval is required for that case, the operation should enforce it.

These rules belong in the software that performs the action. They should not depend on the model remembering an instruction in a prompt.

The model may help interpret the customer's description or identify which investigation to start. Ordinary software can check an account identifier, compare a setting with an approved value and reject a change outside the permitted scope.

Use each where it helps. A predictable operation does not become better because a language model performs it.

The same principle applies to access. A support workflow should receive the information and permissions needed for its work. Connecting it to company systems should not give it unrestricted access to every customer record or internal function.

For older tools, some actions may still require using the interface. Treat that as a dependency that needs checking and maintenance. A successful demonstration of clicking through a screen does not establish that the process will keep working after the screen changes.

The practical question is whether the workflow has a dependable way to perform the actions it is responsible for.

Remember what happened when something fails

Suppose the configuration change succeeds but the support tool is unavailable when the workflow tries to update the ticket.

What happens next?

The customer may already have access. The ticket may still say the issue is unresolved. Restarting the whole process could repeat an action that has already happened.

The workflow needs to retain its progress. It should know which action completed, which step failed and what can be retried safely.

That record needs to survive an interruption. It cannot exist only in a conversation that disappears when the process restarts.

It also needs to distinguish an accepted request from a completed result. A system acknowledging a configuration request is not proof that the setting took effect or that the customer can use the feature.

Define a completion check that is meaningful for the task. If the check fails, the case stays open with the evidence attached.

When a person takes over, they should see what was checked, what changed and where the process stopped. Asking them to repeat the entire investigation would waste the work already done.

These details determine whether automation reduces the workload or creates a new job supervising it.

A workflow that requires someone to notice every failure and reconstruct every unfinished case still depends on constant human attention.

What the customer request looks like now

Return to the customer who cannot access the feature.

The request is linked to a verified account. The workflow checks the approved entitlement and reads the current configuration. It finds a mismatch covered by a supported correction.

The action checks those conditions again before changing the setting. The workflow then verifies the result, records the evidence and prepares the customer response under the company's communication rules.

The routine case can proceed within the authority already granted to it.

Now change the situation. The agreement is unclear. The customer has two possible accounts. The approved entitlement is correct but the feature still fails after the setting is fixed.

Those cases need further judgment or investigation. They go to the responsible person with the relevant records and completed checks.

That person can work on the unresolved question instead of spending the first part of the investigation finding the customer and reconstructing the history.

You have removed the routine handoffs from one defined category of support work.

Its value depends on how often it succeeds, how much work remains and whether customers get the result they need.

But it gives you something real to build on. The next workflow can reuse the account mapping and the approved ways to inspect the product. You do not have to teach another team to reconstruct those relationships from scratch.

Shared foundations need shared ownership

This is where a company can create another problem for itself.

Support builds its own customer mapping. Sales creates a separate copy. Finance and support use different meanings of "active customer" without making the distinction clear. Each team connects an agent to its preferred records.

Now the agents can disagree for the same reasons the departments did.

Give someone responsibility for the shared definitions and connections. Make clear who maintains the mapping between accounts, who owns each business fact and who fixes an integration when the source changes.

Outcome owners should still decide how their workflows operate within agreed limits. They should be able to use common capabilities without rebuilding them privately.

That division matters. Shared infrastructure should remove repeated work across teams. It should not become a central group that must approve every ordinary case.

The knowledge used by the workflows also needs an owner. If a product release changes a setting, the instructions and checks that depend on it need to change too.

A process that relies on employees remembering which documentation is wrong still relies on knowledge outside the system.

Document the correction where the workflow can use it. When the same exception appears repeatedly, decide whether the standard process needs to change.

Otherwise, the company will keep paying people to compensate for a known defect.

Build enough to remove one complete piece of work

None of this requires replacing every application before you can start.

I would begin with a recurring request where the necessary records already exist and the permitted action is clear. Identify the missing connections and build enough to complete that request reliably.

Some workflows will mainly need better integration. Others will benefit from AI because the input varies or the investigation requires interpreting unfamiliar material.

Let the work determine that choice.

Do not make a company-wide data cleanup a condition for fixing a narrow process. Equally, do not connect an agent to unreliable records and expect it to resolve every inconsistency on its own.

Set a clear boundary around the cases the workflow can handle. Expand it as the evidence supports doing so.

During the initial rollout, human review may be necessary to establish whether the process behaves correctly. That review is part of the workload. It needs to appear in the calculation.

Measure the human time across the full case, including exceptions, corrections and maintenance. Check whether cases reopen and whether the customer can actually complete the affected task.

Then remove the manual steps that the proven process has replaced.

If an employee must still check every account, update a separate spreadsheet and send the same internal message, the company has kept much of the original work.

The 25% workforce target remains a design challenge. You earn a credible staffing decision by showing how much work the new process requires under real demand.

Make the next hiring request explain the work

There will still be good reasons to hire.

You may need expertise you do not have. Customers may need more personal attention. The volume of difficult cases may exceed the team's capacity.

But "we need someone to stay on top of all this" deserves a closer look.

What exactly will that person spend their week doing? Which decisions require their judgment? Which steps exist because the systems cannot use information the company already has?

Sometimes you will need the person now while you fix the process. Be clear about both needs.

A new hire should not quietly become the permanent answer to a system limitation nobody owns.

The company is already paying for disconnected systems through the time people spend working around them. Compare the cost of fixing that work with the cost of repeating it as the business grows.

That is the decision I want leaders to make before approving the next role built around checking records and chasing updates.

Before you hire another person to keep the systems in sync, make someone accountable for why they aren't.