Nobody Decided Not to Bid
Tuesday, 10:40 in the morning. An RFQ lands in the shared inbox. Nine line items, two of them need vendor pricing before anybody can put a number on the page. Somebody opens it. Somebody reads it. Somebody leaves it, because there are forty orders that have to be in the ERP before cutoff, and an order beats a quote every time.
Wednesday it is below the fold. Thursday it is gone.
Nobody decided not to bid. There was no pricing debate, no walk down to the sales manager's desk, no call on whether this one was worth chasing. The decision never got made, because there is no place where decisions like that get made.
And everybody involved behaved correctly. The person who chose the orders over the RFQ made the right call with what was in front of them. Which is exactly why a rule aimed at that person will not fix this.
EVERY OTHER QUEUE IN YOUR BUILDING HAS A SYSTEM
Orders: in the ERP within hours. A number, an owner, a status, and somebody notices if it stalls.
Open quotes: in the CRM, with a follow-up date and a spot in the pipeline review.
Support issues: in a ticket queue, with an SLA and an escalation path.
A request for a price that arrived by email: in an inbox. That is the whole system.
The request becomes trackable the moment somebody turns it into a quote. So the one stage where it is most likely to die is the only stage with no record, no owner and no status. That is not a discipline problem. It is a gap in the design.
Harvard Business Review ran an audit of 2,241 US companies, sending each one a sales inquiry and timing the reply. 37 percent answered within the hour. 24 percent took more than a day. 23 percent never answered at all. Those were inbound web leads rather than RFQs from accounts with a customer number, so it is not your benchmark. It is useful for exactly one thing. None of those 2,241 companies thought they were in the 23 percent.
A buyer collects three bids. Miss once and you are one of two next time. Miss twice and you are off the list, and none of that generates a phone call. Meanwhile the account keeps reordering its stock items, so it never trips a churn flag and never lands in an at-risk report. What stopped was the growth. You find out about two years later.
This Week, Try This: Put a Watch on the Mailbox
Three parts. Most people build the first one and skip the third, which is why it never lasts.
1. The tracker, and where it lives
Put it in Google Sheets or Excel on the web, in a shared drive. Not a file on somebody's desktop, and this is not a style preference. Rows have to be appendable by an automation while a person has the sheet open, which rules out anything local. And this queue has never been visible above the order desk. Put it somewhere a sales manager can open without asking anyone for it, and the first time somebody outside the desk sees a count of undecided requests, it stops being the CSR's problem.
We built the template. Three tabs: the tracker itself, a This Week tab that counts what matters, and a setup tab with the classifier prompt sitting on it. Download it, drop it in Drive or SharePoint. Nothing to sign up for.
Two rules make it work, and neither one is in the file.
Owner is never blank. It defaults to somebody. A queue that waits for a volunteer is not a queue.
“Declined to bid” is a status, and it is a good one. The tracker's job is not to force a quote onto every request. It is to force a decision onto every request. Below minimum, a product you do not carry, a bid list you would rather not be on: ten seconds and a reason is a complete and successful outcome. The only defect is a row still sitting on New.
2. The classifier
The easy cases are not the problem. “Please quote the attached” is trivial. What gets missed:
- A PO with one line that is not on contract. Part order, part quote request, and it goes in as an order with the odd line quietly dropped.
- “While you're at it, can you price out...” in the fourth paragraph of a reply about something else.
- A re-quote arriving as “is this still good?” against a quote that expired six weeks ago.
- An RFQ forwarded in by a rep with no context and no ask.
- Anything that needs vendor pricing. Highest value, most likely to stall, because it cannot be closed in one sitting.
One rule on tuning, and it matters more than the wording of the prompt. Over-include. A row that should not be there costs ten seconds to dismiss. A row that never appears is the entire subject of this newsletter. Unclear goes in the tracker flagged, not filtered out.
Read every message below. For each one, decide whether it
is a request for a price, and return one row per message.
A request for a price includes: an RFQ or bid request, "can
you quote", "what would X cost", "is this price still
good", a request to re-quote something that expired, a
request for pricing on a quantity break or an alternate,
and a purchase order that contains any line that is not on
contract pricing.
It also includes a price question buried inside a message
that is mostly about something else. Read the whole
message, not the subject line.
It does NOT include: order status questions, expediting
requests, invoice or credit questions, vendor solicitations
sent to us, marketing mail, or an order where every line is
already on contract.
For each message return:
- is_price_request: yes / no / unclear
- evidence: the exact sentence you based that on, quoted
- account: the customer company, or unknown
- requester: name and email
- asking_for: one sentence, plain language
- needs_vendor_pricing: yes / no / unclear
- customer_date: any date the customer stated, or blank
- attachment: filename if the message has one, else blank
- confidence: high / medium / low
Rules:
- When you are unsure, return unclear, not no. A row that
should not be here costs ten seconds to dismiss. A row
that never appears is the problem this exists to solve.
- If the message has an attachment you cannot read, return
unclear and name the file. Do not guess at its contents.
- Never infer a price request from the sender's role or the
account's history. Only from the text.
- Do not merge two requests from the same account into one
row. One message, one row.
- If a message contains both an order and a price request,
return it as a price request and say so in asking_for.
3. The watch
This is the part that keeps the tracker alive, because rows appear whether or not anybody is having a good week. Claude Cowork will run it on a schedule.
If you are a Google shop: connect Gmail and Google Drive from the connectors menu.
If you are a Microsoft shop: connect Microsoft 365, which covers Outlook, OneDrive and SharePoint together. A Microsoft Entra global administrator grants one-time tenant consent for your organization, and on Team or Enterprise plans a Claude owner enables the connector first. It needs a work or school account. Personal outlook.com addresses will not work.
Then, either way: click Scheduled in the left sidebar, New task, Set up manually. Name it, paste the prompt below, point the working folder at wherever the tracker lives, and pick a frequency. Hourly, daily, weekly, weekdays and manual are the options. Start on weekdays each morning, in an approval mode that shows you the rows before it writes them. Move to hourly once you trust it.
Every run, do this.
1. Search the mailbox for messages received since your last
run. If you have no record of a last run, use the past
24 hours.
2. Open the Quote Request Tracker in the working folder and
read the Tracker tab so you know which messages are
already logged. Never log the same message twice. Match
on the email link.
3. For each new message, apply the classifier prompt on the
Setup tab of that file.
4. Append a row for every message that came back yes or
unclear. Fill Received, Account, Requester, Link to
email, What they're asking for, Needs vendor pricing,
and Customer need-by. Set Status to New. Set Owner to
the default owner named on the Setup tab. Leave Decision
date, Quote # and Value blank.
5. Do not modify any row that already exists. You append
only. People edit the rest by hand.
6. Post a short summary: how many new requests you logged,
which accounts, and any row still marked New that is
past the threshold on the Setup tab. List those by
account and days open. If there are none, say so in one
line.
Two things to know before you build it.
Attachments. Plenty of RFQs are two lines of text and a PDF. The Google connector gives Claude metadata for attachments rather than their contents, so the prompt above logs any message with an attachment as unclear and records the filename. That still turns an invisible request into a row with an owner, which was the point. Handle it the same way on Microsoft until you have tested what comes through.
Shared mailboxes. This is where the two stacks differ, and Microsoft comes out ahead. The Google connector reads the mail of the single account you authenticate, so either connect the account that actually receives the RFQs or filter a copy into one Claude can see. Microsoft 365 picks up shared mailboxes through the delegate permissions you already have configured, with no extra setup.
Turn it on Monday. By Friday you have a number nobody at your company has ever had, and nobody had to go back through last quarter to get it.
An Honest Take
Every company I have watched try this starts with the spreadsheet and nothing else, and the spreadsheet is dead within a month. Not because the team lacks discipline. Because a tracker that depends on a person noticing something is subject to the exact failure it was built to catch. The person too busy to quote the RFQ is also too busy to log the RFQ they are too busy to quote. You cannot fix a capacity problem with a form.
So build the watch or do not bother with the tracker.
And the deeper version, which is what I actually think. An order and a quote compete for the same person, and the order wins every time. Correctly. The order is revenue you already earned with a customer already waiting. The quote is revenue you might earn. Anybody triaging that queue makes the same call, and they should. Which means the durable fix is not making people value the quote more. It is ending the competition. Take the order entry off the desk and the quotes get answered as a side effect, with no new rule and no new meeting.
That is what we sell, so weigh it accordingly. The logic holds regardless of who you buy it from.
One smaller thing. Nobody in your building is measured on requests answered. Order accuracy, entry time, error rate, backlog, all measured and reviewed. Requests received against requests decided, measured nowhere.
The Bottom Line
The revenue here is not in a new market or a new territory. It is in requests that already arrived, from buyers who already picked up the phone, at accounts that already have terms and a credit line. The cheapest revenue in the building, and the only kind with nobody assigned to it.
There are requests sitting in that mailbox right now. The question is not what you missed last quarter. It is whether anything is watching this week.
Logging the request is the easy half.
The tracker tells you a quote is owed. It does not price anything, and the two suppliers who did answer are getting faster at that part every quarter.
We're running a live workshop on using Claude to build the quote itself, working from the customer's request against your price file and your rules. Real messy inputs, not slides.