An RFQ comes in Monday. By Friday, the proposal engineer is still waiting on a cost estimate. The customer has asked twice. The proposal engineer thinks the cost estimator has it moving. The cost estimator thinks the proposal engineer is still gathering requirements. Both are doing real work most weeks — just not on this RFQ, this week, because neither of them is the one whose name is on the deadline.
It's tempting to call this a coordination problem and fix it with a status meeting or a Slack channel. It isn't a coordination problem. It's a workflow with no owner. Two people assigned to the same deliverable, with no explicit split of who actually delivers it, isn't twice the coverage — it's a deliverable nobody's actually accountable for finishing.
Why "someone's handling it" fails quietly
The failure mode here is specifically quiet. Nobody drops the RFQ on purpose, and nobody's obviously behind — right up until the customer asks a second time and everyone realizes it's been sitting for four days with no single person who was supposed to move it. An RFQ tracker that shows status ("in review," "sent," "awaiting quote") without showing who is accountable for that status changing has the same blind spot as the two inboxes in the story above: it tells you where the RFQ is, not who's supposed to move it forward.
The fix isn't more visibility into status — it's ownership
More status detail doesn't solve this. A more detailed dashboard showing "in review" for six days doesn't tell you anything the proposal engineer and cost estimator didn't already both know — it just makes the gap more visible without assigning anyone to close it. What actually closes the gap is a single name attached to the RFQ from the moment it exists, answerable to the question "who moves this forward" without anyone having to ask.
That name shouldn't necessarily be whoever happened to create the RFQ in the system. The person who logs an inbound RFQ is often not the person best positioned to actually own getting a quote back — that might be a specific cost estimator, a category buyer, or whoever has the supplier relationship already. The important part isn't who the default is; it's that the default is reassignable, and that reassigning it is a two-click action, not a conversation that has to happen out loud for everyone to know it happened.
What this looks like in practice
We built this directly into RFQTrace: every RFQ has an Owner field, separate from who created it, visible as a column right next to the deadline in the RFQ list — the same "one name, one deadline" pairing that actually prevents the Monday-to-Friday gap. Reassigning ownership takes a search-and-select, not a thread. And because it's a real field on the RFQ, not a note in someone's head, anyone on the team can glance at the list and know exactly who to ask — including the person who's supposed to be moving it.
None of this replaces having enough people. It just makes sure that when you do have enough people, an RFQ doesn't fall through the gap between two of them. RFQTrace tracks RFQ ownership the same way it tracks everything else — visibly, for the whole team, not just whoever's currently holding it. Start a free 60-day pilot and put a name on every RFQ that comes in next week.