Tasks and systems

How do you prevent administrative tasks from falling between systems?

Give each handoff one owner, one place with a status, and monitoring for missing follow-up. Software monitors its own integration, not the work.

Piet Baudoin··16 min read

You prevent administrative tasks from falling between systems by giving each handoff one owner, keeping all open handoffs in one place with a status, and monitoring what fails to happen as well as what goes wrong. No software package does that last part for you: Power Automate, Make, Zapier, and n8n each monitor only their own integration.

This page explains why work disappears at the boundary between two packages, what research on hospital handoffs and AI systems says about it, what major automation packages report when a handoff fails, and which three measures work together for a small or midsize business. Assessing incoming email is covered on the page about emails that need manual processing. This page follows the work after that first step, into other systems and to other people.

The short answer

  • Work falls between systems because two things are missing at the boundary: an owner and a signal. Each package knows only its own part.
  • Communication failure contributes to more than 75 percent of serious hospital incidents, according to the Joint Commission (2017). Handoffs are a major cause there, rather than an edge case.
  • In multi-agent AI systems, 31.35 percent of failures come from misalignment between agents, according to 1,642 annotated executions in the MAST study (arXiv, version 3, October 2025).
  • Power Automate sends no failed-run alert if it cannot identify a fix, and never sends one to administrators. Make does not store incomplete runs by default. Zapier turns off a Zap at 95 percent errors over seven days. n8n reports nothing until you build an error workflow.
  • None of these packages sees “forwarded, but nobody picked it up.” That is not an error to any of them, so there is no alert.
  • 88 percent of knowledge workers say time-sensitive projects fell behind or through the cracks (Asana, Anatomy of Work).
  • Three layers together help: one name per handoff, one place with a status, and monitoring of time and missing follow-up. An AI agent can handle the last two. The first remains your decision.

Why do administrative tasks fall between systems?

Administrative tasks fall between systems because each system knows only its own part of the work and nobody owns the transition. Outlook knows an email arrived. Exact, Dutch accounting software, knows which invoices it contains. Neither knows that the email contained an invoice that still needed to go into Exact.

UnifyApps, August 19, 2026 calls this the first break: “Ownership fractures first. The moment a workflow crosses functional boundaries, there is no single system of record.” Then: “At every functional boundary, context degrades.” UnifyApps sells a platform for this problem, but the observation is separate from that product.

Combidesk, which sells integrations, describes a Dutch example through Accountancy Vanmorgen, May 26, 2026. An online store sends the invoice, but, translated: “The payment itself arrives through a different route.” And: “Without a direct connection between the PSP and the accounting package, the system does not know that an invoice has been paid.” The invoice stays open even though the money has arrived.

In an office of twenty people, the boundary is often a person rather than an integration: someone who takes an attachment from Outlook and puts it in Exact, or forwards an email asking “is this for you?” Our page about distributing shared inbox email describes the failure, translated: “what one person opens, another leaves alone because they think it has already been picked up.” An email nobody forwards “has not been handled, it has only been read, and nobody sees that difference until a customer calls.” This describes the mechanism, rather than a measurement.

How large is the handoff problem according to research?

Handoff errors are among the largest sources of failure wherever they are measured. The best measurements come from healthcare and, more recently, research into multi-agent AI systems.

In its Sentinel Event Alert on handoffs, October 2017, the Joint Commission wrote: “Communication breakdowns are involved in over 75% of serious patient adverse events”. The source is older, but concerns people handing work to each other, which has not changed. According to the same alert, one hospital reduced ineffective handoffs by about 60 percent after standardization.

AI agents show the same pattern. The MAST study by Cemri et al., arXiv 2503.13657 version 3, October 2025 annotated “1642 annotated execution traces” across seven frameworks, with inter-rater agreement of kappa 0.88. Failures fall into three groups: design failures, inter-agent misalignment (31.35 percent), and verification. A developer summarizing the paper on DEV Community, August 17 gives 32.3 percent: “Roughly a third of failures are agents failing to communicate correctly with each other”. The difference probably comes from an earlier paper version. Both say: more than a third of failures involve the handoff.

It is visible in offices too. Asana, page dated April 17, 2026 reports that “88% [of knowledge workers] agree that time-sensitive projects and large initiatives have fallen behind or through the cracks”, and “60% of a person’s time at work is spent on work about work”. Asana sells work management software and does not give the survey year. Treat this as a direction, rather than a precise measure.

What do Power Automate, Make, Zapier, and n8n report when a handoff fails?

Power Automate, Make, Zapier, and n8n report only errors within their own integration. None has fully enabled monitoring by default. Assuming automation automatically raises an alarm when work gets stuck means relying on something the makers do not promise.

Package Where a failed run appears Who gets an alert What falls outside it
Power Automate (Microsoft) Run history and a weekly summary of all errors Only the flow owner and co-owners, “never sent to environment admins or tenant admins”; then no new alert for that flow for 28 days Failures without an identified fix produce no alert; per-run alerts are not enabled by default for every flow
Make “Incomplete executions”, but “By default, incomplete executions are disabled” Nobody until you enable it Errors in the first module, runtime overruns, initialization or rollback; when storage is full, Make disables the scenario or discards the run
Zapier Zap History, with “Errored” or “Handled error” status Automatic retries for “temporary issues, like a brief API outage or a server timeout” At 95 percent errors over seven days the Zap turns off; with a custom error handler it never automatically turns off
n8n An error workflow configured for each workflow: “It runs if an execution fails” Nobody until you build the workflow and alert “The Error Trigger only runs when an automatic workflow errors”, so not during manual execution

Sources, all read September 30, 2026: Microsoft Learn, April 3, 2026, updated July 1, 2026; Make, incomplete executions and errors without an incomplete execution; Zapier, troubleshooting and Zapier, error settings, May 29, 2026; n8n, error handling. All four sell the package they describe.

Microsoft provides the most striking sentence: “If the system can’t identify a specific fix for the failure, no per-run alert email is sent. This is by design to ensure that alert emails are actionable”. That is a defensible choice against alert fatigue. It also means an unexpected failure, for which nobody has a fix, stays silent.

Their shared limitation matters more than their differences: each package reports only errors it sees. A successful run delivering a task to someone on vacation is a success to all of them.

Why is building an integration not enough?

Building an integration is not enough because an integration moves data rather than completing work. Our position: a task falls between systems when each package monitors its own part and nobody monitors the rest. Monitoring belongs to the work, rather than the integration.

Put three facts together that nobody has yet combined. First: communication, often at handoffs, contributes to more than three quarters of serious healthcare incidents. Second: more than a third of AI-agent failures involve inter-agent handoffs. Third: the four largest automation packages monitor individual integrations, with defaults that allow silent failures. Together they suggest that automating more handoffs creates more places where work can silently stop, while reducing the chance of a person noticing by accident.

A simple calculation illustrates this. A chain of n systems has n-1 boundaries. Email, Exact, and the bank create two. Add a CRM and payment provider and there are four. The number of places where work can get stuck doubles, while each new integration monitors only itself. This is reasoning, rather than a measurement.

For a small or midsize business, the consequence is practical. Previously, the office manager noticed an invoice was stuck because she retyped it herself. After automation, nobody types it, so nobody notices. More automation without monitoring moves the problem from “forgotten” to “unseen.” What one package can do and what an agent must do between packages is covered on the page about AI agents automating work between software systems.

Who is responsible for a task between two systems or departments?

One named person is responsible, and that name must be recorded before the work reaches the boundary. “If everyone is responsible, nobody is responsible,” writes Creatieve Koppen, translated, referring to MIT Sloan. Filling in a name is not yet ownership, they say. They name five conditions. The third column gives our assessment of what software can enforce.

Condition Meaning Can software enforce it?
One name No “team” or “department” as owner Yes, as a required field
Decision rights The owner can act without first asking permission Partly, through permissions
Capacity The task fits someone’s workweek No, but it can make this visible
Date and first step A set date and concrete first action Yes, with a reminder
Red is allowed Reporting a problem is safe No, that is culture

Creatieve Koppen also warns about “watermelon status”: green outside, red underneath. That is exactly what a successful integration does when the work stays stuck.

British consultancy Elite Project Consulting identifies five fixed task fields: owner, deadline, priority, status, and review point. It sells project management, but these fields are useful in any office.

A second-order effect: making the boundary visible first creates a discussion about who should do what, rather than technology. Expect it. That discussion is the solution, rather than the delay.

How do you organize handoffs so nothing gets lost?

Organize every handoff with the same fixed fields: who has it now, what needs to happen, when it must be finished, and what it is waiting for. In its 2017 alert, the Joint Commission recommends “standardized tools (forms, templates, checklists, protocols, mnemonics, etc.)” and “some way of measuring and monitoring the success of handoffs”. Also: “training and culture are critical to effective handoffs”.

Applied to a bookkeeping firm or installation contractor:

  • What is it waiting for? This field is most often missing. A case “waiting for the customer” differs from a stalled case. Our page about an email missing the attachment or information you need says, translated, that a case “waiting for one missing item goes unnoticed.”
  • Explicitly “not resolved yet.” Pratik Patel lists four handoff measures for AI agents: structured data, explicit marking of uncertainty or open issues, boundary checks, and tracking provenance. The same four apply to people.
  • The original stays retrievable. Summarizing and forwarding email discards context. Keep the source beside the task.

A ServiceNow employee, October 16, 2025 shows what late handoffs cost: teams miss their deadline “because that ticket is being transferred to them super late”. Time disappears in the preceding queue, rather than with the people doing the work.

How do you know which emails, invoices, and cases are stuck?

You know what is stuck by monitoring time and missing follow-up as well as errors. An error alert tells you something went wrong. You need a signal that something did not happen: no reply within three days, no entry after a payment, no response to a request for information.

Three practical rules:

  1. One place for everything open. One overview with an owner and status per handoff, rather than a list per package. While open tasks are spread across Outlook, Exact, and an Excel list, nobody sees the whole picture.
  2. A deadline per type of work. A customer follow-up may take a week; an invoice discrepancy two days. Without a deadline, “late” does not exist.
  3. Escalate to one name, rather than everyone. Group reminders become noise. Microsoft, Work Trend Index, 2025 counted “117 emails daily”, “153 Teams messages per weekday”, and employees “interrupted every 2 minutes during core work hours”; 48 percent find work “chaotic and fragmented”. The report is older and Microsoft sells work software, but another group alert solves none of that.

Packages you can connect are covered in working with your own software. Combining Excel, documents, and email is covered in automating documents, Excel files, and emails with AI.

Can an AI agent monitor whether a task between systems is completed?

Yes, an AI agent can monitor the boundary because it follows work across packages rather than living in one. It can read that an email contains an invoice, check whether the invoice is in Exact, and return if it is still absent after two days. This differs from an integration that reports only its own failures. Whether an agent makes sense for your situation is covered in when an AI agent makes sense.

There is a condition. MAST shows agents themselves make handoff errors, and Camunda, January 2026 reports that 48 percent of organizations use agents “in silos”. 71 percent use agents, but 11 percent put agent applications into production in the past year, and 73 percent see “a significant gap” between ambition and reality. Camunda sells process orchestration. An agent added alongside existing integrations therefore adds another handoff unless it takes responsibility for monitoring the whole.

It works when the agent does three things: executes or prepares the handoff, checks that it arrived, and returns to the owner when nothing happens. Required actions in your packages are covered in AI agents automating work between software systems. Handling the agent’s own mistakes is covered in errors and review.

Where is this heading?

The makers’ documentation shows the pace. Microsoft updated its error-alert explanation in April and July 2026, and Zapier its error settings in May 2026. Both refine monitoring per integration, rather than across integrations. Meanwhile, agent numbers grow: Camunda reports 71 percent usage, but almost half in silos.

Our expectation: by the end of 2027, major packages will offer an overview of open work across packages as well as alerts about their own flows. The reasoning: Microsoft already provides a weekly overview of all failed flows in an environment. The step from “all errors” to “all open tasks” is small once agents work across packages. This expectation would fail if vendors do not expose handoffs to each other, or offices receive monitoring but never configure it, as with Make’s current disabled default. We have not checked whether Exact and AFAS, Dutch business software, already plan this.

By then, with Bombos you will not need to configure monitoring per package. Open handoffs appear in one place in Bombos, with an owner for each task, whatever package is on the other side.

What can this approach not do yet?

This approach cannot create an owner where none exists. If nobody has decided who handles invoice discrepancies, software cannot decide for you. An agent can prepare the question. The decision is yours.

Also:

  • Monitoring cannot see knowledge held only in someone’s head. If “Jan always calls that customer himself” is recorded nowhere, no system can see that it did not happen. Bombos interviews you to record this knowledge for next time.
  • Monitoring takes attention. Every triggered deadline needs a person to look. Too many signals are ignored just like no signals.
  • The figures do not come from small and midsize businesses. Hospital figures and MAST concern different settings. We found no Dutch measurement of administrative work stuck between packages. We could not verify an online claim of 15 to 30 percent lost work because its source was no longer accessible. We therefore do not use it.
  • A visible status is not a completed task. Listing a handoff does not mean someone picks it up. It only shows that it remains open.
  • An agent also makes mistakes. Approval catches many, but guarantees no error-free result. A named person therefore remains responsible for reviewing handoffs.

How does Bombos approach this?

Bombos puts open handoffs in one place and gives each task an owner. Chef, the regular worker distributing incoming work, reads all connected email addresses, recognizes the task, finds the customer and case in your own package, and prepares a proposal for the coworker who normally handles it. Each proposal shows its basis.

You approve, change, or reject in Bombos. Only after approval does Bombos write the result into Exact, AFAS, Twinfield, Dutch accounting software, or another package. Those integrations are routine work. Payments, customer messages, and contracts wait for your approval by default. A correction then becomes a rule, including for your coworkers.

Our pages about the shared inbox and missing attachment describe the process: work left open too long returns to its owner, rather than the whole group. You decide which deadline fits which work.

Your team does more work, at higher quality, with the same people. Closing the boundary is the beginning. Your own team then teaches Bombos the next task without technical skills. The first step for a service business is described in how a service business becomes AI-native. We guide you, then you can do it yourself.

Sources

Each source was opened on September 30, 2026, and each quotation appears literally in it. Dutch quotations above are translated.

Free, no obligation

More work done, at a higher quality, with the same team.

That is what Bombos is for: companies that grow fast and want to keep the same team. We start with one task that keeps piling up and guide you until your team can handle it. Then your team teaches Bombos the next task. Leave your number and we will call you back to talk about your situation.

We read what you write. Within one working day you hear from the one of us who knows your kind of work best.

More about tasks and systems

All questions in the knowledge base →