Managing bid invitations from PlanHub, BuildingConnected, and Procore

Ask an estimator at a mid-sized flooring or specialty sub where their bid invitations live and the honest answer is: in the inbox. Not in a system — in the inbox, alongside supplier quotes, RFIs, submittals, and everything else. The invitations that get bid are the ones that happened to be near the top when someone had time to look.

Why the inbox loses

Three structural problems, none of which are solved by being more organized:

1. The sender is almost never the general contractor

This is the one that breaks every home-grown system. An invitation to bid a Turner project does not arrive from anyone at Turner. It arrives from a relay address — something like `notifications@planhub.com` or a per-thread alias such as `728832@message.planhub.com`. The GC's actual name appears only in the display name or the body of the message.

So any rule built on the sender address — an Outlook rule, a Gmail filter, a spreadsheet column for "who sent this" — files three different GCs' invitations under "PlanHub." Your bid list ends up organized by the platform rather than by the client, which is the opposite of useful: you never bid a platform, you bid a GC, and win rate is only meaningful per GC.

2. The same project arrives three times

A GC posts to PlanHub, invites through BuildingConnected, and copies you directly. An addendum drops and every channel re-notifies. A second estimator at the same GC sends their own invite. You now have five emails about one job, with the project name spelled three different ways: "T.F. Green — Expansion of Parking," "TF Green Parking Expansion," and "Green Airport Pkg Expansion."

Handled by hand, this goes one of two ways: you log it five times and your pipeline value is inflated by 4x, or someone deletes four of them and occasionally deletes the one carrying the addendum.

3. Nothing distinguishes urgent from noise

A bid due Thursday and a courtesy notice for a job in another state look identical in a list of subject lines. The information that would let you triage — due date, square footage, location, whether this GC has ever awarded you anything — is inside the attachments, not in the inbox view.

What a working intake process looks like

1. 1
   Consolidate to one mailbox

   Every platform notification, every direct invite, one destination. Not one per estimator — one shared address the whole desk can see. Invitations sitting in a departed estimator's personal inbox are the single most common cause of a missed bid.
2. 2
   Resolve the real client on arrival

   Pull the GC from the display name or the message body and store it as a proper field, separate from the sending address. Store the relay address too — you will need it to reply — but never let it stand in for the client.
3. 3
   Extract the four fields that drive triage

   Project name, location, bid due date, and scope/size. Those four decide whether the job is worth a takeoff. Everything else can wait until you have decided to bid.
4. 4
   De-duplicate before it hits the list

   Match incoming invitations against what is already open by project name, address, and client — not by subject line, which changes with every addendum. Merge duplicates into the existing record so the addendum attaches to the job instead of creating a sixth copy of it.
5. 5
   Make bid/no-bid an explicit decision

   Every invitation gets an outcome: bidding, declined, or duplicate. A declined invite is a real data point — it tells you which GCs are sending you work outside your lane, which is a conversation worth having with them.
6. 6
   Close the loop on submitted bids

   The intake list is not done when you submit. Read the replies, record awards and regrets against the specific GC, and let the outcome flow back into the record. Otherwise you rebuild your win rate from memory every year.

Should you decline more invitations?

Almost certainly yes. Subs who bid everything have low win rates, exhausted estimators, and no signal about where they are actually competitive. The uncomfortable version of the math: if you bid 200 jobs a year at a 12% hit rate, you did roughly 176 takeoffs that produced nothing. Cutting to 120 well-chosen bids at 20% wins the same amount of work with 80 fewer takeoffs.

You cannot make that call without per-GC history, which is the real argument for structured intake. "We've bid nine jobs for this GC and won none" is a decision. "I feel like we never win with them" is a hunch, and hunches lose to the estimator who wants to be helpful.

Bid boards vs. your own pipeline

Platform bid boards — PlanHub's, BuildingConnected's, ConstructConnect's — are genuinely useful for what they are: a view of the invitations that arrived through that platform. The limit is structural, not a criticism. No platform can show you the invitations that came through a competing platform, or the ones a GC emailed you directly, and none of them hold your pricing history, your scopes, or your outcomes.

The practical answer is both: keep using the boards to receive invitations, and maintain one pipeline of your own that everything lands in. See how IntelBid works alongside PlanHub and BuildingConnected for how that split works in practice.

Automating intake

This is the part of a bid desk that automates best, because the work is genuinely mechanical: read the email, pull out four fields, decide whether it duplicates something already open. IntelBid connects to Gmail or Outlook, reads incoming invitations, resolves the GC from the display name rather than the relay address, extracts project name, location, due date and size with a confidence score, and merges duplicates against your open pipeline before showing you the queue.

What it does not do is decide for you. Every extracted bid lands in a review queue with its confidence score and a link back to the source email — you approve, correct, or reject. Automation earns trust by being auditable, not by being invisible.