Case record · PECTECH · Phoenix Ember
livePhoenix Ember begins with a school noticing that a child needs support. It does not end when somebody fills in an assessment. Classroom staff, the SENCO, school leaders, parents and a wider school group each need a different part of the picture. The work behind Ember is making those parts connect without making everybody do somebody else’s job.
PECTECH owns the product and brings the inclusion expertise. Zero Drift is its contracted software supplier: we design, build, host and operate the service. This is a walkthrough of that work—not a claim that software makes decisions about children.
The job to be done
A teacher may notice a change. A teaching assistant may see a different pattern. An assessment makes the picture more consistent, but it is only useful if it leads to support, a named next step and a review. Lose a hand-off and the school starts reconstructing the story from notes, spreadsheets and memory.
Sarah Johnson has spent more than twenty years in inclusion and SEMH. PECTECH’s product brief describes that real workload. The software organises and carries it; the school retains professional judgement and responsibility for the child.
Inside the school
The roles are not decorative permissions on one giant dashboard. They govern the record each person can see, the work they can complete and the hand-off to the next person.
Teacher and teaching assistant
Staff work from their own pupil caseload, recording check-ins, observations and assessments where they happen. The point is not another score to file; it is keeping the context visible to the next person who needs to help. Role-based access keeps a classroom view from becoming an unrestricted school record.
Work avoided: reconstructing the story from separate notes and memory.
SENCO and inclusion team
The actions view brings together pupils needing assessment, concerns, approvals, interventions ending soon and support-plan reviews. An intervention has a plan and a session record. The Individual Support Plan stays live as the pupil’s record changes; it does not have to be rewritten from a stack of separate files at every review.
Work avoided: chasing dates, rewriting plans and assembling the same evidence again.
School leadership
Leaders can follow the school-wide picture over time, compare cohorts and see whether interventions are moving the indicators they target. A heatmap prompts a question; it is not a diagnosis or an automatic decision.
Work avoided: asking staff for a new spreadsheet each time the picture is needed.
School administrator
School setup covers branding, assessment cadence, term dates and features. Administrators can import pupils and staff, manage roles, run the academic-year rollover and inspect the audit trail. Help is organised around real tasks and school roles so routine changes do not have to become support tickets.
Cost avoided by design: repeat setup and access work done manually by the supplier.
Value this term, not jam tomorrow
The return is not dependent on opening ten more schools or a heroic forecast. It is the work a school can stop doing now.
The evergreen ISP. The plan combines the pupil’s current needs, support, targets, parent voice and review history with the SENCO’s own narrative. Live sections update from the underlying record while the plan is active; when it closes, a snapshot preserves what was true then. Staff work from the plan rather than hunting down which document is the latest version.
The EHCP evidence pack. Assessments, intervention history, observations, the current plan and action taken at SEN Support are assembled from that same pupil record into a downloadable PDF. A SENCO chooses the pupil and generates the pack; professional interpretation remains theirs, but gathering the underlying evidence no longer means copying it between files.
The small-school arithmetic
PECTECH’s workflow estimate is 45 minutes saved per teacher and four hours per SENCO each week. For a small school with four teachers and one SENCO, that is seven hours a week, or 280 hours across 40 school weeks. Value that time at a modest £20 an hour and the capacity returned is £5,600 a year—11.8 times the £475 annual school price, excluding VAT.
That is staff time available for pupils, not a promise to cut payroll. It also leaves out the slower, harder-to-price work: preparing for audits and inspections, monthly and quarterly planning, showing whether interventions are effective, and directing funding to the support that actually helps.
Beyond one school
A parent should not need the staff system. A group leader should not have to open pupil records to see whether its schools are keeping up. These are separate audiences with separate jobs, not two more tabs on the school dashboard.
Parent or carer
The parent view translates the current picture into plain-language categories, shows support and goals, and keeps requests and the school’s response together. It does not expose raw assessment scores or private staff notes. An informal message and a formal action request are deliberately separate channels.
Work avoided: repeated “what happened next?” calls when the record cannot be seen.
School group or trust
The group portal brings school-level patterns, a cross-school heatmap, benchmarking and reports into one read-only view. Group staff can spot where to ask better questions while schools retain responsibility for individual pupils and interventions.
Work avoided: collecting and reconciling separate returns from every school.
Persona-first, specification-driven
We did not start with a clever assessment screen and call it a minimum viable school service. PECTECH defined the people and their complete jobs first: classroom recording, inclusion action, leadership oversight, parent communication, group reporting, school setup and the operating work behind the subscription. Those journeys became the specification for roles, records, reports, alerts and the hand-offs between them.
That is why Ember arrived with the depth of a working service rather than the thin slice common to a point solution. The breadth is inspectable in the actual screens and the separate portals, not a feature roadmap offered in place of delivery. It also means a school can adopt it without waiting for a different team to build the missing administration around it.
The work behind the work
A school should not spend an evening assembling evidence it has already recorded. PECTECH should not need a developer every time an approved sentence in a document needs changing. Those are different kinds of avoidable work, and Ember addresses both.
Documents with rules, not guesses
Report numbers and document sections come from recorded assessments, plans, interventions and reviews. In an EHCP evidence pack, the current support plan appears when one exists; trend analysis appears when there are enough assessments to compare; observation evidence appears when observations have been recorded. The contents and section numbers follow what is actually included. A language model is not asked to invent the conclusion.
A platform administrator can change report wording for a jurisdiction, country, sector or language without changing the rules. They can preview a draft with sample data, publish it, see what changed and restore an earlier version. The editor can insert only values the document already supplies. The rules deciding which facts and sections appear stay in code; changing a sentence cannot silently change the arithmetic.
Work avoided: schools rebuilding documents; PECTECH buying a code change for every wording change.
Help grounded in the product
The help articles begin with maps of real screens, roles, actions and failure messages, each tied back to the code. AI turns those facts into short, role-specific task guidance. Three independent checks challenge factual claims against the mapped evidence; tests catch known false phrases, broken references and developer terminology leaking into the published article. The Help Centre then gives school staff, parents and group users the guidance relevant to their work.
That is a defence against plausible but imaginary instructions. It is not, by itself, proof that a tired SENCO can follow every guide on a busy afternoon. Factual verification and audience usability are different tests; the latter still needs a reader from the role to try the task and tell us where the explanation fails.
Cost avoided by design: maintaining a second, disconnected help manual. Fewer support calls is the aim, not a measured result we can claim yet.
Behind the service
Making the interface is not the whole business. Somebody has to bring schools on board, answer support questions, collect payment, publish useful material, detect failed jobs and keep the service healthy. Ember builds that ordinary operating work into the product instead of assuming a growing back office will absorb it.
Platform administrator and support
The operator view covers schools, access, subscriptions, invoices, exports and a shared inbox for support and system alerts. Health checks expose database status, scheduled-job failures and recent audit activity. Routine assessment reminders, review prompts and digests are scheduled work; exceptions surface for a person rather than hiding in a log.
Cost avoided by design: silent failures and manual checks across disconnected tools.
Marketing and revenue operations
Prospects can be imported and segmented; campaigns and multi-step journeys have suppression and send controls. A school can move through signup, trial, quote or subscription, while attribution and the lifecycle view show what outreach actually produced. Expired trials go to a human review queue rather than automatically becoming an invoice.
Cost avoided: a separate CRM and manual spreadsheet hand-offs for the outreach-to-sale journey.
The staff-hour calculation above is PECTECH’s workflow estimate. The additional inspection, planning and intervention benefits are real jobs the product supports, but we do not fold an invented cash value for them into the 11.8× figure.
Capacity and operating cost
A school service must survive a busy morning, a report run and a release day—not just look good with one person clicking through it. Our scale plan follows the bottlenecks we have measured, with room to change the shape as use grows.
Production starts with more than one web task and scales that pool with CPU demand. The database is multi-availability-zone, fronted by a connection proxy. Scheduled jobs run separately from the web service, so a reminder sweep is not part of a teacher’s page request.
Load testing exposed web CPU and PDF generation as pressure points. Report rendering now has separate compute and its own error and latency alarms; a heavy evidence pack should not consume the capacity serving classroom work.
We watch response times, CPU, job failures and database behaviour. Web capacity is the first lever; assessment writes are the path that can make the database a co-bottleneck, so the database has its own review and resize path. Backups, release checks and rollback are part of the operating model, not a rescue plan written after an outage.
The load exercise was a local test against a production-sized task, not proof of a national throughput number. We use it to decide what to isolate and measure next, not to print an impressive requests-per-second promise.
A live-system replacement
Ember’s production server was replaced while the existing product continued to matter to its users. The team first recorded important operating behaviour from the old route. Both old and replacement routes were then exercised against the same corpus: requests, retained state and responses. The release-gate run recorded 193 scenarios and 2,510 observations; inside that measured boundary it found no differences, crashes or unexplained one-sided results.
That is a strong, specific engineering receipt. It does not prove every imaginable behaviour is covered or that a new implementation is infallible. The old route remained a rollback net while divergence was exposed and closed. The comparison machinery was retained so future changes can be judged against something firmer than memory.
Read the plain-English account → Inspect the machine-readable receipt →
Ownership and relationship
PECTECH owns the product and customer offer; Zero Drift supplies the software under a revenue-linked commercial arrangement. Ownership, background tooling, operation and exit rights are matters for the actual agreement, not a marketing-page promise. Our published revenue-share model explains the kinds of terms a new product founder should ask us to define.
Related-party disclosure: PECTECH founder Sarah Johnson and Zero Drift co-founder Daniel Johnson are married. This case record describes our supplier work and public evidence; it is not presented as an independent customer testimonial. Sarah’s own account of the product is on PECTECH’s site.
The product is in school use. The screenshots show a working interface and the refactor receipt shows a bounded engineering result; neither should be mistaken for a pupil-outcome study or a current adoption figure. PECTECH is the right source for those claims.
Need software built with the domain founder’s authority still intact?
See how we work together