Subcontractor bid comparison

The subcontractor bid comparison process begins when the office coordinator or one of five agents receives PDF quotes from subcontractors via email. Each quote arrives in its own format, with line items labelled and structured differently depending on the supplier. The team then manually extracts those line items, works out which items across different quotes are actually equivalent, populates a comparison spreadsheet, and flags anything ambiguous or non-standard before passing the finished table to a decision-maker. The process runs several times a week and adds up to roughly 400 runs per year, each taking around two hours of manual effort.

The core difficulty is format variability. Subcontractors do not follow a standard template, so every quote requires human interpretation to figure out how its line items map to a common structure. About 75% of cases are routine enough that a consistent normalisation logic applies, but the remaining 25% involve judgment calls that currently live in the heads of a small number of experienced staff. The comparison output is not just an internal convenience: it feeds directly into property claim statements, which carry legal liability under consumer protection rules, and personal data handled during the process falls under GDPR obligations. Errors introduced during manual data entry are discovered downstream during rework, which compounds both the time cost and the compliance risk.

The business currently uses email and spreadsheets as its primary tools, with a vendor CRM that has a partner API. Portal integrations have previously been built by an external contractor who can be re-engaged. There are no in-house developers, so any solution must be buildable and maintainable through that contractor relationship without requiring permanent technical staff on the payroll.

The recommended approach is a Hybrid AI workflow: a managed cloud document-understanding service handles extraction and normalisation for the routine majority of quotes, while a human review gate intercepts the non-standard cases that require judgment before the final comparison table is approved and stored. This is not a compromise between automation and caution; it is the architecture that actually fits the problem. The defining characteristic of this process is PDF format variability, and that is precisely what modern document AI, services like Azure Document Intelligence or AWS Textract, is designed to handle. A human reviewer sitting at a lightweight review interface covers the 25% of cases where the AI cannot confidently normalise a line item. The result is that the team's attention is concentrated on the cases that genuinely need them, rather than spread thinly across every quote.

The client has no stated platform preference, which the assessment notes as an opportunity rather than a constraint. Without a legacy system to integrate around or an internal team with strong opinions about tooling, the contractor can choose the managed cloud service that gives the best extraction accuracy for construction-format PDFs and pair it with a simple orchestration layer, most likely a low-code workflow tool, that routes standard cases through automatically and surfaces exceptions in a review queue. The external contractor who has previously built portal integrations against the CRM partner API is well positioned to deliver this: the architecture is not exotic, and the CRM integration at the end of the pipeline is a straightforward API write once the comparison table has been approved.

The fully automated AI Workflow path scored lower for a clear reason: a 25% exception rate is too high to leave unattended when the outputs carry legal liability. A plausible-looking but incorrect comparison table reaching a property claim statement is the specific risk the client identified, and an unattended pipeline has no mechanism to catch that before it causes harm. The human review gate in the Hybrid path is the control that makes the rest of the automation safe to run, not a concession to risk aversion. It also gives the team a period of calibration during which they can see what the AI gets right and wrong before they are asked to trust it fully.

RPA and Traditional Code were considered and set aside. RPA is brittle against format variability: a bot configured for one subcontractor's PDF layout breaks when that layout changes or a new supplier is onboarded, and maintaining a growing library of bot configurations without in-house developers is not realistic. Rule-based code parsing has the same fundamental weakness. These approaches could assist with downstream spreadsheet population, but they cannot solve the extraction and normalisation challenge that is the heart of the problem. An autonomous AI Agent could theoretically handle the full workflow end to end, but without the oversight infrastructure and with compliance liability in play, that level of autonomy is not appropriate at this stage. It remains a plausible future state once the team has built confidence in the system's accuracy over time.

Education alone would reduce individual effort but would not eliminate the 800 hours per year of repetitive work. It is worth noting that the office coordinator and agents who will own this process do need to develop real fluency with AI document workflows, not to build the system but to supervise it, interpret its outputs, and handle exceptions confidently. Upskilling at the right level is a necessary complement to the technical build, and the assessment identifies AIRIES Levels 3 and 4 as the relevant range for the team and its lead respectively. The Hybrid path works best when the people running it understand what the AI is doing and why, rather than treating it as a black box.

The two strongest paths for this process are Hybrid and AI Workflow, and the gap between them comes down to one thing: what happens when the extraction goes wrong. A fully automated AI Workflow could handle the routine 75% of quote comparisons without any human involvement, and in a low-stakes process that would be a perfectly reasonable choice. Here, though, the outputs feed directly into property claim statements that carry legal liability under consumer protection rules. An incorrect line-item comparison that reaches a decision-maker without review is not just an operational inconvenience; it is a compliance failure. That reality makes the human review gate in the Hybrid path a necessity rather than a conservative preference.

RPA scores well below both because it cannot solve the problem that actually matters. The core challenge in this process is that subcontractor PDF quotes arrive in dozens of different layouts with no consistent structure. RPA is well-suited to clicking through predictable interfaces and populating fields it already knows how to find, but it has no ability to understand a document whose structure it has never seen before. Every new subcontractor format would require a new bot configuration, and with a contractor rather than in-house developers maintaining the system, that becomes an expensive and fragile treadmill. Traditional Code has the same fundamental weakness: a rule-based parser that works for one quote layout breaks the moment a new supplier sends a PDF formatted differently, and maintaining a growing library of format-specific parsing rules without in-house technical staff is not realistic.

The Hybrid path wins specifically because AI document understanding, provided by a managed cloud service like Azure Document Intelligence, is designed for exactly this kind of format variability. It does not need to be told in advance what a quote looks like; it infers structure from the document itself. The human review gate then handles the cases where inference is not confident enough, ensuring that no output reaches a decision-maker without a person having been accountable for it. That combination of AI breadth and human accountability is what makes this path the right fit for a compliance-sensitive, variable-format process run by a non-technical team.

The build starts before any code is written, with a format audit. The external contractor reviews a sample of 30 to 50 historical PDF quotes collected from the client's email archive and catalogues the structural variations: how different subcontractors label equivalent line items, which fields are sometimes missing, and where ambiguity is most likely to occur. That audit produces a normalisation schema, essentially a defined list of canonical line-item categories and the rules for mapping incoming labels to them, along with a clear definition of what makes a case standard versus non-standard. Everything built after this point depends on the quality of that schema, so it is worth spending the time to get it right with input from the coordinator and the agents who currently do this work manually.

With the schema in place, the contractor builds the extraction pipeline. Incoming PDF quotes arrive by email, and a connector, most practically built using Make or n8n given the absence of in-house developers, monitors a designated inbox and triggers the pipeline on receipt. Each PDF is passed to Azure Document Intelligence, which extracts line items and their associated values and returns structured JSON. A normalisation layer maps the extracted labels to the canonical schema, scores each field by confidence, and flags the whole record as standard if all fields exceed a defined confidence threshold, or non-standard if any field falls below it or cannot be mapped. The output for standard cases flows directly into a comparison spreadsheet or a structured output template; non-standard cases are held in a review queue.

The review interface is where the compliance control lives. A lightweight web form, built by the contractor using a tool like Retool or a comparable low-code interface builder, presents the flagged cases to the office coordinator with the original PDF alongside the extracted values so that discrepancies are immediately visible. The coordinator can correct individual fields, add a note explaining the exception, and approve the record for output. Only approved records, whether auto-approved standard cases or manually reviewed exceptions, proceed to the final comparison table. Once approved, the contractor connects the pipeline output to the vendor CRM via its partner API, so that each completed comparison is stored against the relevant project record automatically rather than living in a spreadsheet attached to an email thread.

The final stage before full handover is a four-week parallel pilot in which the automated pipeline runs alongside the existing manual process on live incoming quotes. The team compares AI outputs against their own manual comparisons, and the contractor adjusts confidence thresholds and normalisation rules based on the errors found. This calibration period is not optional; it is where the system earns the team's trust and where the exception rate is measured against the baseline. At the end of the pilot, the coordinator and agents are trained on the review interface and the exception-handling workflow, process documentation is written down for the first time, and the contractor hands over a maintenance guide covering how to update the normalisation schema when new subcontractor formats appear.