Don't Touch the Client's Format
The answer goes back in their template. Every font. Every margin.
The Architecture Series · 9 minute read · By Ed | Founder & CEO, DealiOS
In enterprise sales, the client sends you their RFP template. Their fonts. Their formatting. Their structure. Their rules.
The moment you export your answers into a clean new document, you've told the client two things: "We don't follow instructions" and "We think our formatting is more important than yours."
Both messages are deal-killers. And most proposal tools send them by default.
The moment you export your answers into a clean new document, you've told the client: "We don't follow instructions" and "We think our formatting is more important than yours."
The winning move is invisible: write directly into their file without breaking a single style. No new fonts. No reformatted tables. No rearranged sections. Their document comes back looking exactly like their document, except now it has your answers in it. Like you were always supposed to be there.
The RFP Reality
The average RFP response takes 25 hours of work (Loopio/Bidara, 2025-2026). Enterprise teams with complex compliance requirements average over 30 hours. With 40% of revenue now tied to formal bids (Loopio, 2025), the RFP process isn't a side task. It's a core revenue function.
And the first thing most teams do with that 25 hours is throw away the client's template.
Here's how it usually works. The client sends a DOCX file. It has their logo, their fonts, their table structure, their section numbering, their carefully negotiated column widths that three VPs argued about. It has Word content controls, bracketed placeholders, and specific response fields that their procurement tool knows how to parse.
The proposal team opens the file. Reads the questions. Types the answers into their own tool. Exports a PDF. Sends the PDF.
The PDF has different fonts. Different formatting. Different structure. The client's carefully designed evaluation rubric, which relied on answers appearing in specific cells of specific tables, is now useless. Their procurement team has to manually extract answers from a reformatted document and re-enter them into their evaluation system.
You might as well have written the answers in crayon.
The client spent weeks building that template. It has approval from legal, procurement, and those three VPs. When you export your answers into a new document with your brand's fonts and your tool's formatting preferences, you haven't just changed the appearance. You've communicated something about how seriously you take the client's process. And the answer is: not very.
The Architectural Problem
Writing into someone else's DOCX is not a copy-paste problem. It's an XML manipulation problem.
A DOCX file is a ZIP archive containing XML files. The document body lives in word/document.xml. Styles live in word/styles.xml. Numbering definitions live in word/numbering.xml. The relationships between embedded objects live in word/_rels/document.xml.rels.
When you "open a DOCX in Word," you're looking at a rendered view of interconnected XML trees. When you write into that DOCX programmatically, you're manipulating those trees directly. One wrong node insertion and the document won't open. One wrong style reference and the formatting breaks. One wrong table cell modification and the column widths shift, cascading through every row below.
The challenge: find the exact locations where the client expects your answers, insert your content, and preserve every other byte of the file. The client should not be able to tell that a machine touched their document. The formatting should be identical. The styles should be identical. If they run a diff against the original, the only changes should be your answers in their answer fields.
That's the bar. Anything less communicates carelessness.
The Three-Layer Detection Hierarchy
The first problem is finding where to write. Clients mark their answer locations in inconsistent, unpredictable ways. Some use Word's built-in content controls. Some use bracketed text. Some use empty table cells.
A single detection strategy fails on most real-world RFPs. You need a hierarchy that tries multiple approaches in order of reliability.
Layer 1: Word Content Controls (SDT XML). The most reliable signal. Word's Structured Document Tags are explicit machine-readable markers that say "content goes here." They appear in the XML as <w:sdt> elements with properties that can include aliases, tags, and placeholder text. When the client uses content controls, the answer locations are unambiguous. Parse the SDT elements, find the ones that correspond to response fields, write into them.
Content controls are the ideal case. They're also the minority case. Most enterprise RFP templates are built by procurement teams who don't know what SDT elements are. They use brackets.
Layer 2: Bracketed Placeholders. This is the most common pattern across enterprise RFPs: [VENDOR RESPONSE], <<ANSWER>>, {{FIELD}}, [INSERT RESPONSE HERE], <Your Answer>, and a dozen variations. The detection layer runs 12 regex patterns against the document text, each calibrated to a different bracketing convention.
The patterns need to be specific enough to match intentional placeholders without matching regular text that happens to contain brackets. [1] is a footnote reference, not a response field. (see Appendix A) is a parenthetical, not a placeholder. The regex patterns exclude common false positives while capturing the intentional markers that procurement teams use.
Layer 3: Empty Table Cells. When the client doesn't use content controls or brackets, they often use tables with one column for questions and an adjacent empty column for answers. The detection layer identifies tables with a consistent structure (question text in column A, empty cells in column B) and marks the empty cells as response locations.
This is less reliable than Layers 1 and 2 because empty cells can be intentionally empty (section dividers, formatting spacers) or unintentionally empty (the client hasn't filled in their own content yet). The detection layer uses heuristics: if the adjacent cell contains a question mark or ends with a colon, the empty cell is probably a response field.
The hierarchy always starts at Layer 1 and falls through. If content controls are found, use them. If not, try brackets. If not, try empty cells. Each successive layer is less reliable and more heuristic, which is why the ordering matters. Three layers, twelve regex patterns for bracket detection alone, and a set of table-structure heuristics. That's enough to handle the overwhelming majority of enterprise RFP templates without ever modifying the document's structure.
Format Preservation at the Open XML Level
Finding the response locations is half the problem. The other half is writing content that doesn't break the surrounding formatting.
When you insert text into a DOCX programmatically, the text needs formatting properties. Font family, font size, bold/italic, line spacing, paragraph alignment. If you specify these properties explicitly, you override the client's styles. If you don't specify them, Word falls back to its own defaults, which are almost certainly wrong.
The solution: inherit. Every paragraph in a DOCX has a style reference (<w:pPr> with a <w:pStyle> element). Every run of text has character formatting properties (<w:rPr>). When injecting content, the system reads the formatting properties of the surrounding content and applies them to the injected text.
If the client's response field is in a table cell formatted with Arial 10pt, the injected text is Arial 10pt. If the surrounding paragraph has 1.15 line spacing and left alignment, the injected text has 1.15 line spacing and left alignment. The AI generates the words. The format preservation layer ensures the words wear the right clothes.
This extends to data types. When writing into Excel files (some RFPs include XLSX worksheets for pricing or compliance matrices), the system uses a function called inferTypedValue() that detects whether the content should be written as a string, a number, a date, or a boolean. Writing the string "14400" into a cell that expects a number breaks any formulas referencing that cell. Writing the number 14400 preserves the client's Excel logic.
The client never sees a formatting artifact. Ever. That's not a nice-to-have. It's the entire point.
The client never sees a formatting artifact. Ever. That's not a nice-to-have. It's the entire point. The template is sacred because the client's evaluation of your competence starts before they read your first answer. It starts the moment they open the file and see whether you respected their format.
Word-Limit Intelligence
Here's a subtlety that most automation tools miss entirely.
Many RFP templates include word limits. "Describe your approach to data security (maximum 500 words)." The limit appears in the question text, not in a metadata field. The client's evaluation team will penalize or disqualify responses that exceed it.
The AI needs to know the limit before it starts writing. The detection layer extracts word limits from the question text using pattern matching: "maximum X words," "not to exceed X words," "X-word limit," "up to X words." The extracted limit becomes a constraint on the AI's generation, producing responses that are substantive, complete, and compliant with the stated boundary.
An AI response that exceeds the word limit by 40% communicates the same thing as a reformatted template: "We didn't read your instructions carefully." The content might be excellent. The compliance failure overrides it.
The Competitive Dimension
RFP evaluations are comparative. Your response sits next to four other vendors' responses. The evaluator has a rubric, a scoring matrix, and limited patience.
The vendor whose response appears in the client's original format scores faster. The evaluator doesn't have to hunt for answers. They're exactly where the template said they'd be. The content controls are populated. The table cells are filled. The formatting is consistent with every other section of the document.
The vendor whose response arrives as a branded PDF requires manual extraction. Someone on the evaluation team opens the PDF, reads each answer, and copies it into the scoring matrix by hand. That process introduces transcription errors, takes longer, and generates low-level frustration that colors the evaluation even when the evaluator tries to be objective.
This is the hidden cost of ignoring the template. The proposal itself might be stronger. The pricing might be better. The technical approach might be superior. But the evaluator spent 45 minutes extracting your answers from a reformatted document while they spent 10 minutes scoring the vendor who wrote directly into the template. Evaluation friction is real, and it doesn't appear in any win/loss analysis.
The vendor who respects the template is saying, without saying it: "We pay attention. We follow your process. We'll be easy to work with." That's a signal that extends far beyond the RFP.
"Respect the artifact you didn't create" is a principle that extends far beyond RFP responses.
API integrations follow it. When you write data to someone else's API, you conform to their schema. You don't send your preferred field names and hope they figure it out. You read their spec, use their types, respect their constraints. The API is their template.
Database migrations follow it. When you modify a production schema, you add columns. You don't rename the existing ones to match your preferences. The existing schema is the artifact that other systems depend on. Your migration respects it by being additive, not destructive.
Plugin architectures follow it. When you build a plugin for someone else's platform, you operate within their extension points. You don't modify their core code to accommodate your feature. Their platform is the artifact. Your plugin is a guest.
In every case, the principle is the same: the artifact was there first. It has its own logic, its own users, its own dependencies. Your job is to add value within its structure, not to restructure it to match your preferences.
The client's RFP template is the most visible version of this principle in B2B sales. The template is the client's first test: can you work within our system? If your first act is ignoring their formatting requirements, what does that predict about how you'll handle their implementation requirements?
A contractor who shows up and immediately starts rearranging the furniture isn't demonstrating initiative. They're demonstrating that they don't listen.
A contractor who shows up and immediately starts rearranging the furniture isn't demonstrating initiative. They're demonstrating that they don't listen.
The winning move is always the same: make your contribution invisible within their structure. Their document comes back looking exactly like their document. Your answers fit perfectly into their format. The content controls are satisfied. The placeholders are filled. The table cells are populated. The column widths haven't shifted. The fonts haven't changed.
Like you were always supposed to be there.
The takeaway: The client's template is their first test of whether you follow instructions: write into their file invisibly, and you've passed before they read your first answer.
References
1. Loopio. (2025). "RFP Response Benchmark Report." Annual Survey Data. 2. Bidara. (2026). "RFP Statistics 2026: Average Win Rate Is 45%." Research compilation citing Loopio, APMP, and industry surveys. 3. ECMA-376. "Office Open XML File Formats." Standard defining DOCX/XLSX/PPTX structure. 4. Architecture Library #6: "One Document, Five Architectures." The Architecture Series. 5. Microsoft. "Open XML SDK Documentation." Developer reference for programmatic DOCX manipulation.
This paper is part of The Architecture Series by Ed, Founder & CEO of DealiOS. For the weekly series and more technical deep-dives, visit dealios.app/library.
See how these principles come together. Explore the platform →