The Internal Request Layer Is the Most Under-Observed Part of Your Stack

Emily Mabie
Zapier

Last year, there was a day where I spent 20 minutes just figuring out what someone actually wanted. The Slack message said "need access to the thing." The follow-up email said "for the project." The ticket they finally opened said "urgent." Nowhere in any of those three places did they say which system, which project, or why it was urgent. By the time I had the full picture, I could have completed three actual requests. For awhile, it was a part of my job nobody saw, and it turned out I wasn't alone.

I spent a chunk of this spring digging into how widespread that confusion is, and the numbers surprised me. We surveyed roughly 800 project managers and operations professionals regarding how their organization's internal requests are processed. 63% said their team had experienced delayed or lost revenue because of missing or delayed internal requests. 30% reported both.

Revenue is leaking out of the seams between systems that were never wired to talk to each other.

The Intake Layer Is Invisible, and That's the Problem

If you work in APM or observability, you already know the drill: make the invisible visible. Trace requests, find the bottleneck, put a light on it. The internal request layer is that bottleneck. Nobody's instrumenting it. Nobody's dashboarding it. And it's where a meaningful slice of operational drag lives.

In the survey, 54% of teams said they field requests across three or four channels. Email, Slack, a ticketing system, a project tool, sometimes a form, sometimes a DM that says "hey can you." 93% said those requests routinely arrive with missing information. Almost half (48%) said the most common gap is a clear description of what's actually being asked for.

So, before any work happens, someone has to read the request, figure out what it means, find the missing pieces, and route it to whoever owns it. 42% of ops professionals said they spend 6 to 15 minutes organizing a single request. Another 32% spend more than 15. Just to figure out what the request is.

If a service in production was adding 15 minutes of latency to every call, you'd page someone. The internal request layer adds that kind of latency to human work every day and nobody alerts on it.

Fewer Surfaces, Faster Work

The finding I keep coming back to is what happens when teams consolidate intake.

Teams using one or two request platforms were 81% more likely to process a request in under five minutes than teams using three or more. 49% of teams on one or two platforms said they'd never lost revenue to missing or delayed requests, compared to 25% of teams on three or more.

Cutting your intake surface in half roughly doubles the share of teams who say they've never lost revenue to this problem. The reason is pretty intuitive once you've sat with it. Every additional channel is another place a request can land, another format it can arrive in, another assumption about what counts as "complete," another inbox to check. The cost of triage scales with the number of surfaces, not the number of requests.

When I first saw the 81% number, I thought it was overstated. Then I mapped my own team's intake. We had requests coming through Slack DMs, a shared inbox, a project board, a recurring meeting, and the occasional hallway ask (or the remote equivalent, which is a meeting that should have been a ticket). We collapsed it to two surfaces with a clear intake form behind them and the noise dropped almost immediately. The work didn't get easier. The cleanup tax went away.

The Mental Load Shows up in Your Error Rates

36% of project managers and operations professionals said the mental fatigue of managing requests outweighs the effort of actually completing the task. 44% said they consistently chase updates and approvals. 41% spend their day chasing updates and approvals. 41% get interrupted by follow-ups and forced context switches.

That's a context-switching tax — the same coordination overhead we measure in distributed systems, except the coordination is happening inside people's heads.

This matters for IT and ops leaders for a practical reason. When the cleanup tax is high enough, people start cutting corners. They skip the clarifying questions. They guess at what the requester was asking for. They mark something resolved that's only partially complete. Mistakes at the intake layer don't show up as intake errors. They show up downstream as escalations, reworking of previous work, missed SLAs, and discussions around "why things didn't get done."

If a request falls through the crack, 46% of survey participants stated that another colleague or supervisor had to intervene. 31% noted that other requests were delayed because of the backlog from the first request. 29% reported burnout from their respective teams.

Those are the second-order costs of an intake layer that nobody's watching.

What Good Looks Like

A few things hold up across the teams that handle this well.

They treat intake as a system. The teams who consolidated didn't pick one tool and force everyone to use it. They left the surfaces people actually use in place (you're not going to talk a sales team out of Slack) and built a layer underneath that captures, normalizes, and routes the request wherever it landed. The user-facing experience stayed familiar. The operational experience changed.

They write down what "complete" means. The single biggest gap in incoming requests was a clear description of what was being asked for. The teams who fix this define, per request type, the minimum information needed before the work can start, and they make the intake layer responsible for collecting it. If you've ever written a good runbook, you already know how to do this.

They measure the cleanup. Most ops dashboards count tickets closed. The teams pulling ahead are also measuring time to first meaningful action, percentage of requests that need clarification before work begins, and how often a request gets routed to the wrong owner. Those metrics tell you whether your intake layer is doing its job, or whether your team is silently paying for it.

They use AI for the pattern-matching parts. Classifying a request, extracting the relevant fields, routing it to the right queue, drafting a clarifying question when something's missing. This is the kind of work AI is genuinely good at, and it's the work that's costing people the most time. The judgment calls about priority and ownership still belong to a person. The triage in front of those judgment calls doesn't have to.

Why This Is an APM-Adjacent Problem

The discipline is the same.

You don't fix latency by telling engineers to be faster. You instrument the path, find where time is being spent, and address the specific bottleneck. The internal request layer needs the same treatment. Your team's effort isn't the bottleneck. The bottleneck is a coordination problem the team is absorbing because nobody's pointed a tool at it.

Half of task-focused leaders in our survey handle at least 26 internal requests in an average workday. A quarter handle 51 or more. At that volume, every minute of triage compounds. And unlike a slow service, it doesn't trigger an alert. It shows up as people who feel like they're working hard and falling behind anyway.

The companies pulling ahead aren't throwing more people at the problem. They're instrumenting the part of the stack they'd been pretending wasn't there. They're measuring the cleanup, not just the output. And they're treating intake like what it actually is: a coordination layer that either works for you or costs you, every single day.

Emily Mabie is AI Automation Engineer at Zapier

Related Links

Hot Topics

The Latest

Beyond Buy vs. Build: The New Playbook for Data Pipelines

While organizations want to take control of their telemetry, building telemetry pipelines from scratch can be a very daunting, complicated task, even when leveraging open-source standards like OpenTelemetry. It requires specialized knowledge across distributed systems, data engineering, and security. This fragmented approach across systems causes higher operational costs; it puts a strain on resources and reduces efficiency as teams have to work with different interfaces and processes ...

The Corporate Network Is Fading - Here's What Replaces It

For decades, enterprise networks were designed around a simple assumption: work happened inside the office. Applications lived in centralized data centers, employees connected through internal infrastructure, and security focused on protecting the perimeter that surrounded everything ... But the way organizations operate today bears little resemblance to that environment. Cloud platforms host critical applications, employees connect from homes and airports as often as they do from offices, and partners collaborate through shared systems that exist far beyond corporate walls. In short, the corporate network no longer resembles the environment it was designed to protect ...

IT Leaders Must Establish a Network Data Architecture Practice

As an analyst who researches how IT organizations design, build, and operate their networks, I find that network data is a constant source of pain. Network teams struggle with data quality, fragmentation, authority, access, and trust. And these issues undermine everything they try to do. Here are the numbers: Only 45% of network teams are completely confident in the accuracy of their network source of truth, which documents the intent of their network ...

Data Center Outages Are Decreasing but More Costly

The 2026 Global Data Center Survey from Uptime Institute reveals an industry navigating workforce constraints, escalating outage expenses, even as rising costs remain the top concern for management teams ...

Observability Has a Physical Layer Now: What AI Infrastructure Teaches IT Operations

The next observability gap may not be in the code. It may be under the rack. That sounds strange until you think about how AI incidents actually feel in the middle of an investigation ... The application dashboard may be accurate. It may also be stopping at the wrong boundary. AI systems depend on software, but they also depend on a dense physical stack: racks, power paths, thermal margin, maintenance activity and, in many environments, liquid cooling. Those physical dependencies can change slowly before they look like a software incident ...

TLS Certificate Expiration Is Becoming an Observability Problem

Certificate expiration is the rare outage you can see coming. Every TLS certificate carries the date it stops working, so the moment it will begin breaking connections is knowable in advance. That's what makes an expired certificate such a frustrating way to lose a service. What's changing now is how often that date comes around ...

Enterprise Cloud Observability: Choosing the Right Starting Point

Enterprises operate different combinations of workloads across cloud, hybrid and multicloud environments. For business-critical workloads, teams need to consider monitoring and observability early so they can detect health issues, investigate failures, and understand operational impact. Organizations place workloads on cloud platforms based on a combination of technical requirements, economics, existing dependencies, organizational standards, and business priorities. Their monitoring priorities therefore depend on what they operate and where those systems run. Those priorities will not look the same for every organization ...

AI Is Making Incident Management More Complex - Bad Data Makes It Harder

Top-performing businesses prioritize data-driven decision making, enabling leaders to move from intuition and gut feel towards evidence-based judgment. But that judgment is only sound when the data underpinning decisions is accurate. With incident management, data accuracy is particularly important. Long-term revenue, customer trust, and operational stability depend on high-quality data that enables teams to quickly identify and address the root cause of major incidents. Against this backdrop, governance becomes a critical endeavor to ensure the right data drives the right action ...

MEAN TIME TO INSIGHT Podcast - Episode 26: Network Compliance

In MEAN TIME TO INSIGHT Episode 26, Shamus McGillicuddy, VP of Research, Network Infrastructure and Operations, at EMA discusses network compliance ... 

Why VM and Container Monitoring Is Not Enough for Cloud-Hosted Autonomous Agents

Most production autonomous agents do not run in a vacuum. They run inside cloud infrastructure: virtual machines, containers, pods, managed clusters or private servers. That is where most operations teams start monitoring. Is the VM alive? Is the container running? Did the pod restart? Is memory stable? Is CPU too high? Did the health check pass? Those signals are useful. They tell you whether the shell around the agent is alive. They do not tell you whether the agent inside is actually operational ...

The Internal Request Layer Is the Most Under-Observed Part of Your Stack

Emily Mabie
Zapier

Last year, there was a day where I spent 20 minutes just figuring out what someone actually wanted. The Slack message said "need access to the thing." The follow-up email said "for the project." The ticket they finally opened said "urgent." Nowhere in any of those three places did they say which system, which project, or why it was urgent. By the time I had the full picture, I could have completed three actual requests. For awhile, it was a part of my job nobody saw, and it turned out I wasn't alone.

I spent a chunk of this spring digging into how widespread that confusion is, and the numbers surprised me. We surveyed roughly 800 project managers and operations professionals regarding how their organization's internal requests are processed. 63% said their team had experienced delayed or lost revenue because of missing or delayed internal requests. 30% reported both.

Revenue is leaking out of the seams between systems that were never wired to talk to each other.

The Intake Layer Is Invisible, and That's the Problem

If you work in APM or observability, you already know the drill: make the invisible visible. Trace requests, find the bottleneck, put a light on it. The internal request layer is that bottleneck. Nobody's instrumenting it. Nobody's dashboarding it. And it's where a meaningful slice of operational drag lives.

In the survey, 54% of teams said they field requests across three or four channels. Email, Slack, a ticketing system, a project tool, sometimes a form, sometimes a DM that says "hey can you." 93% said those requests routinely arrive with missing information. Almost half (48%) said the most common gap is a clear description of what's actually being asked for.

So, before any work happens, someone has to read the request, figure out what it means, find the missing pieces, and route it to whoever owns it. 42% of ops professionals said they spend 6 to 15 minutes organizing a single request. Another 32% spend more than 15. Just to figure out what the request is.

If a service in production was adding 15 minutes of latency to every call, you'd page someone. The internal request layer adds that kind of latency to human work every day and nobody alerts on it.

Fewer Surfaces, Faster Work

The finding I keep coming back to is what happens when teams consolidate intake.

Teams using one or two request platforms were 81% more likely to process a request in under five minutes than teams using three or more. 49% of teams on one or two platforms said they'd never lost revenue to missing or delayed requests, compared to 25% of teams on three or more.

Cutting your intake surface in half roughly doubles the share of teams who say they've never lost revenue to this problem. The reason is pretty intuitive once you've sat with it. Every additional channel is another place a request can land, another format it can arrive in, another assumption about what counts as "complete," another inbox to check. The cost of triage scales with the number of surfaces, not the number of requests.

When I first saw the 81% number, I thought it was overstated. Then I mapped my own team's intake. We had requests coming through Slack DMs, a shared inbox, a project board, a recurring meeting, and the occasional hallway ask (or the remote equivalent, which is a meeting that should have been a ticket). We collapsed it to two surfaces with a clear intake form behind them and the noise dropped almost immediately. The work didn't get easier. The cleanup tax went away.

The Mental Load Shows up in Your Error Rates

36% of project managers and operations professionals said the mental fatigue of managing requests outweighs the effort of actually completing the task. 44% said they consistently chase updates and approvals. 41% spend their day chasing updates and approvals. 41% get interrupted by follow-ups and forced context switches.

That's a context-switching tax — the same coordination overhead we measure in distributed systems, except the coordination is happening inside people's heads.

This matters for IT and ops leaders for a practical reason. When the cleanup tax is high enough, people start cutting corners. They skip the clarifying questions. They guess at what the requester was asking for. They mark something resolved that's only partially complete. Mistakes at the intake layer don't show up as intake errors. They show up downstream as escalations, reworking of previous work, missed SLAs, and discussions around "why things didn't get done."

If a request falls through the crack, 46% of survey participants stated that another colleague or supervisor had to intervene. 31% noted that other requests were delayed because of the backlog from the first request. 29% reported burnout from their respective teams.

Those are the second-order costs of an intake layer that nobody's watching.

What Good Looks Like

A few things hold up across the teams that handle this well.

They treat intake as a system. The teams who consolidated didn't pick one tool and force everyone to use it. They left the surfaces people actually use in place (you're not going to talk a sales team out of Slack) and built a layer underneath that captures, normalizes, and routes the request wherever it landed. The user-facing experience stayed familiar. The operational experience changed.

They write down what "complete" means. The single biggest gap in incoming requests was a clear description of what was being asked for. The teams who fix this define, per request type, the minimum information needed before the work can start, and they make the intake layer responsible for collecting it. If you've ever written a good runbook, you already know how to do this.

They measure the cleanup. Most ops dashboards count tickets closed. The teams pulling ahead are also measuring time to first meaningful action, percentage of requests that need clarification before work begins, and how often a request gets routed to the wrong owner. Those metrics tell you whether your intake layer is doing its job, or whether your team is silently paying for it.

They use AI for the pattern-matching parts. Classifying a request, extracting the relevant fields, routing it to the right queue, drafting a clarifying question when something's missing. This is the kind of work AI is genuinely good at, and it's the work that's costing people the most time. The judgment calls about priority and ownership still belong to a person. The triage in front of those judgment calls doesn't have to.

Why This Is an APM-Adjacent Problem

The discipline is the same.

You don't fix latency by telling engineers to be faster. You instrument the path, find where time is being spent, and address the specific bottleneck. The internal request layer needs the same treatment. Your team's effort isn't the bottleneck. The bottleneck is a coordination problem the team is absorbing because nobody's pointed a tool at it.

Half of task-focused leaders in our survey handle at least 26 internal requests in an average workday. A quarter handle 51 or more. At that volume, every minute of triage compounds. And unlike a slow service, it doesn't trigger an alert. It shows up as people who feel like they're working hard and falling behind anyway.

The companies pulling ahead aren't throwing more people at the problem. They're instrumenting the part of the stack they'd been pretending wasn't there. They're measuring the cleanup, not just the output. And they're treating intake like what it actually is: a coordination layer that either works for you or costs you, every single day.

Emily Mabie is AI Automation Engineer at Zapier

Related Links

Hot Topics

The Latest

Beyond Buy vs. Build: The New Playbook for Data Pipelines

While organizations want to take control of their telemetry, building telemetry pipelines from scratch can be a very daunting, complicated task, even when leveraging open-source standards like OpenTelemetry. It requires specialized knowledge across distributed systems, data engineering, and security. This fragmented approach across systems causes higher operational costs; it puts a strain on resources and reduces efficiency as teams have to work with different interfaces and processes ...

The Corporate Network Is Fading - Here's What Replaces It

For decades, enterprise networks were designed around a simple assumption: work happened inside the office. Applications lived in centralized data centers, employees connected through internal infrastructure, and security focused on protecting the perimeter that surrounded everything ... But the way organizations operate today bears little resemblance to that environment. Cloud platforms host critical applications, employees connect from homes and airports as often as they do from offices, and partners collaborate through shared systems that exist far beyond corporate walls. In short, the corporate network no longer resembles the environment it was designed to protect ...

IT Leaders Must Establish a Network Data Architecture Practice

As an analyst who researches how IT organizations design, build, and operate their networks, I find that network data is a constant source of pain. Network teams struggle with data quality, fragmentation, authority, access, and trust. And these issues undermine everything they try to do. Here are the numbers: Only 45% of network teams are completely confident in the accuracy of their network source of truth, which documents the intent of their network ...

Data Center Outages Are Decreasing but More Costly

The 2026 Global Data Center Survey from Uptime Institute reveals an industry navigating workforce constraints, escalating outage expenses, even as rising costs remain the top concern for management teams ...

Observability Has a Physical Layer Now: What AI Infrastructure Teaches IT Operations

The next observability gap may not be in the code. It may be under the rack. That sounds strange until you think about how AI incidents actually feel in the middle of an investigation ... The application dashboard may be accurate. It may also be stopping at the wrong boundary. AI systems depend on software, but they also depend on a dense physical stack: racks, power paths, thermal margin, maintenance activity and, in many environments, liquid cooling. Those physical dependencies can change slowly before they look like a software incident ...

TLS Certificate Expiration Is Becoming an Observability Problem

Certificate expiration is the rare outage you can see coming. Every TLS certificate carries the date it stops working, so the moment it will begin breaking connections is knowable in advance. That's what makes an expired certificate such a frustrating way to lose a service. What's changing now is how often that date comes around ...

Enterprise Cloud Observability: Choosing the Right Starting Point

Enterprises operate different combinations of workloads across cloud, hybrid and multicloud environments. For business-critical workloads, teams need to consider monitoring and observability early so they can detect health issues, investigate failures, and understand operational impact. Organizations place workloads on cloud platforms based on a combination of technical requirements, economics, existing dependencies, organizational standards, and business priorities. Their monitoring priorities therefore depend on what they operate and where those systems run. Those priorities will not look the same for every organization ...

AI Is Making Incident Management More Complex - Bad Data Makes It Harder

Top-performing businesses prioritize data-driven decision making, enabling leaders to move from intuition and gut feel towards evidence-based judgment. But that judgment is only sound when the data underpinning decisions is accurate. With incident management, data accuracy is particularly important. Long-term revenue, customer trust, and operational stability depend on high-quality data that enables teams to quickly identify and address the root cause of major incidents. Against this backdrop, governance becomes a critical endeavor to ensure the right data drives the right action ...

MEAN TIME TO INSIGHT Podcast - Episode 26: Network Compliance

In MEAN TIME TO INSIGHT Episode 26, Shamus McGillicuddy, VP of Research, Network Infrastructure and Operations, at EMA discusses network compliance ... 

Why VM and Container Monitoring Is Not Enough for Cloud-Hosted Autonomous Agents

Most production autonomous agents do not run in a vacuum. They run inside cloud infrastructure: virtual machines, containers, pods, managed clusters or private servers. That is where most operations teams start monitoring. Is the VM alive? Is the container running? Did the pod restart? Is memory stable? Is CPU too high? Did the health check pass? Those signals are useful. They tell you whether the shell around the agent is alive. They do not tell you whether the agent inside is actually operational ...