Build a library of RFP answers

Kite builds the library from your own past work first, because answers you've already submitted and won with are the best starting material you have. It reads past RFP responses, security questionnaires, product documentation, implementation guides, case studies, and the boilerplate your team pastes into proposals.

You can hand Kite these files in a few ways:

• Upload them. In the Kite web app, you can upload PDFs of past proposals directly into the conversation.
• Point Kite at a Google Drive folder. With Google Drive connected, Kite searches your folders for past responses by name, file type, or words inside the file, and reads Google Docs, Sheets, and PDFs.
• Share your Notion pages. If your team keeps product details or security notes in Notion, share those pages with the connection and Kite reads them.

Kite also checks what it finds against its own research. Your website, your pricing page, and the company facts in your knowledge base often hold newer information than a proposal from last spring. When a past answer says you have 40 customers and your website says 120, Kite uses the current number and notes where the old one came from.

Kite organizes the library by the topics RFPs ask about, so anyone looking for an answer knows where to find it. A typical library for a software company covers these topics:

• Company overview. Your history, size, ownership, locations, and the boilerplate paragraph that describes what you do.
• Product and capabilities. What the product does, how it fits the buyer's existing systems, and what's on the roadmap that you're willing to share.
• Implementation and onboarding. Timelines, who does what, training, and data migration.
• Security, privacy, and compliance. How you store and protect data, your certifications and audits, and your policies on access, backups, and incident response.
• Support and service levels. Support hours, response times, uptime commitments, and how customers reach you.
• Pricing and contract terms. How you price, what's included, and the standard terms you offer.
• Customer references and case studies. Named customers who agreed to be references, along with results you can cite.
• Team. Short bios of the people who would work on the account.

Each question in the library gets one approved answer. Many also get a short version and a long version, because one RFP gives you a 500-character box while the next asks for a full page. Every answer records where it came from, who approves it, and the date it was last checked. Kite marks each answer as either sourced or inferred, so an answer drawn from your security policy reads differently in review than one Kite wrote from your website.

Kite brings you the conflicts and gaps it finds, because those are the places where a library either earns trust or loses it. Two past proposals might give different uptime figures. Your support hours might be listed as "9 to 5 Eastern" in one response and "24 hours a day" in another. Kite shows you both versions with their sources and asks which one is current.

Some topics need a specific person to approve them. Security answers usually belong to whoever owns security, contract terms belong to whoever signs contracts, and pricing belongs to whoever sets it. Kite assigns each answer to its owner and sends that person only the answers they need to confirm, rather than the whole library.

Kite also lists the common RFP questions your library doesn't answer yet. If you sell to school districts and the library has nothing about student data privacy, that's a gap you want to close before the next deadline rather than during it.

Once answers are confirmed, Kite saves the library where your team works:

• In Google Docs, Kite writes the library as one document with a tab for each topic, so security answers sit in one tab and implementation answers in another.
• In Notion, Kite creates a database with one row per question and columns for the topic, the answer, the owner, the source, and the last-reviewed date. Your team can filter it to see every security answer or every answer that's due for review.

Kite also saves the core facts, such as your certifications, uptime commitment, and support hours, to its own knowledge base. That keeps its other work consistent with the library, so a sales one-pager or a landing page Kite writes uses the same numbers as your proposals.

When a new RFP arrives, Kite reads it, matches every question to the library, and writes a first draft of the full response. This is how a library makes you faster: the matched answers are done in minutes, and your team spends its time on the questions that are actually new.

Kite works through the RFP in order:

1. It reads the requirements first. Before writing, Kite lists the RFP's must-have requirements, deadlines, and formatting rules. If the buyer requires something you can't do, such as an on-premises installation or a certification you don't hold, Kite tells you up front, so you can decide whether the bid is worth the effort.
2. It researches the buyer. Kite looks up the organization that issued the RFP: its size, recent news, the systems it already uses, and what it says it's trying to fix. That research shapes how each answer is framed.
3. It matches and tailors. For each question, Kite finds the approved answer, picks the length that fits, and adjusts the wording to the buyer. A question about implementation for a 40-school district gets the same facts as one for a 4-school district, but the timeline and staffing examples change.
4. It flags what's new. Questions the library can't answer go on a separate list, grouped by the person who owns each topic. Kite drafts an answer where it has enough to go on and marks it for review.
5. It writes the response. Kite copies your proposal template in Google Docs, fills in the buyer's name and details, and writes the answers in the order the RFP asks for them. It can export the finished document as a PDF.

Here's what that looks like in practice. Say a 25-person company that sells scheduling software to school districts receives an RFP with 140 questions. Kite matches 118 of them to approved answers, tailors those to the district, and drafts answers for 15 more from the company's documentation and knowledge base. It sends the remaining 7 to the right people: 4 security questions to the head of engineering and 3 pricing questions to the founder. The team reviews a complete draft instead of a blank document.

You read the response, make changes, and submit it through whatever process the buyer requires.

Kite updates the library after every response and whenever your company changes, because a library is only worth using if the team trusts that its answers are true today. There are three ways an answer goes stale, and Kite handles each one.

New answers from finished responses. After you submit a response, Kite reads the final version and adds any newly approved answers to the library. If your team rewrote a matched answer during review, Kite asks whether the new version should replace the old one. If you keep finished responses in a Google Drive folder, Kite can check that folder on a schedule and pick up new ones on its own.

Changes to your company. When you tell Kite about a change, such as a new certification, a new support tier, or a price increase, Kite finds every answer that mentions the old version and rewrites it. The same happens when the change reaches Kite another way, such as a pricing update Kite makes on a website it hosts for you or a new fact it records in its knowledge base. In Google Docs, Kite can find a phrase and replace it everywhere it appears. In Notion, it updates the matching rows in place.

Answers nobody has checked in a while. You can set Kite to review the library on a schedule, for example on the first Monday of every quarter. Kite checks each answer against your knowledge base and website, rewrites the ones that have drifted, and sends each owner a short list of the answers that are due for their review.

Kite also learns from your corrections. When the founder says, "We never quote implementation in weeks, always in phases," Kite records that as a rule and follows it in every later response.