What would it take to finish the work across departments?

A team improves the way work moves from A to B. Another team improves B to C. Each has a useful result to show. Between them, someone still gathers the missing information, explains the context again, and asks whether the next step has happened.

That person may be making a necessary decision. They may also be carrying work across a boundary that the organization has simply inherited.

We recommend examining those boundaries before choosing the next automation project. Start with the business outcome, then follow the work far enough to establish what completion requires. That can reveal opportunities to carry a process through several departments, with human judgment placed at the decisions that need it.

Make room for a broader possibility: a workflow that gathers the information, carries out permitted steps, and verifies completion without somebody initiating every handoff. The first design question becomes what it would take to get from A to C. Helping teams see that possibility, and agree on a workable way to pursue it, is valuable work in its own right.

Agree what completed delivery means

Consider a hypothetical company onboarding a new customer after a signed agreement. Sales supplies the commercial commitments. Operations prepares to deliver the service. Finance establishes the billing requirements.

Each department can have a reasonable definition of done. Sales has recorded the agreement. Operations has created a setup task. Finance has received a request to open an account. The customer could still be waiting for a confirmed start date.

Bring those teams together around a specific outcome: the customer is ready to begin the agreed service. Define the evidence that would establish that state. For this example, it might require approved delivery requirements, confirmed capacity and start date, validated billing details, and a named contact who has communicated the next step to the customer.

Separate readiness from later outcomes. An account marked ready does not establish that service has been delivered or payment collected. Those need their own completion criteria. A useful workflow has a boundary the participating teams can test.

This exercise also exposes conflicting assumptions. Perhaps sales records a requested date that operations treats as confirmed. Perhaps finance needs an approved billing milestone that neither team supplies. Those disagreements belong in the design conversation before the system is asked to move work faster.

Examine what each handoff carries

Take one handoff and ask the person doing it to explain the work. They may be copying known information, interpreting a commitment, making a decision, or checking whether something actually happened. A single email can contain all four.

For the hypothetical onboarding process, transferring an approved customer identifier into another system is an information task. Resolving a conflict between the promised start date and available capacity is a business decision. Confirming that the billing setup succeeded requires evidence from the receiving system.

Give each activity an explicit treatment. Known information may be transferred through an ordinary integration. A proposed interpretation can be presented with the relevant source for review. A commercial exception needs an authorized person. A completion check needs a reliable record of the result.

Keep the people doing today’s coordination in this conversation. Their informal checks may explain why a process has avoided errors. Ask which checks protect the outcome, which compensate for missing information, and which exist because nobody can see the next department’s status. This is useful operating knowledge to preserve as the workflow changes.

Choose how the work should proceed

An agentic workflow uses a model to help decide which permitted action to take next. Anthropic’s engineering guidance distinguishes agents that direct their tool use from workflows that follow predefined paths, and recommends starting with the simplest adequate solution. Building effective agents.

Apply that distinction to the work in front of you. If every complete agreement follows the same approved setup sequence, a fixed workflow may be sufficient. Better intake fields or clearer decision rights may resolve the problem before any new software is needed.

An agent may be worth testing when cases need different steps: locating relevant information, identifying a missing requirement, choosing among permitted checks, and carrying the result forward. The test is whether it can perform those tasks reliably within agreed permissions and at an acceptable operating cost.

In our hypothetical example, a bounded agent could be designed to assemble the onboarding record, flag inconsistent commitments, create authorized setup tasks, and check their status. When a date conflict appears, it would present the evidence to the responsible owner. It would continue only after the required decision was recorded, then verify the remaining readiness conditions.

The authority stays explicit throughout. Finding a conflict does not grant permission to rewrite a contract, promise a new date, or release an invoice. The workflow needs a defined way to wait, escalate, and resume without treating silence as approval.

Make the shared outcome worth owning

A workflow can cross departmental boundaries while the incentives remain local. If sales is measured only on the speed of its handover, operations on the number of tasks created, and finance on requests processed, nobody’s measure necessarily shows whether the customer is ready.

Agree on a shared result and inspect the burden on each team. For the example, track elapsed time from signed agreement to verified readiness, alongside the effort spent by sales, operations, and finance. Include clarification requests, corrections, unresolved exceptions, and time spent reviewing the system’s work.

Consider a proposed change that removes a form from sales but leaves operations reconstructing the missing information. That is a redistribution of effort to examine. Let both teams see the evidence and agree on the adjustment. Departmental participation should include a say in what gets measured and how problems are resolved.

Name one accountable owner for the overall workflow and retain the relevant decision owners within it. Specify who resolves an exception that spans departments, how long it may wait, and who covers an absence. The overall owner needs a route to resolve conflicting priorities; a title without that authority leaves the same coordination problem in place.

These are design recommendations to test. The hypothetical example establishes no savings, reduced delay, or customer result.

Leave the organization able to operate the work

The definition of completion, decision rights, and exception ownership need to survive beyond the people who first designed the workflow. Keep them accessible to the teams using it, together with the evidence for each case’s current state.

Ask a receiving operator to inspect an incomplete case. They should be able to explain what remains, whose decision is needed, and what would allow the work to proceed. Ask the participating departments to review a completed case against their shared criteria. Record where they disagree or need help.

That is part of capability transfer: the organization can understand, operate, and improve the work after the initial delivery effort. As requirements change, it can revise the completion criteria and check the effect across all participating teams.

At Northbeam Solutions, helping departments shape a workable outcome is one part of our strategy, architecture, delivery, and capability-transfer work. Start with one process whose next step repeatedly needs chasing. Bring its owners together and define the result they are collectively responsible for finishing. If that scope needs clarification, explore the Rapid Assessment.