How BidTriage triages every bid in minutes.

Stage 01

Ingest.

Capture more, process more. False positives at intake are fine. The wood chipper philosophy: get every invite into the pipe, let triage handle the rest.

• Source 01

  ConstructConnect

  Pull bid invitations the contractor has been invited to, including project metadata, bid date, GC, location, scope summary, and the document set when access is enabled.

  Shape

  PROJECT · DOCS · GC · BID DATE · SCOPE

  Cadence

  Sync every 6 hours; manual refresh on demand.

  Status · Ingestion live via the Construct Connect extension path. Files API in negotiation; both tracked in parallel so a delay on one does not gate the other.

• Source 02

  ISqFt

  Read invitation feeds and project pages. Capture invite metadata plus the GC and project context; document handling on roadmap pending platform-side API confirmation.

  Shape

  PROJECT · GC · BID DATE · LOCATION

  Cadence

  Sync every 6 hours.

  Status · Metadata ingestion on roadmap. Targeted for the next release window.

• Source 03

  BuildingConnected

  Pull invitations, bid form metadata, project files, folder structures, and the live GC distribution lists. Owned by Autodesk; richest API surface of the four sources today.

  Shape

  PROJECT · DOCS · FOLDERS · GC · BIDDERS

  Cadence

  Sync every 6 hours; folder recursion as the indexer walks.

  Status · Invitation ingestion live. File recursion in active engineering.

• Source 04

  Email

  Read invitation emails from a shared estimator inbox: GC-direct bid invites, ITB blasts, addenda, and clarifications. Extract project, bid date, and attached documents.

  Shape

  FROM · SUBJECT · ATTACHMENTS · PROJECT

  Cadence

  Sync every 15 minutes.

  Status · Gmail ingestion path under repair. Daily-use loop with the design partner depends on this surface; prioritized.

Stage 02

Triage.

Three scoring layers, one explainable output. Every score shows which rules fired and why. Operator override is always available; the system learns from the override.

• Strategy 01

  Rules

  RULE → MATCH → SCORE

  Plain-English filters your team writes once and reuses on every invite. Region, scope, GC, project size, bond requirement, contract type. Regex when you need it; dry-run against the last 90 days before commit so nobody ships a rule that quietly drops the wrong jobs.

• Strategy 02

  History

  WON → WEIGHT → SCORE

  Every invite is scored against the contractor's own win/loss/no-bid history. Won three projects with a given GC at this scope last year? That weight rides on the next invite. The longer the data builds, the more honest the score.

• Strategy 03

  AI-suggested rules

  OUTCOME → PROPOSAL → REVIEW → RULE

  Our model watches the outcome stream and proposes rules in plain language. Accept, edit, or reject. Every accepted rule joins the same explainable scoring path the human-written rules use. Suggestions come from your outcomes, not industry averages.

Stage 03

Decide.

A daily queue your estimators can clear before lunch. Surfaces built for the decision, not the dashboard.

• Surface 01

  Timeline view

  INVITE / WALK / BID / AWARD

  A calendar-style view of upcoming bid dates, walk-throughs, addenda, and award dates across every active pursuit. Cross-source. Nothing falls off the edge of a spreadsheet.

• Surface 02

  Per-source sync status

  LAST RUN · LAST FAIL · DEPTH

  Visible status on every source: last successful sync, last failure, queue depth. Estimators always know whether the queue they are looking at is current; engineers know which source needs attention.

• Surface 03

  Audit trail

  SCORE · RULE · OVERRIDE · DEDUP

  Every score, every rule change, every operator override, every dedup decision recorded. Defensible when a job you skipped turns out to have been the right one, or when a rule change drops the wrong invites for a week.

Where data comes from, where it goes

One routing layer between every source and your queue.