Your best operator should not be the integration layer.

The job that never appears in the job description

There is a familiar pattern in growing teams. One person knows which spreadsheet is current, which customer needs a different reply, and who to message when a record is incomplete. Their formal role might be operations, sales or finance. Their informal role is making everything connect.

Picture an example coordinator who reads an enquiry, searches the CRM, checks a diary, asks a colleague for availability and writes the same update in two places. The visible task is booking a meeting. The hidden task is reconstructing enough context to make the booking safe. Automating only the final calendar entry leaves most of that work intact.

Separate valuable judgment from repeated transport

Do not start by asking how to remove the operator. Ask which parts of the work depend on their judgment and which parts simply depend on their memory. Knowing that a customer needs a careful conversation is judgment. Remembering to copy an approved address into a second system is information transport.

For one week of representative work, have the process owner record the handovers they make. Keep the exercise proportionate: source, destination, missing information and what they decided. Do not turn it into minute-by-minute employee surveillance. The useful output is a map of the process, not a ranking of people.

Give each handover a small contract

A handover becomes easier to improve when both sides agree on what is required. What event starts it? Which fields are necessary? Who receives it? What proves it arrived? What happens when the information is wrong? These questions apply whether the sender is a person, a rule or an AI system.

In the example meeting workflow, a complete handover might include contact details, purpose, availability, timezone and an accountable owner. If the timezone is absent, the system should ask or route the case. Guessing creates a polished-looking record that the next person still has to repair.

• Name the record that everyone should trust.
• Define required information and acceptable formats.
• Name the receiver and the fallback owner.
• Record acceptance, rejection and unresolved cases.

Build around the operator’s knowledge

The person doing the work should help define the exceptions. They often know why a field is left blank, why a request goes to a particular colleague, or why an apparently redundant check exists. Removing that check without understanding it can transfer effort somewhere less visible.

Review a few ordinary cases and a few difficult ones together. Describe the decision in plain language before translating it into system behavior. The useful question is not whether the model can imitate an experienced operator in a demonstration. It is whether the team can understand, correct and own the process once it runs.

Measure whether the dependency actually shrinks

After the pilot, look for fewer context-rebuilding moments. Can another authorized colleague see why a task is waiting? Can the process continue when the usual coordinator is away? Does a receiving team get complete information more often? These are practical tests of a more resilient operation.

Keep an eye on work displaced rather than removed. A system that creates a large review queue might save copying time while adding more judgment calls. Count that review effort. A useful outcome is a smaller number of better-framed decisions, with enough information to resolve them.

Start with the Workflow Mapping Kit. Use it with the person who knows the unofficial process. Their experience is the design material; the automation should give them more room to use it.