The Education Robot Vendor RFP: Questions and Red Flags

A purchase order for classroom robots is a procurement decision, but it is also a curriculum commitment, a software dependency, a student data agreement, and a multi-year maintenance relationship. Most school purchasing processes are designed to evaluate hardware specifications and unit price. They are poorly designed to evaluate the four other dimensions — and those are the ones most likely to produce problems over a 3–5 year program horizon.

This article provides a structured RFP (request for proposal) question bank organized by category, followed by a red-flag checklist that identifies responses — or non-responses — that should prompt either a follow-up or a reconsideration of the vendor.

It is written for a STEM coordinator, district technology director, or procurement officer preparing a competitive or directed RFP for an education robotics platform. The questions are deliberately vendor-neutral: they apply to any platform regardless of grade band or price point.

Category 1: Curriculum and Pedagogical Alignment

This is the highest-stakes category and the one most commonly addressed superficially in vendor responses. A vendor who says "our curriculum is aligned to CSTA standards" has not answered the question. A vendor who provides specific standard codes, grade-band progression documents, and sample lesson plans has started to answer it.

Questions to ask:

1. Please provide your curriculum scope-and-sequence document for the grade band(s) we are evaluating. Which specific CSTA (Computer Science Teachers Association) K-12 standards, NGSS (Next Generation Science Standards) engineering practices, or state CS standards does each module address? Provide the standard code, not a general claim of alignment.

2. Is the curriculum included in the hardware purchase price? If not, describe the licensing model: per-teacher, per-student, per-school, or per-district? What is the annual renewal cost?

3. What teaching experience or background does a teacher need to deliver your curriculum? If the curriculum requires a CS background, describe the minimum preparation needed and the PD you offer to bridge that gap.

4. Can a teacher access the curriculum before purchase — for example, via a free trial account? If not, can you provide a full PDF of one complete multi-week curriculum module for our review prior to the purchase decision?

5. How frequently is the curriculum updated? What is the process when curriculum content is updated — do existing licenses get access to the new content, or is it behind an upgrade paywall?

6. Does your platform integrate with Google Classroom, Canvas, Schoology, or other LMS platforms we use? If yes, which specific features are available via LMS integration (assignment distribution, grade passback, student roster sync)?

Red flags:

• Curriculum is described as "available" but cannot be provided for review before purchase
• Alignment claims are general ("STEM aligned," "project-based learning") with no specific standard codes
• Curriculum requires a CS degree or teaching credential that most of your teachers do not have, with no PD pathway to address that gap
• Curriculum is sold separately at a price that doubles the effective cost of the program (and this was not disclosed upfront)
• LMS integration is listed as a feature but is only available on a higher pricing tier

Category 2: Repairability and Long-Term Durability

Education robots are used by students in classroom and makerspace environments. They will be dropped, they will lose parts, batteries will degrade, and cables will be chewed. A platform that treats units as disposable — replace the whole unit when anything fails — has significantly higher long-term costs and produces more e-waste than one designed for field repair.

Questions to ask:

7. Is the platform designed for field repair? What components can a teacher or school technician replace without voiding the warranty? Please provide a list of individually purchasable spare parts with current pricing.

8. What is the expected battery lifespan (in full charge cycles) at normal classroom use? After the battery reaches end-of-life, can it be replaced by the school, or must the unit be sent in for service?

9. What is your warranty policy? Does warranty coverage extend to normal use damage in a classroom environment (drops, minor impacts), or is it limited to manufacturing defects?

10. How are software updates delivered? Does updating the app or firmware require IT involvement, or can a teacher initiate updates directly? Are updates backward-compatible with existing curriculum activities?

11. What is your typical lead time for spare part orders? Do you maintain a parts inventory in the United States (for US buyers), or are parts sourced internationally with lead times that could interrupt a program?

12. What is the unit end-of-life plan? Is there a take-back or recycling program for units at end of life?

Red flags:

• No individual spare parts are available — only full-unit replacement
• Battery replacement requires returning the unit to the manufacturer or an authorized service center
• Warranty explicitly excludes drop damage or "misuse" without a classroom-appropriate definition
• Software updates have historically broken compatibility with older curriculum activities (ask for version history)
• Parts are only available through the vendor's online portal with long international shipping times

Category 3: Student Data Privacy (COPPA and FERPA)

This is a non-negotiable category for any school buyer in the United States. COPPA (Children's Online Privacy Protection Act) governs the collection of personal data from children under 13. FERPA (Family Educational Rights and Privacy Act) governs the privacy of student education records. Both apply to ed-tech platforms used in schools — and many vendors are not in full compliance with both.

Questions to ask:

13. Is your platform and its associated apps, coding environments, and cloud services compliant with COPPA? Please provide your COPPA compliance documentation or link to your children's privacy policy.

14. Is your platform compliant with FERPA as a school official? Does your Terms of Service or Data Processing Agreement include FERPA-required provisions for schools acting as data controllers?

15. What student data does your platform collect? Please provide a complete data inventory: what is collected, why it is collected, where it is stored, and how long it is retained.

16. Is student data ever used for advertising, product development, training machine learning models, or any purpose other than delivering the platform's educational functions? If so, describe those uses and how consent is obtained.

17. What is your process for student data deletion when a school ends its subscription? How long does the vendor retain student data after a subscription lapses?

18. Have you signed a Student Data Privacy Consortium (SDPC) agreement or an equivalent data privacy agreement for any state or district? If yes, please provide a reference.

19. Is a Data Processing Agreement (DPA) available for our district to execute? Will the vendor sign our district's standard DPA, or only its own?

Red flags:

• The vendor cannot point to a specific children's privacy policy or COPPA compliance statement
• Student data is collected for purposes beyond platform delivery (advertising, analytics resale, model training) without clear opt-out
• The vendor refuses to sign a district DPA and only offers its own terms
• Student accounts for children under 13 are created with individual email addresses rather than through a teacher-managed roster
• Account deletion is a manual process that requires contacting support, with no guaranteed timeline
• The vendor is based outside the United States and cannot confirm compliance with US federal privacy law

Category 4: Software Longevity and Account Model

Education programs typically run 3–7 years before a major platform refresh. A vendor whose coding environment becomes unsupported, whose app is removed from the App Store, or whose company is acquired and the product discontinued mid-program creates a serious disruption. These risks cannot be eliminated, but they can be assessed.

Questions to ask:

20. How long has this specific product been commercially available? What is the oldest version of your platform still actively supported?

21. What is your product roadmap for this platform over the next 2–3 years? Are there major platform versions planned that would require schools to re-purchase hardware or curriculum?

22. What happens to a school's curriculum licenses, student accounts, and saved student work if your company is acquired or the product is discontinued? Is there a data portability provision — can schools export student work and curriculum in a standard format?

23. What coding environments does your platform support? Is your coding environment proprietary (runs only on your platform) or standards-based (Scratch, MicroPython, Python 3, ROS)? If proprietary, what is the migration path for students who want to use those skills on other platforms?

24. Is the companion app (if applicable) available on both iOS and Android? Does it work on Chromebooks? What is the minimum OS version requirement, and how far back does device compatibility extend?

25. What is your pricing model for multi-year curriculum licenses? Is multi-year pricing available, and is it fixed or subject to increase at renewal?

Red flags:

• The product has been available for less than 3 years with no track record of long-term support
• The coding environment is entirely proprietary with no export or migration path
• The vendor cannot describe a data portability or account transition process in the event of acquisition
• App availability is iOS-only, or the Chromebook version is significantly feature-reduced compared to the iOS app
• Pricing at renewal is not contractually fixed, and the vendor is unwilling to commit to a price cap

Category 5: Consumables and Total Cost Transparency

As detailed in Article 2 of this series, hardware is typically less than half the three-year cost of a robotics program. A vendor whose quote does not include consumables, curriculum licensing, and PD cost estimates is not giving you a real cost picture. A vendor who declines to provide that picture on request is being deliberately opaque about cost.

Questions to ask:

26. In addition to the hardware quote, please provide a three-year cost estimate that includes: curriculum licensing at our school/district scale; estimated annual consumables and spare parts for a class set; and your recommended PD program with cost.

27. What is the price of each consumable item — batteries, charging cables, coding mats, replacement sensors — individually? Not bundled; individual SKU pricing.

28. What is your pricing for multi-school or district-wide curriculum licenses? Is there a volume discount structure, and if so, at what thresholds?

29. If we purchase hardware this year and want to expand the program next year, will hardware prices be the same, or are they subject to change? Is there an educational pricing guarantee?

30. Are there any additional fees not captured in the hardware and curriculum quote — such as onboarding fees, support fees, LMS integration fees, or data hosting fees?

Red flags:

• The vendor provides only a hardware quote and is unable or unwilling to estimate three-year TCO
• Consumable prices are not publicly available; schools must contact sales for pricing
• Annual curriculum renewal is priced higher than the initial license with no contractual cap
• Surprise fees appear in the contract that were not in the quote

Category 6: Cross-Platform Support and Ecosystem Lock-In

Curriculum lock-in — where skills and activities developed on one platform are unusable on another — is acceptable if the platform delivers sustained value. It becomes a problem when the platform is discontinued, when students move to a school that uses a different platform, or when the school wants to add a higher-complexity platform without abandoning the curriculum investment already made.

Questions to ask:

31. Does your curriculum build student skills that transfer to other coding environments and platforms? Specifically, if a student completes your middle-school curriculum, what coding skills do they have that would be applicable in a general Python environment, a block coding environment on a different platform, or a robotics competition context?

32. Does your platform support any open coding standards (MicroPython, Python 3, Scratch compatibility, ROS)? If yes, which ones, and to what extent?

33. Is your hardware compatible with any third-party accessories, sensors, or expansion systems, or is expansion limited to your own accessory line?

34. Can curriculum materials (lesson plans, activity guides, rubrics) be exported by the teacher in a format (PDF, Word, Google Docs) that can be used on other platforms or in other tools?

Red flags:

• The coding environment is fully proprietary with no transferable skill pathway
• Hardware is only expandable with the vendor's proprietary accessories
• Curriculum export is not available; all content is locked inside the vendor's platform
• The vendor claims curriculum "aligns with" a standard language like Python but the environment only supports a custom block system with no text equivalent

The Consolidated Red-Flag Checklist

Before signing a contract, confirm that none of the following are true:

Curriculum:

• No scope-and-sequence document with specific standard codes available for review
• Curriculum requires pre-review purchase
• Curriculum is a separate, undisclosed cost

Repairability:

• No individual spare parts catalog with pricing
• Battery replacement requires manufacturer service
• Warranty excludes normal classroom use damage

Data Privacy:

• No COPPA-specific children's privacy policy
• Student data used for purposes beyond platform delivery
• Vendor will not sign district DPA

Software Longevity:

• Product history under 3 years with no track record
• No data portability or account transition process
• App compatibility gap with your device fleet

Cost Transparency:

• No TCO estimate available on request
• Consumable prices not publicly listed
• Annual renewal not contractually capped

Lock-In:

• No transferable coding skills or standards-based language
• Curriculum not exportable from the vendor's platform

Any single item on this checklist is worth a follow-up question. Three or more items in the same category is a meaningful signal about the vendor's approach to school relationships.

This article concludes the six-part buyer education series on classroom robotics programs. To start from the beginning — with the story of why programs fail and the framework for building one that works — see Why Classroom Robots End Up in the Closet.