Writing an RFP for school communication software
Most district communications RFPs are inherited. A requirement written in one district in 2016 is still being scored against vendors today, which is why so many responses are compliant and useless. This page gives you a requirements set organised by what it actually tests, and a decoder for the eleven answers that mean nothing.
| What the response says | What it usually means | Ask this instead |
|---|---|---|
| "Yes, fully supported." | Supported by something, somewhere, possibly on a roadmap or in a partner product | "Show it in a trial tenant on our data, this week." |
| "Industry-standard encryption." | TLS in transit, which is table stakes and not an answer about isolation | "How is one district's data prevented from being returned to another district's query?" |
| "Enterprise-grade security." | No specific control is being claimed | "Name the control, the mechanism, and the test that proves it fails closed." |
| "SOC 2 in progress." | Anything from an audit under way to a kickoff call | "What is the report type, the audit window, the auditor, and the date the report will exist?" |
| "Unlimited messaging." | Unlimited in one channel; voice or SMS metered separately | "Which channels are metered, at what rate, and what was a district our size invoiced last year?" |
| "Full data export available." | Sometimes a self-serve export, often a support ticket and a services quote | "Is export a right in the contract, is it self-serve, what format, and is there a fee?" |
| "Seamless SIS integration." | Frequently a CSV or a roster API the district must populate | "Does your code connect to our named SIS, or do we push data to you? Show the connector." |
| "99.9% uptime." | A marketing figure unless it is in the SLA with a remedy | "What is the SLA number, what is the remedy, and where is the public status history?" |
| "Translation into 100+ languages." | A machine-translation vendor's language list, restated | "Which engine, which languages does your interface actually expose, and can a sender read the translation before it sends?" |
| "Pricing is customised to your district." | The number depends on what you will pay | "Send the standard rate card and the three-year total including escalation and every module we need." |
| "That is on our roadmap." | Not built | "Is it contractually committed with a date and a remedy? If not, score it as absent." |
Score every roadmap answer as zero. Not as partial credit — zero. A district that scores roadmap items generously ends up buying the best presentation rather than the best product, and the roadmap item that decided the award is the one that slips.
Nine sections, and what each is actually testing
Structure the requirements set so each section tests one thing. A sixty-item flat list produces a sixty-item flat response and nobody learns anything.
- Delivery (items 1–9). Channels, failover behaviour between them, quiet hours, emergency override, per-recipient delivery outcomes, and what the vendor calls "delivered". This last one matters more than districts expect: a platform that counts "handed to the carrier" as delivered will report success on messages nobody received.
- Translation (10–16). Engine, exposed language list, whether the sender can preview the translation before a family reads it, what happens when the translation service fails, and whether translation is metered.
- Audience and identity (17–24). How a person with two roles at two schools is represented, how guardianship and custody are modelled, how a withdrawn student's family stops receiving messages, and precisely which audience selections resolve.
- Governance and audit (25–31). What is logged, whether the log can be altered, who can alter it, how a record is produced for a public-records request, and what a records export looks like.
- Security (32–39). Tenancy isolation mechanism, authentication methods, key handling, sub-processor list, incident notification path and timeline.
- Integration (40–46). Roster mechanism, public API, webhooks, rate limits, and whether integration is a capability or a licence line.
- Accessibility (47–51). WCAG conformance level, current VPAT, how accessibility regressions are caught, and whether family-facing surfaces are covered as well as staff ones.
- Support and cadence (52–57). Response targets in and out of term, escalation path, and when the vendor ships breaking changes relative to your school year.
- Contract and exit (58–62). Price lock, escalation cap, export right, family-monetisation prohibition, change-of-control exit. These five decide more of your total cost than the other fifty-seven combined.
Requirements Kastr would fail, by section
Publishing this is not modesty. It is the only way the rest of the page is worth anything, and it saves both of us a wasted evaluation.
- Security section. Any requirement for SAML, OIDC, Google or Microsoft single sign-on, or MFA. Magic link is our only authentication method. There is no SSO code of any kind. If your requirement is mandatory, we are non-responsive and you should score us zero.
- Security section. Any requirement for a current SOC 2 Type II report. We are pre-launch and not audited. We will not write "in progress" to avoid a zero.
- Delivery section. Any requirement for file attachments, photo or video sharing, or mobile push notifications. Kastr sends SMS, email and voice. There is no upload path and no push channel.
- Delivery section. Any requirement for a dedicated emergency console, two-person authorisation, or a stated delivery time for a full-district send. None of those exist, and we publish no load-test figures.
- Audience section. Any requirement to target by grade, school, class or bus route. Two audiences resolve: specific people, and everyone. Selecting a student expands to that student's guardians.
- Integration section. Any requirement for a native PowerSchool, Infinite Campus, Skyward, Aeries or Synergy connector. Roster data is POSTed to our REST API or loaded from CSV.
- Governance section. Any requirement for automated notices triggered by SIS events. Notice rules configure in the interface; no engine fires them.
- Governance section. Any requirement for enforced retention schedules or a cryptographic deletion certificate. Retention defaults are published; there is no purge job enforcing them.
- Contract section. A requirement for self-serve export tooling. Clause §7.1 gives an unconditional export right in a machine-readable format at no charge, and we will honour it — but the one-click tooling does not exist, so the right is currently satisfied by us doing the work.
- Any section requiring district references. We have none. Nobody is live.
What we would score well on: published pricing with a contractual cap, a 28-endpoint org-scoped REST API with signed webhooks and an MIT-licensed CLI and MCP server, Postgres row-level security under a non-owner role that fails closed with a cross-tenant suite in CI, a SHA-256 hash-chained append-only audit log, cost-and-reach preview before send, translation preview before send, and a roster withdraw guardrail that aborts above 50 per cent.
Weighting, and the four district profiles
Weights before demos. Always. A committee that sets weights after seeing presentations sets them around what impressed it.
- Safety-led district. Delivery and emergency 40 per cent, governance 20, security 15, cost 15, everything else 10. This profile should be shortlisting notification specialists.
- Equity-led district. Translation and reach 35 per cent, delivery 20, cost 20, governance 15, integration 10. Translation preview and true per-recipient delivery outcomes matter more here than any feature count.
- Budget-constrained district. Cost and contract terms 40 per cent, delivery 25, support 15, security 10, integration 10. Weight the three-year total including escalation, not year one.
- Technically mature district. Integration and governance 40 per cent, security 25, delivery 20, cost 15. This is the profile that should ask for API documentation as a response attachment rather than a claim.
Five contract clauses worth writing into the RFP itself, so they are scored rather than negotiated afterwards. A price fixed for the initial term with year-four escalation capped at the lesser of an index or a fixed percentage, with nothing excluded from the cap. An unconditional data export right in a machine-readable format at no charge. An explicit prohibition on the vendor marketing or selling to district families, and on any family-facing subscription revenue. A change-of-control exit right allowing termination with export and a prorated refund within a defined window after an acquisition or a material change of data terms. And a requirement that breaking changes land outside the school year. Ours are §3.2, §7.1, §9.4 and §11.2; borrow the language whoever you buy from.
Questions people actually ask
What should be in an RFP for school communication software?
Nine sections, each testing one thing: delivery, translation, audience and identity, governance and audit, security, integration, accessibility, support and release cadence, and contract and exit terms. The last section decides more of your total cost than all the others combined and is usually the thinnest one in an inherited template.
What questions do communication vendors avoid answering?
The consistent ones are how a message counts as delivered, which channels are metered and at what rate, whether export is a self-serve capability or a services engagement, whether an SIS integration is their code connecting to your system or your team pushing data to theirs, and what the escalation cap actually excludes. All five have a precise answer, and a vendor that will not give one is telling you the answer.
Should an RFP require SOC 2 certification?
If your policy requires it, require it and score it as pass or fail — but understand that it eliminates most young vendors, which may be exactly what you want or may narrow you to four incumbents. If you want the assurance without the elimination, ask for the underlying controls instead: tenancy isolation mechanism, key handling, incident notification timeline, and evidence that isolation is tested rather than asserted.
How do we score vendors that will not disclose pricing?
Require a rate card and a three-year total in the response itself, with every module you need included, and score a refusal as a low score on transparency rather than treating it as neutral. Bring comparables from board packets and co-operative awards so a non-disclosure cannot be a bargaining advantage. A vendor that will not price against a defined scope in a public procurement is asking you to bid against yourself.
What contract terms should a district insist on?
Five: a price fixed for the initial term with a lesser-of escalation cap and no carve-outs; an unconditional machine-readable export right at no charge; a prohibition on the vendor marketing or selling to your families; a change-of-control exit right with export and a prorated refund; and a commitment that breaking changes ship outside the school year.
Which requirements would Kastr itself fail?
Single sign-on in any form, MFA, SOC 2, attachments and media, push notifications, native SIS connectors, an emergency console with two-person authorisation, automated event-triggered notices, enforced retention, grade, school or route targeting, self-serve export tooling, and any requirement for district references. That list is published in full on this page and in our comparison matrix rather than discovered during a demo.
One price. Every feature. Locked for three years.
$3.50 per student per year under 5,000 students. No tiers, no add-on modules, no per-message fees. Published on the site because you should not have to book a call to learn a price.