An RFP template for K-12 parent communication

Weightings are a starting point, not a prescription — move them to match what your district actually cares about, but move them before you see the responses rather than after. The two rows most districts under-weight are the first two, and they are the two that determine what this decision costs you in year four. A twelve-point difference on feature parity is noise. An uncapped renewal on a 9,000-student contract is a six-figure difference over the term.

How to structure the document

A parent-communication RFP does not need to be long. It needs to be scoreable, which means every requirement is written so that a reader can mark it met, partially met or not met without a conversation. Nine sections is enough.

1. Background and scale. Student count, school count, guardian count, languages spoken with numbers, current platform and contract end date, SIS and its version. Vendors price better with real numbers, and vague scale is how you get a proposal you cannot compare.
2. Scope. What you are buying and, importantly, what you are not. If you are keeping a separate LMS messaging tool or a separate emergency system, say so.
3. Functional requirements. The section below. Numbered, each one scoreable.
4. Technical and security requirements. Data residency, tenancy model, audit logging, authentication, subprocessors.
5. Data and exit requirements. Separate section, not a subsection of technical. This is the one that gets skipped when it is buried.
6. Implementation and migration. Timeline, responsibilities, what happens to historical message data.
7. Commercial terms. Pricing format required, term, renewal mechanics, what is included and what is metered.
8. Evaluation method. Publish the rubric. Vendors respond better to a published rubric and it protects you from a protest.
9. Response format. Page limits, a requirement to answer in the order asked, and a rule that a reference to a website does not constitute an answer.

Two process notes worth more than most of the document. Set the question deadline early enough that you can publish answers to all bidders, and publish them all — the questions vendors ask reveal which requirements are hard, which is information your evaluation committee should have. And require a live demonstration against a scenario you write, not one the vendor brings. "Send an emergency notice to these 40 named guardians in two languages, then show us the delivery report and the audit record" separates products faster than any written response.

Requirement statements you can lift verbatim

Written to be scored. Use SHALL for mandatory and SHOULD for weighted-but-optional, and keep the numbering so responses stay comparable.

Messaging and delivery

R1. The system SHALL send to SMS, voice and email from a single composed message, without requiring the message to be re-entered per channel.
R2. The system SHALL automatically attempt an alternative channel when a message fails terminally on the primary channel, and SHALL link the retry to the original attempt in reporting.
R3. The vendor SHALL state whether reporting counts a message accepted by a carrier as "delivered". Reporting SHALL distinguish accepted, delivered, failed and suppressed.
R4. The system SHALL enforce configurable quiet hours, and SHALL allow an explicitly flagged emergency message to bypass them. The bypass SHALL be restricted to designated users and SHALL be recorded in an audit log.
R5. The system SHALL display an estimated cost and estimated recipient count before a message is sent.
R6. The system SHALL allow a test send to the composing user only, before the message is released.
R7. The system SHALL allow scheduling, and the vendor SHALL state whether the recipient list is resolved at the time of scheduling or at the time of sending.
R8. The vendor SHALL state which audience selections are supported natively — individual, school, grade, class, bus route, language, custom group — and SHALL demonstrate each claimed selection live.
R9. The vendor SHALL describe its handling of A2P 10DLC registration, who owns the registration, and the lead time before the district can send at volume.

Language access

R10. The vendor SHALL name the translation engine used and SHALL provide the complete list of supported target languages. A count without a list will be scored as not met.
R11. The system SHALL allow the sender to preview the translated message before sending.
R12. The vendor SHALL describe what happens when translation fails — whether the original is sent, the message is held, or the failure is silent.
R13. The system SHOULD allow a per-guardian language preference sourced from the SIS and overridable by the family.

Roster, integration and API

R14. The vendor SHALL state, for each named SIS, whether integration is a vendor-built connector, a standards-based feed (OneRoster, SIF), a flat-file import, or an API the district must populate itself.
R15. The system SHALL provide a documented public API covering roster, audiences, messages and delivery results, with published rate limits.
R16. The system SHALL provide outbound webhooks with request signing, and SHALL document the signature scheme.
R17. The system SHALL prevent a mass-withdrawal event caused by a truncated or partial roster file, and the vendor SHALL describe the specific guardrail.
R18. The system SHALL suppress messages to withdrawn students and their guardians at send time, not merely at import time. The vendor SHALL demonstrate this.

Security, tenancy and audit

R19. The vendor SHALL describe tenant isolation at the database layer, not only at the application layer, and SHALL state how isolation is tested.
R20. The system SHALL maintain an audit log of message sends, audience selections, permission changes and data exports, and the vendor SHALL state whether that log can be modified or deleted by any user or administrator.
R21. The vendor SHALL state its current independent audit status — SOC 2 Type I, Type II, in progress, or none — with dates. A statement of "compliant" without an audit will be scored as none.
R22. The vendor SHALL list all subprocessors with function and location, and SHALL commit to notifying the district before adding one.
R23. The vendor SHALL describe available authentication methods for staff, including whether SSO/SAML, OIDC and MFA are supported today.
R24. The vendor SHALL provide a current VPAT against WCAG 2.1 AA, dated within the last 12 months and covering the version being proposed.

Data ownership, portability and exit

R25. The district SHALL retain ownership of all district and family data. The vendor SHALL NOT use district data to train models or to develop products beyond providing the service.
R26. The district SHALL be able to obtain a complete export of all its data — people, contact points, message history, delivery results, audit log — at any point during the term, in documented machine-readable formats, at no additional charge. The vendor SHALL state whether this is self-service or vendor-performed, and the maximum turnaround.
R27. The vendor SHALL delete district data within a stated number of days of termination and SHALL provide written confirmation.
R28. The vendor SHALL NOT market or sell any product or service to district families, and SHALL NOT offer a paid family-facing tier of this product.
R29. In the event of a change of control of the vendor, or a material adverse change to data-handling terms, the district SHALL have the right to terminate within 90 days with a prorated refund, full export, and no early-termination penalty.

Commercial

R30. The vendor SHALL price every year of the term, including all renewal years, in the response.
R31. The vendor SHALL state the maximum annual increase it will accept in the contract, expressed against a named public index.
R32. The vendor SHALL identify every item that is metered, capped or charged separately from the per-student fee — messages, voice minutes, translation volume, storage, API calls, additional users, additional schools, implementation, training, integrations.
R33. Where the vendor sells feature tiers, the response SHALL identify which tier each claimed capability requires.

The four questions that separate vendors

Feature responses converge. These four do not, and they are where the money and the risk actually sit. Ask them in writing, require a written answer, and attach the answers to the contract.

1. What is the maximum annual increase you will accept in the contract, in writing, against a named index?

Not what your increases have historically been. Not a statement that increases are "typically modest". A number, in a clause. The pattern that has repeated across this category is a competitive first term followed by renewal increases in the double digits, at a point where the district has three years of message history in the system and no realistic ability to move mid-year. A vendor that will not cap in writing is telling you what its renewal strategy is. Kastr's answer is in the contract at §3.2: price fixed for 36 months, and from year four the increase is capped at the lesser of CPI-U or 5%.

2. Can I export everything today, without asking you, and is that a contract right?

Two separate questions bundled into one, and vendors answer the easy half. Almost every vendor will export your data if you are leaving. The question is whether you can get a complete export — including message history, delivery results and the audit log — during the term, routinely, without a support ticket and without a professional-services line item. If the answer is that export happens at termination, you are being told that your leverage at renewal is zero. Get the export right into the contract with a named turnaround, and then test it in the first ninety days rather than in year four. Kastr's version is a contract clause at §7.1 covering all district data in documented formats at any time and at no charge; we are being deliberate in describing it as a contractual right rather than a self-service button, because the self-service export tooling is not built yet.

3. Do you now, or could you in future, sell anything to our families?

This one is asked almost never and matters increasingly. A parent-communication platform holds a direct channel to every household in your district, with contact details, language, and enrolment context. That is a commercially valuable asset and some vendors in adjacent categories have monetised the equivalent — family-facing premium tiers, in-app placements, partner offers. The district is the party that handed over the channel and gets none of the revenue, but takes all of the complaints. Ask for a clause prohibiting marketing or selling to families and prohibiting a paid family-facing tier of the product. Kastr's is §9.4, and it is unconditional.

4. What happens to this contract if you are acquired?

This category consolidates. Several of the products a district might be evaluating this year are already inside a larger group, and terms can change after the ink dries — data handling, subprocessors, roadmap, pricing model, or the product simply being sunset into a bigger suite. The protection is a change-of-control exit: if the vendor is acquired or materially changes its data terms, the district may terminate within a defined window with a full export, a prorated refund, and no penalty. It costs the vendor nothing if they intend to behave and it costs you nothing to ask for. Kastr's is §11.2 with a 90-day window. See what to do when your vendor is acquired.

Scoring it without a committee argument

The evaluation goes wrong in predictable ways, and all of them are avoidable by deciding things before the responses arrive.

Publish the rubric in the RFP. Weightings, and what full marks look like on each row. This improves the responses, shortens the evaluation, and is your best protection if a losing bidder protests.

Score independently, then meet. Committee members score alone against the rubric before any discussion. Then compare and discuss only the rows where scores differ by more than two points. A committee that scores collectively converges on the loudest member's view within twenty minutes.

Separate cost scoring from the rest. Score the functional and technical sections without the price in front of you, then apply cost. Committees that see price first tend to justify backwards.

Model the full term, not year one. Build one spreadsheet: per-student fee by year at your projected enrolment, plus implementation, plus every metered item at your actual message volume, plus the renewal increase each vendor has committed to in writing — and where a vendor has refused to commit, model it at the increase they have historically taken. Sum across the whole term including renewals. This regularly reverses the ranking that year-one pricing produces, and it is the single most useful hour the committee will spend.

Write a demo scenario and give it to every vendor. Same scenario, same data, same fifteen minutes. Something like: import this roster file with 40 records and 3 deliberately malformed rows; compose a two-language emergency notice; send it to 12 named guardians; show the delivery report; show the audit record of who sent it; then export the whole thing. Vendors will push back on the scripted demo. That resistance is itself information.

Check references on the thing that goes wrong. Not "are you happy". Ask each reference: what did the migration actually cost in staff hours, what did your renewal increase come in at, what does the vendor do badly, and how long does a support ticket really take in September. Ask for a reference of similar size and similar SIS, and ask for one that left, if the vendor has any.

How Kastr would answer this RFP, including where we would lose points

Publishing an RFP template and then quietly writing it so only we could win it would be worth nothing to you and not much to us. So here is our own scorecard against the requirements above, including the ones we fail.

Where we score well. R1–R7 on delivery: single compose across SMS, voice and email; automatic SMS-to-voice failover on terminal failure with the retry linked to the original; configurable quiet hours defaulting to 21:00–07:00 with an emergency bypass that is capability-gated and audit-logged; cost-and-reach preview before send; send-test-to-me; and schedule-later with the audience resolved at send time rather than schedule time. R15–R17: a 28-endpoint public REST API with published rate limits, signed webhooks with a documented HMAC scheme, and an MIT-licensed CLI and MCP server you can inspect. R17 specifically — the roster importer aborts rather than proceeding if more than half of active records would be withdrawn, which is the truncated-file failure that has cost districts a lot of goodwill. R20: a per-organisation SHA-256 hash-chained audit log that is append-only at two independent layers, so the honest answer to "can an administrator delete this" is no. R25–R29: ownership, export as a contract right, no family monetisation, and a change-of-control exit, all in clauses rather than in a brochure. R30–R33: $3.50 per student per year under 5,000 students, $3.25 to 14,999, $3.00 above, one tier with everything included, no per-message or per-minute fee, published on the site.

Where we lose points, plainly. R8: our audience resolution handles named individuals and everyone. It does not resolve by school, grade, class, bus route or language. If your evaluation weights targeting, we score badly and we should. R21: we have no SOC 2 audit of any kind. Not in progress, not pending — none. We are pre-launch. R23: magic-link email sign-in is the only authentication method. No SSO, no SAML, no OIDC, no MFA. R24: we do not have a VPAT. R26: the export right is contractual and real, but the self-service export tooling is not built, so today it is a request we fulfil rather than a button you press. We would score partial and we would say so. R14: we have no native SIS connectors — roster data is POSTed to our API or imported as a file, and any vendor telling you their PowerSchool integration is turnkey is worth pressing on. And under the fifth question above, we have no customers, no case studies and no references, because nobody has bought this yet.

If that list disqualifies us, it should — that is the point of running the process. If it does not, the more useful thing you can take from this page is the four questions in the previous section, asked of whoever you are actually going to buy from. See pricing, our compliance status including what we have not done, and surviving a renewal price increase.

Questions people actually ask

Related