AI bid-automation for digital agency

The trigger

The COO was personally screening 50% of inbound projects. 15+ hours per week of his time was going into reading project briefs on five different platforms, comparing them to the agency's positioning, and deciding "pursue / estimate / pass." In a single month they had missed bids on two high-value projects — a $180K e-commerce rebuild and a $95K marketing-automation engagement — because the response window had closed before the screening reached the top of his queue.

The trigger was a board comment: "if the COO is the bottleneck on bid-response, the COO IS the business model, and that doesn't scale." The board wasn't wrong. Three months of internal attempts to delegate the screening to senior account managers had failed — the win rate dropped 6 points whenever someone else made the calls. The screening criteria existed entirely in the COO's head and the team couldn't read his mind.

When they called us, they had already tried a manual rubric (a spreadsheet checklist that the AMs would fill in for each project). It surfaced the criteria but it was even slower than the COO doing it himself. The ask wasn't "build us a screening tool." It was "give us back 15 hours of the COO's week without dropping win rate".

The week-one discovery

We started by harvesting the COO's brain. Three two-hour sessions in week zero, recorded with permission, focused on a single question: "Walk me through the last 20 projects you said yes to and the last 20 you said no to. For each one, what made it a yes or a no?"

The output was a 47-criterion rubric across 6 dimensions (budget fit, scope clarity, technical fit, strategic fit, client signals, competitive pressure). Some criteria were obvious ("budget below $20K" → auto-decline). Others were subtle: "if the client lists 'WordPress' in the tech stack BUT mentions 'enterprise integrations' in scope, that's actually a $80K+ project pretending to be a $20K project — pursue with caution." The 47 criteria with their weights took 6 hours to extract. The reasoning behind each was the deliverable.

The 4 inbound platforms had wildly different input formats. One was clean JSON via webhook. Two were emailed PDFs with semi-structured project briefs. The fourth was a forum post — text only, no structured fields. We built input adapters for all four; the PDF parser used Claude to extract structured fields from the unstructured text BEFORE the screening happened (a separate prompt, kept simple).

The historical win-rate data was sitting in Excel. We pulled 14 months of decisions (won / lost / dropped) into a structured dataset of 1,247 records. The dataset wasn't perfect — some records were missing the "why" field — but it gave us a ground-truth set to A/B test against.

The architecture decisions

**Claude vs GPT-4.** We benchmarked both on the rubric. Claude was marginally more accurate (within noise on a 100-decision holdout) and significantly better at instruction-following on the structured output requirement (always returning a JSON with the 8 expected fields, no chatty preambles). Claude also won on cost at the agency's projected volume: ~$340/month vs ~$580/month for GPT-4 at the same accuracy band. We went with Claude Sonnet for the screening; the agency owns the API key and can swap models if pricing shifts.

**n8n vs custom workflow.** We had a strong opinion that n8n was right here even though our team is more comfortable building custom workflows in Python. The reason: the agency's ops team needed to be able to edit the workflow post-handoff. n8n's visual editor is more learnable than reading our Python code. We accepted the 15% performance overhead vs a custom workflow because the latency budget had plenty of headroom (sub-30-second response time was the goal; n8n + Claude completes in 8-12 seconds).

**Monday.com vs custom database.** Monday was already in their stack as the project-management hub. Putting the screening decisions in the same system that the AMs use every day — same UI, same notifications, same comment threads — was a UX win over forcing them to a new tool. We used Monday's API for state and built the screening as a "Decision Cards" board with three columns matching the three actions.

**Three-action design vs five-bucket framework.** The COO's instinct was that there should be 5 buckets (auto-apply, auto-apply with caveat, estimate required, decline with referral, hard decline). We argued for three: auto-apply, estimate-required, auto-decline. The reason: the marginal decisions (auto-apply-with-caveat and decline-with-referral) get human attention anyway. Three actions kept the framework legible. Six months later, the COO confirmed three was the right call — adding the marginal buckets in v2 would have created decision paralysis instead of removing it.

The build

Week 1 was rubric extraction and prompt engineering. The hardest part was the self-check. Early versions of the Claude prompt would sometimes return decisions that contradicted the rubric — flagging a project as auto-apply when the budget fell below the threshold, for example. The fix was a two-stage prompt: first stage extracts the project facts as structured JSON, second stage applies the rubric to the facts and returns the decision. Separating extraction from judgment cut hallucinations to under 1% on the holdout set.

Week 2 was workflow build. n8n nodes for each platform adapter, a Claude node for the screening, a Monday.com node for state, a Slack node for COO notifications on the auto-apply decisions. We ran an A/B test against the manual baseline using 200 projects from the historical dataset: Claude outperformed the COO by 6 points on a holdout set — meaning Claude's decisions matched what actually happened on the contract (won, lost, dropped) more often than the COO's contemporaneous decision had. That number startled everyone, including us. The likely reason: Claude doesn't get tired at 4pm, doesn't anchor on the most recent project, doesn't have favorite client types.

The shadow week happened in week 3. The workflow ran on every inbound project alongside the COO's manual screening for 5 business days, but the Claude decision was hidden from the AMs. At end of week the COO reviewed the 47 disagreements (out of 312 total decisions) and concluded: Claude was right in 31 of them, the COO was right in 11, and 5 were genuine judgment calls where either answer was defensible. Cutover approved.

The cutover

Week 4: cutover happened on a Tuesday morning. By Friday the team had processed 287 inbound projects with auto-decisions on 71% of them. Response time on auto-apply projects dropped from 4 hours to 11 minutes (the 11 minutes is the agency's response email composition time on top of the workflow's <1 minute decision).

The first week's anomalies: two projects where the input PDFs had unusual formatting that the Claude extraction step couldn't parse cleanly. Both were correctly routed to the estimate-required bucket (the workflow defaults to human review when extraction confidence is low). The agency's AM noticed within 10 minutes and processed them manually. We added the two PDF formats to the extraction prompt's example set the next morning.

No rollback was used. The COO checked the auto-decline decisions for the first 3 weeks (about 380 declined projects) and overruled 2 of them. After 3 weeks he stopped checking.

Ninety days later

Ninety days in, win rate has climbed from 23% to 31% and held. The mechanism is response time, not better screening — we got faster than every competitor in the agency's space. Projects that go to bid in the first 30 minutes after submission win at roughly 2x the rate of projects that go to bid 4 hours later. The screening was the means; the response-time arbitrage was the outcome.

$45K/month of net new revenue is attributable to the win-rate increase. The math is straightforward: ~50 additional projects per quarter, average project value $9K, attributable to the 8-point win-rate climb. The board has stopped asking "how do we scale the COO" because the COO is no longer the bottleneck.

The agency's ops team has been editing the prompt themselves for the last 60 days. We left them a "prompt engineering primer" doc (about 8 pages of patterns + examples) and they've made 4 substantial prompt edits without our involvement — adjusting thresholds for two project categories that emerged after launch, adding a new platform adapter for a forum the agency started monitoring, and tuning the strategic-fit criterion as their positioning evolved.

What we'd do differently

The shadow week was the highest-value 5 days of the engagement. We almost cut it for budget — the COO was confident enough by week 2 that he wanted to cut over directly. The shadow surfaced 5 judgment-call disagreements that informed the v1.1 prompt and probably saved the win-rate-during-cutover dip we would have otherwise hit.

We'd build the prompt-tuning UI from the start. The agency's ops team can edit the prompt in n8n but the change-and-test loop is awkward. A simple UI for "load the last 50 decisions, edit a criterion, see which decisions would flip" would have made the post-handoff iteration faster. We'd build it in week 2 next time, not as a future-state recommendation.