If People Are the Integration Layer, the Workflow Is Not Native
The Sentence That Won't Leave Me Alone
I've been saying this to myself for weeks now, so I might as well say it out loud. If people are the integration layer, the workflow is not native. Say it again slower. If a human being is the thing standing between one system and another, copying a number from here to there, retyping what somebody already typed, carrying an answer from one inbox to another inbox because the two inboxes don't talk, then the software isn't integrated. The person is. And a person is not a workflow. A person is a person, with a name and a shift and a limit to how many times they can do the same manual thing before they stop seeing the errors in it.
I didn't come up with this from a whiteboard. I came up with it from participating in hundreds of hours of real stories with real operators in this industry, brokers, distributors, repair stations, people who've been doing this for twenty and thirty years. Once you hear it enough times, in enough different voices, from companies that have never talked to each other, you stop thinking it's a coincidence. You start thinking it's the actual shape of the problem.
What Integration Actually Looks Like on the Floor
Here's what it sounds like when a person is doing the integrating instead of the software. One customer, running parts at her own company, told us straight out,
I have a Google Sheet nightmare going on, because I have 27 tabs.
Twenty seven tabs is not a system. Twenty seven tabs is a person holding a system together with their own memory. Another customer put it even more plainly when he talked about his own team:
They're probably spending around 80% of their time, our salespeople doing admin data entry bullshit instead of doing sales.
Eighty percent. That's not an exaggeration for effect. That's a person telling you where his people's actual hours go, and it isn't to the job they were hired for.
The RFQ Screen Nobody Asked to Own
Nowhere does this show up harder than in the RFQ. An RFQ comes in, and somebody has to become the connective tissue between the email it arrived in, the catalog it needs to be checked against, the vendors it needs to go out to, and the inbox where the answer eventually lands. One customer described the exact moment this breaks:
It concerns me that if you've got people adding things to an open purchase order and procurement submits that order to the supplier at four o'clock and at five past four another salesman adds a part, we're not going to find out until two weeks time when the customer screams for his part.
Read that again. The system didn't catch it. A customer screaming two weeks later caught it. That's what it looks like when the workflow relies on a person to be the thing holding two records in sync, and the person, being a person, eventually can't.
Repairs Make It Worse
If you want to see the same problem under more pressure, go talk to a repair station. One customer told us something that I think about constantly:
Technicians hate to do paperwork. Technicians hate to. Technicians hate to use a software. Technicians just want to work on a part.
Another customer at that same repair station gave us the line that says the whole thing in one breath: "So many different workers with so many different parts that we have to source from the work order screen, because that's where we live." That's the tell right there. Not the RFQ screen. Not a sourcing dashboard built for a salesperson. The work order screen, because that's where the actual work happens, and if sourcing doesn't live where the work lives, a person has to carry it there by hand. That same customer said it again a different way later in the conversation:
Before we even get there, we need to price. So we have 40 parts in there, we got to get that priced.
Forty parts, priced by a person, one at a time, before anything else can move.
This Was Never a People Problem
I want to be clear about something, because it's easy to hear all this and think the lesson is that people need to work harder or pay closer attention. That's not it. One customer said it best, and I don't think he meant it as a compliment to his own team, but I hear it as one:
We have none of this right now, none of this. We're so blind. We have no clue.
That's not a person failing. That's a person doing an honest job inside a workflow that never gave them the visibility to succeed at it. Another customer called her own situation
...such a Wild West situation for me, such a rookie. I don't know what I don't know.
She's not a rookie. She's an army of one, in her own words, running a real business, and the tools underneath her never got built for the job she's actually doing. When the system doesn't hold the truth, a person has to become the truth, from memory, under time pressure, every single day. That's not a discipline problem. That's a design problem wearing a person's name.
The Tell Is When the System Asks You to Say It Twice
If you want a simple test for whether a workflow is native or whether a person is quietly integrating it by hand, ask this. Does anybody in this process have to type the same information more than once. One customer told us plainly what he wants for his own team:
My shipping and receiving guy, you know I don't want them to go through 20 tabs. I want them to be able to just kind of make it really smooth.
Another customer named the actual cost of not having that:
I can't have people spending 2, 2, 3 hours trying to create all this with all the possibility for human error.
Two to three hours, and every one of those hours carries the chance of a wrong number, a wrong condition, a wrong part landing on a certificate it shouldn't be on. That's the real price of asking a person to be the integration layer in an industry where a mistake doesn't just cost time, it can cost a signature nobody should have signed.
The Tell Is When the System Asks You to Say It Twice
Native doesn't mean automatic in the sense of nobody's watching. It means the workflow already knows what it needs to know, in the place a person is already standing, without asking them to go get it from somewhere else first. It means the RFQ, the work order, the vendor quote, and the part history are the same record, not four records a person has to reconcile by hand. One customer, who's been doing this for thirty years, said something that stuck with me because it wasn't marketing language, it was just relief: "Spending a great deal of time up front saves a whole lot of time downstream."
That's the whole idea. Connect it once, at the start, so nobody has to redo it by hand for every part, every quote, every work order after.
We Built the System So People Could Stop Being the Glue
This is where I'll bring in what we actually do about it, because I've spent this whole piece describing a problem I've watched real operators live with, and I don't think it's honest to stop there. When an RFQ lands, whether it's a clean line item or a scanned PDF or forty lines pasted into an email, rapid intake reads it and turns it into a structured record the moment it arrives, instead of waiting for a person to retype it. From there, sourcing from work order means the part search doesn't live somewhere a technician has to go find. It lives on the work order itself, because that's where our customers told us people actually live, and that's exactly where we put it. ELIA, our embedded layer of intelligence, sits on top of that same connected record and helps with the judgment calls, what to price something at based on what actually won before, which vendor has actually delivered on time, where a quote is walking into risk nobody flagged yet. iRFQ is the part that makes sure the answer, once it exists, reaches everyone who needs it, not just the one person who happened to send the original request, which is exactly the gap that let three salespeople chase the same part for three different customers without ever knowing a vendor had already answered.
None of this replaces the person. It removes the part of their day where they weren't actually doing their job, they were just holding two systems together by hand. One customer, talking about where he wanted his own operation to end up, said it about as well as anyone has: "The way I see this really coming together, we're gonna have 30 plus parts, I need to be able to plug and play people in here." Plug and play people, not plug and play spreadsheets. That's the difference between a workflow that's native and one that only looks finished until you ask a real operator to actually run it.
So here's the question I'd leave you with, the same one I keep asking myself. Look at your own operation, honestly, and find the place where a person is quietly doing the work your software should be doing for them. Once you see it, you can't unsee it. And once you can't unsee it, the only real question left is whether you're going to keep asking that person to be the integration layer, or whether you're finally going to build the workflow that lets them just do their job.
If any of this sounded a little too familiar, I'd like to hear about it. Reply and tell me where in your own operation a person is quietly doing the job your software should be doing for them. That's usually where the real conversation starts.
About ERP.Aero:
ERP.aero is an aviation parts and MRO operating system built by people who did this work themselves, not software engineers guessing at it from the outside. It connects RFQs, sourcing, work orders, and vendor quotes into one native record instead of asking your team to hold it together by hand. If any of this resonated, we're happy to just show you how it works, no pressure.
​