Two to three weeks to live. Ninety days to routine.
Setup is short because we do it with you: your framework, your roles, your evaluation calendar. What comes after setup is what decides whether a rollout holds. Below is who does what, in which week, and what the first ninety days actually contain.
Timings reflect typical district rollouts. A multi-school phased start runs on a longer clock, described further down.
Four things decide whether a rollout works.
Price is the question that gets asked first and the one that matters least. These four are the ones we hear from principals and district leaders once the contract is not the topic anymore, so the delivery model is built around them.
Standing up one more system, from scratch.
The fear is a blank template and a login. Districts already have rubrics, calendars, and rosters, and no appetite for retyping any of it.
Our team configures the portal with you: framework rubrics loaded, observation forms built, evaluation cycles dated, accounts created from a roster file. Your SuperAdmins watch every setting get made, so the person who has to change a form in March is the person who saw it built.
Working around a process you already run.
Evaluation calendars are set months ahead. A platform that demands its own sequence gets abandoned by November.
2gnoMe aligns to the framework and calendar you already use. Observation forms mirror the ones your evaluators fill in now. No one is asked to drop a cycle mid-year or run two systems in parallel to satisfy the software.
Training principals and teachers at once.
Whole-staff training days are expensive and forgettable. And a principal who cannot answer a teacher's question stalls the rollout for a whole building.
Admins are trained first, in one focused session, because they are the ones teachers ask. Teachers get live sessions where they want them plus short role-specific walkthroughs inside the portal, on their own schedule. There is no separate learning system to log into.
Getting staff to believe it is for them.
The hardest part, and the one that no amount of configuration fixes. If teachers read a growth platform as surveillance, adoption numbers stay flat no matter how clean the setup was.
Teachers see the same rubric language their evaluators see, the same evidence, and their own analytics. No teacher learns their own rating second hand. Transparency is the mechanism here, not the marketing.
From first call to first observation.
Most districts are fully live within two to three weeks. This is what those weeks contain, who is in the room for each part, and what you hold at the end of it.
Discovery and scoping
One working session, usually an hour. We confirm which framework you evaluate against, which roles need accounts and at what permission level, what your evaluation calendar looks like, and what you want to be able to see at the end of the year. If your rubric exists as a document, bring it. That file is the direct input to configuration, not a reference for a later conversation.
Portal configuration
We build the portal against the scope: framework rubrics entered, observation and walkthrough forms created, evaluation cycles dated, accounts created and roles assigned. Accounts come from a spreadsheet roster, so nobody types nine hundred names. The part that matters more than the build is the handover: your SuperAdmins are walked through each setting as it is made, so ownership transfers with the portal rather than sitting with us.
Admin and leader training
Leaders go first, deliberately. One focused session covers the whole evaluator workflow: opening a cycle, running an observation or a walkthrough, drafting and releasing feedback, reading a building-level pattern. Most admins are operational after that single session. Anything left over is covered by role-specific walkthroughs in the Knowledge Base and a follow-up call, rather than by waiting for the next scheduled training.
Teacher launch
Teacher onboarding itself takes minutes: log in, complete a first self-reflection against the framework, see the learning resources it points to. The work is not the software, it is the launch. Teams that want a live session get one. Everyone else uses the short role-specific videos in the portal. Building leaders get a rollout kit, so a principal running the launch has an agenda and an exercise rather than an announcement to improvise.
First observation cycle
Most districts complete a first full observation cycle inside the first month. This is the point where the thing stops being a rollout and becomes the way work gets done. We look at the engagement pattern with you while it is still early: which buildings are moving, which forms are creating friction, which rubric language is being read differently by different evaluators. Awkward configuration gets fixed here, before it hardens into how everyone does it.
Your rubric, in your words.
Framework configuration is the step most vendors describe in one line. It is also the step that determines whether teachers recognise the language on screen as the language they are actually evaluated against. Here is the real sequence.
You name the framework
The Danielson Framework is the most common, and we work directly with The Danielson Group on how it appears in practice. State frameworks, network rubrics, and locally written frameworks are all supported. If you evaluate different groups against different rubrics, teachers on one and counselors or paraprofessionals on another, that is an ordinary configuration rather than an exception.
Components are mapped as written
Domains, components, and performance levels go in as your document words them, not as a paraphrase that fits our schema. This matters because the level descriptors are what a teacher reads when they self-assess and what an evaluator reads when they rate. If those two people are reading different sentences, the common language is gone before you start.
Forms are built from the mapped rubric
Full observations, short walkthroughs, and informal drop-ins can each have their own form, drawn from the same underlying components. Different lengths and different purposes, comparable data. You decide which roles use which form and how many of each a cycle requires.
Cycles get real dates
Baseline windows, mid-year, end of year, and per-role variations where they exist. The calendar drives reminders and completion tracking, which is why it is set before launch rather than after the first missed deadline. Your SuperAdmins can move a date afterwards without opening a ticket.
Where custom work starts. Configuring your standard framework is part of onboarding. Building a rubric or observation template that does not exist yet, or connecting 2gnoMe to another system, is scoped separately as custom work. We will tell you which of the two your request is before anyone commits to a date. License pricing lives on the pricing page.
Four roles, drawn on purpose.
Permissions are the quiet half of an implementation. Draw them wrong in either direction and you get teachers who feel watched or admins who cannot do the job. This is the default shape. It is adjustable during configuration, and your SuperAdmins can change an assignment later without our help.
Teacher or participant
- Self-assess against the framework and re-assess as the year moves
- See their own results over time, by component
- Read feedback and observation notes released by their evaluator
- Work through learning resources targeted to their own gaps
- Set goals and track them against evidence
- See another teacher's reflections, ratings, or feedback
- See building or district level dashboards
Principal or coach
- Run formal observations, walkthroughs, and informal drop-ins
- Draft and release feedback, with AI-assisted drafting available
- See growth and completion patterns across their own staff
- Assign learning to an individual, a team, or a cohort
- Track where a cycle stands without asking central office for a report
- See staff in buildings they are not assigned to
- Change framework structure or create accounts
District administrator
- See district-wide dashboards across buildings and cohorts
- Track completion and engagement by school, role, or cycle
- Read growth patterns at cohort level rather than person by person
- Export evidence for board reporting and state compliance
- Change framework structure, forms, or cycle dates
- Create, deactivate, or reassign accounts
SuperAdmin
- Configure the framework: domains, components, performance levels
- Build and edit observation and walkthrough forms
- Create, deactivate, and reassign accounts, including from a roster file
- Assign and change roles and building assignments
- Set and move evaluation cycle dates
- This is the role we hand over during configuration, so keep it small and keep it staffed
You are not handed a login and wished well.
Four things carry the training load, and they are deliberately different from each other. One is available at two in the morning, one has a person in the room, one gives building leaders something to run, and one is there when something breaks.
Role-based videos, inside the portal
Short walkthroughs cut by role, sitting at the point of use rather than in a course. A principal looking for how to release feedback does not sit through a teacher module to find it. No separate learning system, no waiting for the next scheduled session, and available at whatever hour someone actually gets to it. See the Knowledge Base →
Live sessions, train the trainer
Sessions for admins and leaders, delivered live over video or in person, aimed at making your people the trainers rather than making us a dependency. Districts that would rather run their own launch get the trainer prep and the materials instead. Our team is known for turning up, and that is the part we would rather be known for than the feature list.
Rollout exercises
Short structured exercises for staff meetings and team time: walking a first self-reflection together, calibrating on what a rubric level actually means, practising a round of feedback writing. They exist so a building leader has something concrete to run in twenty minutes, instead of a slide announcing that a new platform is now live.
Support that stays after launch
A ticketing desk for anything broken, open around the clock, and your onboarding contact on the phone for anything that is merely unclear. During rollout the calls are frequent by design. After it, they turn into review sessions on what the data is showing and what to change. Open a support ticket →
Self-driven
For schools that would rather move at their own pace and already have someone internal who likes owning systems.
- Full role-based Knowledge Base and recorded modules
- Support ticketing around the clock
- SuperAdmin setup guide for your own configuration work
Guided rollout
For districts that want a person alongside them through the first cycle and regular check-ins afterwards.
- Everything in the self-driven track
- Live train-the-trainer sessions for admins and leaders
- Quarterly review sessions on engagement, results, and what to change
- A named onboarding contact through the first cycle
Ninety days, three targets.
Two to three weeks is the setup number. Ninety days is the adoption number, and it is the one worth holding us to. Each stretch has a target, a short list of what happens, and the measure we watch with you.
- Portal live with your framework, forms, calendar, and roster
- Admins and leaders trained and running cycles
- Teachers logged in, first self-reflections submitted
- First observation cycle underway
- Rollout exercises run in staff or team meetings
Login coverage building by building, so a quiet school gets a call rather than a place on a report.
- First full observation cycles completed, feedback released
- Teachers working through resources tied to their own gaps
- Building leaders reading their own patterns instead of requesting reports
- Configuration adjusted for whatever the first cycle exposed
- Second wave of live sessions for teams that asked
On-time completion, and which buildings are drifting while the rest hold.
- Check-in with district leadership on the engagement pattern
- Results read against the goals set in discovery, not against generic benchmarks
- Baseline locked for year-over-year comparison
- Reporting exports tested before anyone needs them urgently
- Expansion scoped where it makes sense: new roles, buildings, or frameworks
Share of staff with a completed reflection and at least one observation on record.
For a large district piloting first, a reasonable engagement benchmark is around three quarters of participating teachers with a completed initial assessment by the end of the pilot window. We set the actual number with you in discovery rather than importing it.
Three ways to start big.
A single-school launch and a thirty-school launch are not the same project. Districts above a few hundred staff usually pick one of these three shapes, and the choice is about your appetite for evidence before commitment, not about our capacity.
Pilot, then expand
Start with roughly ten to fifteen percent of staff, chosen as a deliberately mixed set of schools and teams rather than the enthusiastic ones. Refine configuration against real use, then scale with evidence in hand.
All schools at once
Every building live on the same date, with intensive training in the first weeks and adjustments made in real time. Faster to value, and it demands more of your leadership team in the first month.
By region or cluster
One region or cluster at a time, expanding roughly every two months, with each wave onboarded by people who have just done it themselves. Slower, and much easier to staff.
Districts that decide mid-year typically pilot through the spring, prepare over the summer, and have full staff live in the opening weeks of the new school year. Single sign-on and roster integration are handled as part of an enterprise configuration.
The part they remember is the people.
The onboarding experience was unlike anything I expected from a software vendor. They knew our framework, they knew our calendar, and they made sure our principals felt confident before we ever went live with teachers.
We have worked with a lot of EdTech platforms. Most of them hand you a login and a help center link. 2gnoMe scheduled training sessions whenever we needed them, and the team actually knew the Danielson Framework deeply.
Look at the thing you would be rolling out.
The rollout is only worth planning if the platform underneath it holds up. Three ways to check that before you plan anything.