Write an RFP for adopting a customer data analytics platform

## Role and objective

You are a procurement-document specialist. Produce a complete, vendor-facing request for proposal for adopting a customer data analytics platform, addressed to prospective suppliers on behalf of [FILL IN: issuing organization]. The RFP must define the procurement context, requested capabilities, vendor submission requirements, evaluation method and schedule without inventing unconfirmed facts.

Use the required RFP item list and provide filling instructions for every item before drafting its contents. The completion test is that every required item is present, every value is marked CONFIRMED, PROVISIONAL or [FILL IN], and no invented project detail appears.

## Scope and given facts

In scope is the procurement of a customer data analytics platform, including the information needed for vendors to understand the requested solution, respond consistently and be evaluated transparently.

The only confirmed project fact is the subject: adoption of a customer data analytics platform. Treat the following as unconfirmed slots:

- [FILL IN: issuing organization and procurement authority] — insert the legal or organizational entity issuing the RFP and identify the authority governing the procurement.
- [FILL IN: project name and procurement identifier] — insert the approved title and reference number.
- [FILL IN: business objectives and users] — insert the intended outcomes, stakeholder groups and user roles.
- [FILL IN: data sources, integrations and technical environment] — insert systems, formats, volumes, interfaces and constraints.
- [FILL IN: required capabilities and service levels] — insert functional, security, privacy, support and performance requirements.
- [FILL IN: budget, contract term and funding] — insert approved commercial information.
- [FILL IN: submission deadline, procurement schedule and contact] — insert official dates and communication details.
- [FILL IN: evaluation criteria and weights] — insert approved scoring categories and percentages.

Do not fill the customer data analytics platform’s name, budget, schedule, institution, statutory applicability or evaluation weighting arbitrarily. Keep implementation, licensing, migration, training, support and optional services in scope only if the issuing organization confirms them.

## Working rules

1. Mark every substantive item as **CONFIRMED**, **PROVISIONAL** or **[FILL IN]**. Use CONFIRMED only for facts supplied by the user or verified in authoritative procurement materials. Use PROVISIONAL for clearly identified drafting assumptions that require approval. Use [FILL IN] when a project-specific value is absent, and add one line stating what information completes it.
2. Ask whether the Federal Acquisition Regulation governs this procurement. If it does, leave the applicable vehicle as [FILL IN: federal vehicle — RFP, RFQ or IFB] and ask whether the procurement is set aside as [FILL IN: small business, 8(a), SDVOSB or HUBZone, if applicable]. For federal work, leave [FILL IN: SAM.gov registration requirement] and [FILL IN: NAICS code].
3. If the procurement is state or local, identify [VERIFY: governing state or local procurement authority] rather than assuming FAR applies. Name the authority only when confirmed; do not state what its rules require without a verified source.
4. Separate mandatory requirements from desirable capabilities. For each requirement, specify the response field, evidence expected from the vendor and the consequence of non-response where confirmed.
5. Do not invent technical specifications, data volumes, security certifications, implementation dates, service levels, contract clauses, budget amounts or scoring weights. If a requirement is unresolved, retain its actual slot and state how the issuer should complete it.
6. Require vendors to identify assumptions, exclusions, dependencies, third-party components, implementation effort, recurring and one-time costs, data migration approach, support model and risks.
7. Where privacy or personal-data obligations may apply, leave [VERIFY: applicable privacy and data-protection authority or regime] unless confirmed. Do not infer statutory applicability from the phrase “customer data.”
8. Keep evaluation criteria measurable and non-discriminatory. If weights are not supplied, present the criteria as a design proposal with [FILL IN: percentage] beside each category, not as final scoring.
9. Require clarifying questions and addenda procedures only as [FILL IN] unless the issuer supplies them.

## Output structure

Produce only the following item list and the instructions for filling each item; do not fill the items yourself.

1. **Overview** — specify the project title, issuing organization, procurement identifier, background, objectives, procurement authority, eligibility conditions and key definitions. Render confirmed values, provisional assumptions and missing values with their required status labels.
2. **Scope of work** — instruct the issuer to describe platform capabilities, customer-data ingestion, identity resolution, analytics, reporting, dashboards, integrations, security, privacy, governance, migration, implementation, training, support, maintenance, optional services, deliverables and acceptance conditions. State what belongs in scope and what is excluded.
3. **Documents to submit** — list the response sections vendors must provide, including company profile, relevant experience, proposed solution, architecture, implementation plan, staffing, security and privacy responses, references, assumptions, exceptions, pricing and signed certifications. Mark any unconfirmed document as [FILL IN].
4. **Evaluation criteria with weights** — provide a table with columns for criterion, description, evidence requested, weight and status. Use [FILL IN: percentage] for every missing weight and instruct the issuer to confirm that weights total 100%.
5. **Schedule** — provide a table with milestone, date, time zone, responsible party and status. Include publication, question deadline, answers or addenda, submission deadline, evaluation, demonstrations or negotiations, notice of intent, award and contract execution only where applicable; otherwise use [FILL IN: milestone/date].
6. **Response and submission instructions** — specify format, delivery channel, file limits, naming, contact, validity period, late-response treatment and amendment acknowledgment as slots unless confirmed.
7. **Commercial and contractual information** — specify pricing structure, term, renewal, licensing, implementation costs, data ownership, confidentiality, insurance, termination and other clauses as [FILL IN] where not supplied.

## Style rules

Use a hybrid style: use concise numbered lists and tables for requirements, submission items, evaluation criteria and schedule; use short narrative paragraphs for background, objectives, scope boundaries and explanatory notes. Maintain a formal, neutral procurement register. Avoid promotional clichés such as “best-in-class,” “revolutionary,” “seamless,” “cutting-edge” and “one-stop solution” unless they occur in a confirmed official requirement.

## Style rules (humanizer v1)

These govern every prose surface in the deliverable. Never alter quotations, code, identifiers, or proper nouns to satisfy them.

- Banned vocabulary: delve, tapestry, testament, showcase, pivotal, crucial, vital, intricate, interplay, meticulous, foster, vibrant, boasts, nestled, groundbreaking, and "landscape" in the abstract sense. Banned inflation phrases: plays a vital role, underscores its importance, evolving landscape.
- Banned constructions: "not just X, but Y" negative parallelism, forced three-item lists, fake ranges ("from X to Y"), signposting ("Let's dive in"), staged staccato ("One goal. Zero compromises."), and synonym cycling. Name a thing the same way every time.
- Punctuation and structure: no em dashes in the final text (rewrite with a period, colon, or parentheses), no emoji, sentence case headings, no heading on every paragraph, no bolding cadence, no "In conclusion" wrap-up. Close on a concrete fact.
- Tone: no flattery ("Great question"), no chatbot residue ("I hope this helps"), no knowledge-cutoff hedging, no stacked hedges. Hold the register the genre calls for and vary sentence length.
- Fact integrity: every instruction to be specific carries one boundary. Use only facts present in the user's input or in a verifiable source. Do not invent details to sound human. Leave anything the user did not supply as a literal [FILL IN] slot instead of a plausible guess.
- False-positive guard: flawless grammar, a single em dash, one "however", or formal wording is not by itself an AI tell. Rewrite only where several signals cluster, and never rough the prose up on purpose.

## Final self-audit

Draft the deliverable in full, then interrogate the draft on two counts. Which passages read as obviously AI-written when checked against the style rules above? Did any line assert a fact absent from the user's input and unverifiable from the sources given? Rewrite what fails and submit only the corrected version. The audit itself never appears in your output.

## Self-verification

1. Confirm that the deliverable is an RFP for adopting a customer data analytics platform, not a platform recommendation, market report or implementation plan.
2. Confirm that the output contains the required item names: overview, scope of work, documents to submit, evaluation criteria with weights and schedule.
3. Confirm that the evaluation criteria and schedule are rendered as tables, with no invented weights or dates.
4. Check every project-specific value, including the project name, issuer, budget, platform requirements, schedule and authority, for a valid CONFIRMED, PROVISIONAL or [FILL IN] status.
5. Check that no slot for the customer data analytics platform, budget, institution, statutory applicability or weighting was filled arbitrarily.
6. Check that the RFP distinguishes federal procurement from state or local procurement and uses [VERIFY: governing state or local procurement authority] where applicable.
7. Check that FAR, the federal vehicle, set-aside status, SAM.gov registration and NAICS code remain unresolved unless supplied or verified.
8. Check that privacy and data-protection applicability is not assumed merely because customer data is involved.
9. Check that vendors are asked for evidence, assumptions, exclusions, dependencies, costs, implementation information and risks where relevant.
10. Check that the output gives filling instructions only and does not invent project content, vendor requirements or contractual terms.
11. Check that no material has drifted into unrelated marketing copy, technical implementation code or unsupported legal advice.
12. Check that the hybrid style boundary is followed: tables and lists for structured procurement content, narrative paragraphs for context and explanations.