Automated RFP proposal generation

The situation

Securance responds to public sector solicitations: state agencies, counties, cities, school districts, higher education. Each one arrives as a dense procurement document with its own required section order, page limits, formatting rules and submission mechanics.

The response work was largely assembly. Read the solicitation, decide whether to bid, pull the right consultant resumes and past engagement case studies from SharePoint, select the applicable methodologies, build a pricing worksheet, then rebuild the same branded Word document from scratch. Cover page, table of contents, requirements matrix, orange accent bars, Gantt charts, reference tables. Every time.

The content already existed. The bottleneck was assembly, and assembly scaled linearly with the number of bids.

What we built

ASolicitation analysisIngests the RFP and produces an intelligence briefing: issuer profile, scope snapshot, drivers and pain points, recent public news on the issuer, a price-versus-value classification with grant funding detection, a level-of-effort estimate, and a go / no-go recommendation scored against Securance’s actual service catalogue and project history. It also drafts the clarifying questions for the procurement officer, matched to scope from a curated question bank.

BProposal contentBuilds the proposal’s section structure in the exact order the RFP requires, drafts the cover letter, selects the consultant team and generates a pricing workbook.

CContent fillMatches each section against the SharePoint content library and copies the real assets in, preserving their original formatting, images and list styling. The output is a fully branded, submission-ready Word skeleton with the boilerplate complete and the judgement calls flagged for the proposal team.

✓Structural verificationEvery run asserts its own integrity — section breaks preserved, headers intact, table geometry valid, no duplicate image ids, no missing resume content — and refuses to report success if any check fails.

How it went

The analysis worked early. Document fidelity was the hard part.

Producing a Word file that a model generated is straightforward. Producing one that renders identically in Word, Outlook and Google Docs is not. Most of the engineering went into problems that only appear at the OOXML level: floating cover art that walks off the page when content is inserted above it, bullet glyphs that silently change because list definitions live in a separate file from the tables that reference them, table grids with near-invisible columns that Word hides and Google Docs draws, image identifiers that collide and cause pictures to render as each other, and a single schema ordering violation that made the file unopenable in one renderer while the others quietly worked around it.

We addressed that by building verification into the pipeline itself. Failures surface as named assertions rather than as a document someone discovers is wrong the day before submission.

It is now in production across live engagements, including the Arizona Department of Administration, the City of Wentzville and Western Wyoming College. The content library remains the single source of truth; the pipeline handles retrieval, formatting and compliance. The proposal team spends its time on strategy and win themes instead of rebuilding cover pages.