EdTech Evaluation: Questions Every Educator Should Ask

You evaluate digital platforms well when you treat them like instructional materials plus a data system, then you verify the vendor’s promises in writing before a single student signs in. The right questions help you protect student privacy, reduce staff workload, meet accessibility expectations, and avoid tools that look polished but fail in real classrooms.

You’re about to make decisions that shape daily instruction, student data exposure, and teacher time. This guide gives you the exact questions educators use to vet platforms with administrators, IT, special education teams, and vendors. You’ll walk away with a practical way to screen tools quickly, run a tight pilot, and document what you need for approval, contracts, and family communication.

How Do You Know If A Digital Platform Is Safe For Student Data (FERPA, COPPA) And Not Just Marketing?

Start by refusing vague answers. If the vendor says “we take privacy seriously,” push for plain-language detail: what data gets collected, why it’s collected, who receives it, how long it stays on their systems, and how you can delete it. When a vendor cannot answer those points without circling back to sales language, the tool is not ready for students.

Move the conversation from policy pages to enforceable terms. Privacy policies can change, marketing pages can be aspirational, and “standard terms” often give the vendor broader rights than your district expects. You need contract language that states the school’s agreement governs, limits data use to delivering the service, bans advertising or targeted profiling, and defines deletion and breach notification expectations.

Make “data minimization” your default stance. A learning tool rarely needs a student’s home address, personal phone number, location, contacts, or social graph. If a platform asks for those fields, require a documented reason tied to instruction or operations, then insist on a way to disable unnecessary collection. This is where many tools fail quietly: they gather more than needed because it is convenient for their analytics, not because it improves learning.

Ask about telemetry and monitoring, not just names and emails. Platforms collect behavioral signals: keystroke patterns, page views, device identifiers, IP addresses, timing, clicks, and content interaction. That data can still identify students when combined, even if names are removed. You need clarity on whether the platform builds profiles, whether it shares telemetry with third parties, and whether telemetry becomes training material for product development or algorithms.

Confirm how consent works for younger students and who acts as the decision-maker. Schools can sometimes provide consent on behalf of parents for school-authorized services, but that brings obligations. You need the vendor to supply the required notices about data practices, and you need your district’s process to match what the vendor is doing technically. If the tool is used at home and pushes families to accept consumer terms directly, it can create confusion and risk.

Press for retention and deletion procedures you can execute. “We delete upon request” is not good enough if there is no clear request process, no timeline, and no verification. You need deletion tied to student lifecycle events: end of class, end of year, withdrawal, graduation, teacher departure. If your district cannot enforce deletion, you are building an archive of student work and behavioral data that outlives any instructional value.

Lock down subcontractors. Many edtech tools rely on cloud hosting, analytics services, video platforms, content delivery networks, and support vendors. You need a list of subprocessors, what each one does, where data is stored, and how changes are communicated. If a vendor can swap subprocessors without notice, your district loses visibility and control.

Get specific about incidents. Ask how the vendor defines a security incident, how quickly you get notified, what information you receive, who pays for remediation support, and how they will communicate with families if needed. Vendor maturity shows up here. A serious operator has a prepared plan, a clear escalation path, and named responsibilities.

Operational checkpoint: ask what happens when a teacher leaves. Teachers often build classes, content libraries, rosters, and assessment banks. If an account is deactivated, can the school transfer ownership, export content, preserve records, and maintain continuity? If the answer is no, the platform creates institutional risk even if privacy looks acceptable.

What Questions Confirm A Platform Is Accessible For All Students (IEP, 504, Screen Readers, Captions)?

Ask for an Accessibility Conformance Report, often provided as a VPAT, for the exact product version you will deploy. A vague statement that the vendor “supports accessibility” is not a substitute for documented conformance claims. If the vendor cannot produce documentation, treat it as a procurement red flag and assume you will be fixing problems midyear with students who cannot wait.

Require commitments, not promises. Accessibility work often competes with new features, and schools pay the price when remediation gets pushed out. You need the vendor to commit in writing to fixing identified gaps on a defined timeline, with a process for reporting issues, verifying fixes, and communicating changes. Without that, support tickets become your accommodation plan, and that is not acceptable.

Test the workflows that matter in your environment. Accessibility is not a checkbox; it is whether a student can complete a task independently. Validate keyboard-only navigation, logical focus order, visible focus indicators, labeled form fields, meaningful error messages, and compatibility with screen readers. Confirm that captions work on every embedded video, transcripts are available, and audio controls are usable without a mouse.

Check color and contrast, but also check meaning. If the tool uses color alone to indicate correctness, priority, or status, students with color vision differences get excluded. If icons lack text labels, students using assistive technology miss information. You need redundant cues: text, patterns, labels, and consistent structure.

Pay attention to assessment features. Timers, drag-and-drop interactions, proctoring modes, and question navigation often break accessibility. Ask whether students can use alternative input methods, whether the platform supports extended time, whether it handles read-aloud needs, and how accommodations are applied without revealing private disability-related information to other students.

Confirm that accessibility extends to documents and exports. Platforms may be accessible, yet they generate inaccessible PDFs, images of text, or poorly tagged handouts. You need accessible templates, correct heading structures, alt text support, and export formats that preserve accessibility. If the platform breaks your accessible workflow, it creates downstream work for teachers and special education teams.

Clarify your responsibility boundaries. Schools own accommodations, vendors own product accessibility. You do not want a vendor telling teachers to “work around” a defect by making separate materials indefinitely. Require a clear escalation process and timelines so accessibility remains a product obligation, not an ongoing burden placed on educators.

How Can You Tell If A Platform Improves Learning Outcomes Instead Of Adding Screen Time And Dashboards?

Force the platform to declare its instructional job. A platform earns a place in your classroom when it solves a specific problem: feedback cycles, practice quality, language scaffolds, formative checks, differentiation workflows, family communication, or content distribution. If the vendor cannot state what changes in student behavior the tool produces and how you will observe it, the tool is probably a reporting layer chasing adoption.

Demand alignment to your curriculum and instructional model. A tool can be “research-based” and still misfit your standards sequence, grade-level expectations, or assessment approach. You need to map what students do in the platform to what you teach, how you assess, and what your pacing requires. Misalignment shows up as teachers building parallel lessons, then students doing extra tasks that inflate time-on-device without improving mastery.

Separate novelty from value. Many platforms feel useful during the first weeks because they are new, visually engaging, and full of analytics. Value shows up later when usage becomes routine. Ask what happens in month three: what features teachers still use daily, what students still do without prompting, and what the platform replaces. A tool that adds tasks without replacing anything increases workload and reduces instructional time.

Measure outcomes you can defend. You do not need a complex research study to make a strong decision, but you do need clean indicators. Identify a baseline, choose two or three measurable targets, define what success looks like, and set a short evaluation window. Track mastery checks, writing volume with quality review, error pattern reduction, assignment completion rates, or time saved on feedback cycles.

Run a pilot that mirrors real conditions. If a pilot only includes your strongest teachers or your most motivated classes, it will mislead you. Pick a mix of classrooms, include students with varied needs, and confirm the tool works on your actual devices and networks. A pilot earns trust when it reveals what breaks, how support works, and whether teachers keep using the tool when the initial excitement fades.

Ask what teachers stop doing when the tool is adopted. If the platform claims to save time, insist on the specific tasks it replaces. Does it reduce grading time, streamline feedback, simplify differentiation, cut down copy volume, reduce duplicate data entry, or shorten assessment cycles? If it does not remove work, you are buying another obligation.

Validate content quality and bias controls. If the platform generates practice items, feedback, summaries, or AI tutoring responses, require clarity on how content quality is validated, how errors are handled, and how the vendor monitors for harmful outputs. Your classroom runs on trust. A tool that produces frequent mistakes will be abandoned, even if analytics look impressive.

Will This Tool Get Blocked By The District Or Violate Policy If You Use It With Students?

Assume any tool that creates student accounts, collects student work, enables messaging, tracks behavior, or integrates with your learning management system needs formal approval. Many districts maintain approved-app lists and enforce technical controls. Even a useful tool can become a problem when it bypasses the district’s review process and triggers a shutdown midunit.

Check how the district categorizes tools: approved, conditionally approved, under review, blocked, or unapproved. Approval status often depends on the vendor signing a data privacy agreement, meeting accessibility expectations, supporting roster sync standards, and aligning to curriculum. If you start using a tool that is “under review,” plan for the possibility that you must stop using it, migrate data, or replace it quickly.

Ask what happens to student data if the tool is later removed from the approved list. You need a plan for exports, deletions, and record retention. If the tool is blocked, students may lose access overnight, and teachers can lose instructional materials and evidence of learning. A platform that cannot export data cleanly traps you and makes district governance harder.

Confirm communication rules before you use any messaging feature. Many districts restrict teacher-student communications to approved channels that support logging, archiving, and supervision. A tool that enables direct messages, comments, video calls, or social feeds may violate policy even if instructionally attractive. If you cannot guarantee compliant communication, do not use it with students.

Review integration requirements with IT early. Single sign-on, roster sync, gradebook passback, and library resources often require technical work. If the vendor promises “easy integration” but IT has not vetted it, you can lose weeks troubleshooting logins, duplicate accounts, and broken rosters. Adoption succeeds when account provisioning and access rules are predictable for teachers and students.

Plan for parental communication. Districts often require notifying families about approved services, privacy terms, and how student accounts are created. If the tool requires parents to create accounts, accept consumer terms, or connect student identities, you need district guidance. Family trust erodes fast when a tool surprises them with account requests or unclear data sharing.

What Should You Ask About AI Features If Student Work Might Be Used To Train Models?

Start with a direct question and do not accept deflection: does the vendor use student content, teacher content, or interaction data to train AI models, either their own models or third-party models? Ask whether training is opt-in, opt-out, or prohibited by contract. If a vendor cannot provide a clear answer, the AI feature is a risk you cannot control.

Define “content” broadly in your questions. AI systems can learn from essays, audio recordings, drawings, chat transcripts, feedback comments, files uploaded by students, and prompts typed into chat tools. They can also learn from metadata: time spent, click paths, error patterns, and behavior flags. You need a written statement of what is and is not used for training, and how the vendor enforces that boundary technically.

Require retention clarity for AI interactions. Many tools store prompts and responses for troubleshooting, quality monitoring, or safety review. You need to know how long logs are kept, who can access them, how they are secured, and how they are deleted. If prompts include personal details, the retention policy becomes a student privacy issue, not a technical detail.

Ask how the tool handles student safety and accuracy without turning your classroom into a moderation queue. Vendors may claim they filter harmful content, yet you need to know what is blocked, what is flagged, and what teachers must review. If the system produces frequent false positives, teachers lose time. If it misses unsafe content, you face a different problem.

Separate teacher-facing AI from student-facing AI in your evaluation. Teacher tools for lesson planning, rubrics, or resource generation carry different risks than student chat tutoring or automated feedback on student writing. Student-facing AI touches student data directly and can shape understanding through incorrect guidance. Treat those features as higher risk, and require tighter controls, clearer reporting, and stronger contractual limits on data use.

Require admin controls that match district governance. You need the ability to disable AI features by grade band, by role, by school, or by course. You also need auditability: which classes used AI features, what content categories were generated, what settings were applied. If you cannot control and observe the feature set, you cannot manage the instructional and privacy impact.

Ask how the vendor handles intellectual property and ownership. If students submit original work and the platform generates derivatives, you need clarity on who owns what, what the vendor can reuse, and how the platform prevents redistribution. This also affects teacher-created materials. Ownership terms that are acceptable for consumer apps may not be acceptable in schools.

Do Teachers Trust These Platforms After Rollout, And What Problems Show Up Once Students Log In?

Trust breaks when a tool shifts hidden work onto teachers. The most common failure patterns are predictable: login issues, unreliable rosters, unclear workflows, excessive notifications, confusing grading exports, and support requests that require teachers to become help desk staff. You can prevent much of this by asking vendors to walk through common failure points before adoption and by requiring a support plan that protects teacher time.

Pay attention to device expectations and personal-phone pressure. When a platform pushes app installs, multifactor authentication apps, or security tools onto personal devices, adoption drops and conflict rises. You need alternatives: web access, district-issued devices, hardware tokens, or kiosk modes. If teachers feel monitored or inconvenienced on personal devices, they will resist, and that resistance is rational.

Monitoring and surveillance features can also erode trust. Tools that track screens, flag behavior, or record student activity may be presented as safety or classroom management. You still need guardrails: who can turn it on, what data it captures, how long it stays, and how it is used in discipline. Overbroad monitoring creates fear, changes student behavior in unhelpful ways, and raises privacy questions families will ask directly.

Check whether the platform creates policy conflicts in communication and records. Messaging features can collide with district rules, and comments can become part of student records. Teachers need clear guidance on what to say, where to say it, and how to document concerns. A platform that feels informal can create formal problems when records requests or investigations arise.

Confirm training and onboarding realities. Vendor webinars are not training; they are product tours. You need role-specific training for teachers, special education staff, paraprofessionals, and administrators. Training should cover daily workflows, accommodation features, common troubleshooting steps, and what to do when something breaks. Without this, the tool becomes a small expert group’s project, not a schoolwide asset.

Ask how the vendor manages change. Platforms update frequently. You need a release communication method, admin control over feature changes, and a predictable cadence for updates that affect instruction. If changes arrive unannounced, teachers lose time, students get confused, and support tickets spike.

What Vendor Evidence And Documents Should You Require Before You Recommend Any Platform?

Collect a standard set of artifacts so you can compare tools without reinventing the wheel. Vendors are used to being asked for these, and serious vendors provide them quickly. Your job is to make the request specific and to file the documents where your team can reuse them during renewals, audits, and future evaluations.

Start with privacy and security artifacts. Ask for the vendor’s data protection terms, a clear list of subprocessors, data retention and deletion commitments, and incident response commitments. If the district uses specific agreements, require the vendor to sign them. Keep the focus on enforceable terms rather than public-facing statements.

For accessibility, require the VPAT or Accessibility Conformance Report and a process for reporting and remediating defects. Ask for known limitations and planned fixes. Vendors sometimes bury limitations in appendices; pull them into the adoption conversation so no one is surprised when a student cannot complete a task.

For instruction, ask for implementation guidance that is written for teachers, not administrators. You want usage expectations, time recommendations, best-fit grade bands, and content coverage notes. You also want evidence of effectiveness aligned to your use case, along with clarity on what outcomes are realistic in typical classrooms.

For technical fit, request integration documentation: single sign-on options, roster sync methods, supported standards, supported browsers, mobile app requirements, bandwidth requirements, and device minimums. A platform that works on new devices but fails on older models or restrictive networks will create equity gaps across classrooms.

For procurement readiness, request references from districts with similar demographics and device environments. Ask those references about support responsiveness, contract flexibility, platform stability, and what they wish they had asked earlier. You get better answers when you ask about operational pain, not satisfaction scores.

How Do You Run A Small Pilot That Produces A Decision You Can Defend?

Define the instructional target in one sentence, then select two or three success indicators you can measure without extra labor. If the pilot’s success criteria require weeks of manual data cleaning, the evaluation will fail. Pick metrics you already track or can export cleanly: quiz mastery checks, assignment completion rates, writing volume plus rubric scoring, time-to-feedback, or reduction in reteach frequency.

Choose pilot classrooms that match reality. Include a mix of grade levels, student needs, and teacher comfort with technology. If the tool requires special conditions to succeed, you want to learn that early. A pilot that only works with a super-user teacher is not a scalable adoption.

Control the setup. Standardize class creation, rostering, and permissions. Many pilots fail because each teacher sets up differently, then the tool is judged unfairly. You want a consistent configuration, documented settings, and a short checklist teachers follow. This also helps IT and curriculum teams see what adoption would look like at scale.

Track time costs explicitly. Ask teachers to log minutes spent on setup, troubleshooting, grading exports, and student support. You do not need perfection; you need enough signal to know whether the tool returns time or consumes it. If time costs spike during pilot and stay high, the platform is not ready for wide rollout.

Gather student usability feedback without turning it into a survey project. Ask students whether they can log in reliably, find assignments, submit work, review feedback, and use accessibility features if needed. Quick checks produce actionable issues. If students cannot navigate independently, teachers will become full-time guides, and learning will slow down.

End the pilot with a structured decision memo. Summarize what worked, what failed, what settings were required, what support was needed, and whether the tool met the success indicators. Include a recommendation: adopt, reject, or adopt with conditions. This document helps procurement, administration, and families understand the choice without re-litigating the same debates.

What Contract And Procurement Questions Protect You After You Adopt The Platform?

Protecting your school after adoption is about enforceable obligations. Contracts should define permitted data use, ban commercial exploitation, set deletion timelines, and clarify that the school’s agreement supersedes general consumer terms. If the vendor insists their public terms govern, you are accepting changing rules without approval, and that is a governance failure.

Require service-level expectations that match school operations. Ask about uptime targets, support response times, escalation procedures during school hours, and scheduled maintenance windows. If the platform supports assessments, downtime is not a minor inconvenience; it can derail instruction and disrupt grading cycles.

Address renewals and price changes up front. Lock pricing terms, define renewal notice windows, and require clear communication before feature deprecations. If a vendor can remove critical features or increase pricing without meaningful notice, your school becomes dependent without leverage.

Include exit rights and portability. You need export formats that are usable, timelines for data return, deletion verification, and support for migration. A platform is only safe to adopt if you can leave without losing instructional assets and student records needed for continuity.

Clarify ownership of teacher-created materials, student work, and analytics. Contracts should state what the vendor can and cannot do with content and derived data. If ownership language is vague, vendors can treat your classroom output as product fuel. Schools should not have to fight that battle after adoption.

Ensure the platform supports record-keeping needs. Communication logs, assignment histories, and grading exports may be subject to district retention policies. You need clarity on what can be archived, what can be exported, and what remains accessible after a student or teacher leaves. This reduces conflict and preserves institutional memory.

What Should Educators Ask Before Approving An EdTech Platform?

What data is collected, used, shared, and retained?
Is it accessible, documented, and testable?
What learning problem does it solve, measured how?
Can the district approve, control, export, and delete it?

Make Your Next Platform Decision Easy To Support And Hard To Regret

You protect students and teacher time when you treat platform evaluation as due diligence, not enthusiasm. You lead with privacy and accessibility requirements, verify claims in enforceable terms, and push vendors for clear answers on collection, retention, AI training use, and support obligations. You also demand instructional clarity: what the tool changes, what it replaces, and what success looks like in your curriculum. When you run a short pilot with measurable indicators and documented setup, you earn a decision you can defend to administrators, families, and colleagues. Keep your questions consistent across tools, store the vendor artifacts, and you’ll build an approval process that gets faster and smarter each cycle.

Application Deadline: September 15, 2023

Evaluating Digital Platforms: What Every Educator Should Ask