What can a subcontractor automate in the bidding process?

Everything on one side of it is knowledge about your crews, your suppliers, your risk and the specific job. Everything on the other side is moving information around so that knowledge reaches the right person before the deadline.

Automating across that line is where tools in this category go wrong, and it is worth being blunt about why: a number produced by software that does not know your crews is not a bid, it is a guess your name is attached to.

• Intake. Invitations arrive by email from several general contractors in several formats. Turning that into one list with dates on it is pure clerical work and is usually the first thing to go.
• Deadline tracking. Which are due, which are close, which have quietly passed. A list that knows today beats a spreadsheet somebody updates.
• Follow-up. On a cadence, without an estimator remembering. This is the one with the most immediate effect, because the current state is usually that it does not happen.
• Outcome logging. Won, lost, no response. The least urgent and the most valuable over a year, because it is the only thing that tells you why.

Pricing, obviously. Scope interpretation, because reading what a set of drawings actually requires is the skill you are selling. And the decision to bid at all, which is a judgement about capacity and risk that belongs to whoever carries the consequences.

A useful test: if getting it wrong costs you money on the job rather than time in the office, it stays with a person.

Because it is the half that fails silently. A mispriced bid is visible immediately and gets discussed. A bid that was never followed up produces no event at all, and an office can lose the same way every week for a year without anything appearing on a report.

That asymmetry is the reason to start here. The work is boring, the risk is low, and the losses it removes are the ones nobody can currently see.

Take intake first. It is visible within a day, a person can verify it by glancing at the list, and being wrong about it costs nothing worse than a missing row somebody adds by hand. That combination is what makes it a good first thing to hand over.

Outcome logging goes last, even though it is the most valuable over a year. It is the hardest to verify at a glance and the easiest to get subtly wrong, and a team that has already watched the earlier pieces behave will extend it the benefit of the doubt that a brand new system has not earned.

The sequence is deliberate rather than technical. Every piece here could be built in either order; the reason to do it this way is that adoption fails long before the software does.

For an underground contractor we cut construction document package assembly from hours down to under a minute, and built the operations platform 114 of its people open every day. Finished work, and the origin of everything above.

ProjectFlow runs on that work and is live with AC Electric now. What we will not do is hand you a figure for what automated bid follow-up has returned, because we have not measured one we would stand behind. We will tell you what it is designed to do and what we guarantee, and leave the rest blank rather than dress it up.