What district communications RFPs actually ask for
District RFPs in this category are largely copied from each other, which means a requirement written by one district in 2016 is still being scored against vendors today. This study codes public communications RFPs against a codebook published in advance, reports what is actually asked for and how it is weighted, and names the requirements that no vendor in the market can honestly satisfy — starting with two that Kastr fails.
| Requirement as usually written | Kastr today | The honest detail |
|---|---|---|
| SAML 2.0 or OIDC single sign-on for staff | No | Magic link is the only authentication method. There is no SSO, no SAML, no OIDC and no MFA of any kind. This is a hard fail and we will not bid around it. |
| Native SIS integration with named vendor | No | No native PowerSchool, Infinite Campus, Skyward, Aeries or Synergy connector exists. Roster data is POSTed to our REST API or loaded from CSV. |
| Automated notices triggered by SIS events | No | Notice rules can be configured in the interface. Nothing fires them. There is no rules engine running today. |
| Targeting by grade, school or bus route | No | Two audiences resolve: specific people, and everyone. Selecting a student expands to that student's guardians. Grade and route targeting do not work. |
| Push notifications to a district mobile app | No | Kastr sends SMS, email and voice. There is no push channel and no mobile app push token registration. |
| Attachments, photo or video sharing | No | No upload path exists anywhere in the product. |
| SOC 2 Type II report on request | No | Pre-launch and not audited. We will say so in a bid rather than claim an audit is "in progress". |
| Documented public API with rate limiting | Yes | 28 org-scoped REST endpoints, keys hashed at rest, four-tier rate limiting, signed webhooks with an SSRF guard. |
| Tamper-evident audit trail of all sends | Yes | Per-organisation SHA-256 hash-chained append-only log, append-only at both the database role and the row-security layer. |
| Multi-tenant data isolation | Yes | Postgres row-level security under a non-owner role, fails closed, with a cross-tenant leakage suite in CI. |
| Data export on demand | Contract right only | Clause 7.1 gives an unconditional export right in a machine-readable format at no charge. Self-serve export tooling does not exist yet. |
| Published pricing, no per-message fees | Yes | $3.50 / $3.25 / $3.00 per student per year by band, one tier, everything included. |
This table is published before the corpus is coded, deliberately. A vendor that publishes its own failures first cannot be accused of writing the codebook around them afterwards.
The codebook, published before coding starts
The unit of analysis is one requirement line in one solicitation, coded to a category. The codebook fixes the categories and the inclusion rules before any document is read, and it is versioned, so the exact instrument used in each edition stays retrievable.
Coding rules that matter, because they are where a study like this usually goes soft:
- Mandatory and desirable are coded separately. A "shall" and a "should" are different requirements and collapsing them inflates every frequency.
- A requirement is coded once per document however many times it is restated across scope, technical appendix and scoring sheet.
- Ambiguous lines are coded as ambiguous rather than being resolved to the coder's best guess. "Robust reporting" is not a requirement, it is a mood, and the share of the corpus made of moods is itself a finding.
- Double coding on a sample with the agreement rate reported. If two coders reading the same document disagree materially, the frequency table is not trustworthy and we would rather say so than publish it.
Corpus sources are public procurement portals — BidNet Direct, Bonfire, Vendor Registry, Periscope and DemandStar public postings — plus district purchasing pages, with issue date, state and enrolment recorded for every document.
Evaluation weights, and the number vendors guess at
Most RFPs publish their scoring weights and almost nobody has aggregated them. The study records, per solicitation, the weight assigned to cost, to functional response, to references and experience, to implementation and support, and to any local or preference factors.
Two things make this worth reading for a district rather than only for a vendor. First, most districts set their weights by copying another district's weights, which means the distribution reflects a small number of original documents propagated widely rather than fifty considered judgements. Second, a weight of 30 per cent on references systematically excludes any new entrant regardless of product, which is a policy choice districts are usually making by accident.
We have an obvious interest in that second point and we would rather declare it than pretend to neutrality. Kastr has no customers, so any solicitation weighting references heavily is one we cannot win. We think districts should know they are making that trade, and then make it deliberately either way.
Requirements nobody can meet as written
A section of the report is given over to the requirement lines that appear frequently and that no vendor in the market demonstrably satisfies, with the reasoning for each. Early candidates, to be confirmed against the corpus:
- Guaranteed delivery times for SMS. No platform controls carrier delivery. A vendor that agrees to a delivery-time SLA on SMS is agreeing to something it cannot enforce and will be measured against.
- "100% of families reachable." Reach is a function of the district's contact data, not the platform's. This requirement transfers a data-quality problem to a vendor that cannot fix it.
- Uptime commitments with meaningful remedies. Commonly requested at four nines, commonly granted with a service-credit remedy worth a fraction of a day's licence fee.
- Certified human translation of all messages, in real time. Frequently requested, structurally impossible at broadcast latency, and usually answered with machine translation that nobody in the evaluation asked about.
Where the corpus shows we fail a common requirement, that goes in the same section with the same treatment. The first two rows of the table at the top of this page are already there.
The requirement library, free to paste into your own RFP
The output district procurement offices will actually use is a clean, vendor-neutral requirement set published under CC BY in Markdown and .docx, with no gate. It is organised by function, written in specific and testable language, and annotated: any requirement the data shows is unmeetable as usually written carries a note saying so and a suggested rewrite.
Two design principles. It names no vendor and contains no requirement that only Kastr satisfies — a requirement library that quietly specifies its author is a rigged bid, and any district procurement officer would spot it in a minute. And it is written to be edited, with brackets where a district must make its own decision, rather than as a document to adopt unread.
Boilerplate drift gets its own finding: how much of the corpus is near-verbatim copied from another district's document, and how old the oldest surviving requirement language is. In a category where the product changed completely between 2016 and today, a 2016 requirement still being scored is a live procurement problem rather than a curiosity.
Questions people actually ask
What should a district communications RFP actually require?
Fewer things, written more testably. The most common defect in the documents we read is a long list of unmeasurable adjectives alongside a short list of the things that actually differ between platforms: how the roster gets in, what audiences resolve, what the audit trail proves, what the export clause promises, and what the total price includes. The published requirement library is our attempt at that set, and it names no vendor.
How do districts typically weight price against functionality in scoring?
The study aggregates published weights across the corpus and reports the distribution rather than a single average, because the spread is the interesting part. Anecdotally the weights are copied between districts more often than they are set, which means the aggregate reflects a handful of original documents. We will publish the actual distribution rather than repeat the anecdote.
Which commonly requested RFP requirements can no vendor actually meet?
The recurring candidates are guaranteed SMS delivery times, which no platform controls because carriers do; universal reachability, which is a function of the district's own contact data; and real-time certified human translation, which is structurally impossible at broadcast latency. Each gets a section with the reasoning and a suggested rewrite that a vendor can be held to.
How many district RFPs are copied from another district's document?
That is one of the findings the corpus is designed to measure, using near-verbatim passage matching across documents, and we will publish the share with the method rather than an impression. The related figure we are equally interested in is the age of the oldest requirement language still circulating, because in this category a 2016 requirement is scoring vendors against a product generation that no longer exists.
Can I reuse your requirement library in our own RFP?
Yes, without asking. It is CC BY, ungated, published in Markdown and .docx, and deliberately vendor-neutral. Districts and regional service agencies are exactly who it is for, and if it ends up pasted into a state template with our name in a footnote, that is the outcome we designed it for.
Does Kastr meet every requirement in this analysis?
No, and the table at the top of this page lists the failures before the corpus is even coded. We have no SSO of any kind, no native SIS connectors, no automated notice engine, no grade or route targeting, no push notifications, no attachments and no SOC 2 report. Those are hard fails against requirement lines that appear in a great many district RFPs, and a district for which any of them is decisive should not shortlist us.
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.