People as the integration layer

The most expensive work in many businesses is the work that falls between systems, and it is usually being done by people.

  1. 01

    One event

    An opportunity is marked as won in the CRM.

  2. 02

    Context

    Validate that the CRM record has everything downstream systems need

  3. 03

    Interpretation

    Create the customer account and billing terms in the ERP

  4. 04

    Rules

    Set up the project or subscription in the delivery system

  5. 05

    System action

    File the signed contract and create renewal reminders

  6. 06 · Human authority

    A person decides

    outside automated authority

  7. 07

    Outcome

    actioned, recorded, visible

Illustrative example · Closed deal to live customer · not a client project, no result claimed

The problem

People as the integration layer

A deal closes in the CRM. Someone creates the customer in the ERP, sets up the project in the delivery tool, adds the contract to the document system, tells finance to raise the first invoice and adds the customer to the support platform. Each system is fine on its own. The handovers between them are manual, and every manual handover is a place where information is delayed, duplicated or lost.

This is not one big process but dozens of small ones: onboarding a customer, onboarding a supplier, launching a product, closing a period, offboarding an employee. Each one touches several systems, has an informal checklist and depends on someone remembering the steps. When that person is busy or leaves, the process silently degrades.

  • The same customer or product entered into several systems by hand01
  • Handover checklists kept in documents, heads or chat threads02
  • Records that disagree between systems03
  • Delays at each handover, not in the work itself04
  • Nobody able to say where a multi-step process currently is05
  • Processes that depend on one person knowing the sequence06

The system response

What a cross-system workflow can do

  1. 1. Carry one event through every system

    When something happens in one system, a workflow can perform the corresponding steps in every other system in the right order, with the right data, and confirm each one.

  2. 2. Reconcile records continuously

    Customer, supplier and product records can be compared across systems and discrepancies raised as they appear rather than discovered at month-end.

  3. 3. Translate between formats

    Where systems disagree about how data should look, a workflow can map and validate the fields so each system receives what it expects.

  4. 4. Make the process visible

    A multi-step process can be shown as a single tracked item with its current stage, owner and history, replacing the checklist in someone's notebook.

  5. 5. Handle the unstructured parts

    Where a step involves reading an email, a contract or a form, AI can extract what the next system needs, with a person confirming when confidence is low.

  6. 6. Recover from failure safely

    If a system is unavailable or a step fails, the workflow can pause, retry within limits and alert a person, rather than leaving a half-completed process nobody knows about.

Example workflows

Example workflows

These example workflows show the shape of cross-system work that can be built. They are illustrative only and do not describe any client's systems.

Record · 01 · illustrative

Closed deal to live customer

Trigger. An opportunity is marked as won in the CRM.

  1. 01Validate that the CRM record has everything downstream systems need
  2. 02Create the customer account and billing terms in the ERP
  3. 03Set up the project or subscription in the delivery system
  4. 04File the signed contract and create renewal reminders
  5. 05Register the customer in the support platform
  6. 06Confirm each step and present the completed onboarding to the account owner

Human authority · The account owner confirms the commercial details before the ERP account is created, and finance approves the billing setup before the first invoice can be raised.

SYSTEMSCRM · ERP · project or subscription system · document storage · support platform
STEPS6 automated
DATAillustrative
HOLDa person decides

Record · 02 · illustrative

New supplier onboarding

Trigger. A department requests a new supplier.

  1. 01Collect the supplier's details and documents through a single form
  2. 02Extract and validate registration, tax and bank information
  3. 03Run the checks your policy requires and route for approval
  4. 04Create the supplier in the ERP and procurement system
  5. 05Notify the requester and the finance team

Human authority · Finance approves every new supplier and verifies bank details through an independent channel before the record is activated for payment.

SYSTEMSERP · procurement system · intake form · email · document storage
STEPS5 automated
DATAillustrative
HOLDa person decides

Record · 03 · illustrative

Record consistency check

Trigger. A scheduled daily run, or a change to a master record in any connected system.

  1. 01Compare customer, supplier and product master data across systems
  2. 02Identify conflicts and classify them by likely cause
  3. 03Correct the cases that follow an agreed rule
  4. 04Raise the rest for a data owner with both versions shown

Human authority · A named data owner decides the conflicts the rules do not cover. Every change to a record has an explicit authority behind it, either a rule the business agreed or a person.

SYSTEMSCRM · ERP · product or catalogue system · reporting tool
STEPS4 automated
DATAillustrative
HOLDa person decides

Explicit rules, visible exceptions

Human authority · explicit thresholds, named owners

Cross-system work is mostly deterministic: if this happened, do these things. That is a good thing, because rules are predictable, testable and easy to explain. AI is used only at the points where something has to be read or interpreted, and a person confirms anything the system is unsure about. Decisions above the financial or contractual thresholds the business sets go to a named person; routine changes within policy run on their own.

Sometimes the honest recommendation is to reduce the number of systems rather than connect them. If two tools do the same job, integrating them entrenches the duplication. Part of our work is saying which connections are worth building and which problems are better solved by removing a system.

Questions about this area

Do we need to replace any of our systems for this to work?

Normally not. The approach is to connect the systems you already run and to automate the handovers between them. Replacing a system is a separate decision, and if we think one is warranted we will explain why rather than assume it.

Where does AI come into a workflow like this?

In a limited and specific way. Most steps are rules and integrations. AI is used where a step needs to read a document, an email or a form and turn it into structured data, and those steps are the ones with a human check on low-confidence results.

What happens if one of the systems goes down mid-process?

The workflow pauses at that step, retries within agreed limits and alerts the owner if it cannot complete. Nothing is left half-done without someone knowing, and the process resumes from where it stopped rather than starting again.

How do you avoid building something fragile that breaks when a system changes?

By keeping each connection small and well defined, by validating data at every boundary, and by monitoring the workflow so a change in one system is noticed as a failed step rather than as bad data appearing somewhere weeks later.

Where is capability hiding in your business?

Bring one workflow that costs your team more time than it should. We will tell you honestly whether AI, automation or a better system belongs there.