EVALUATION & LAUNCH DOCUMENTATION
A clear path from questions to everyday work.
Use this public guide to understand the decisions, inputs and acceptance evidence that connect evaluation, configuration, migration, launch and ongoing ownership.
STAGE 01 · EVALUATION LEAD AND DEPARTMENT OWNERS
Evaluate
Establish the outcomes and evidence needed for a decision.
Prepare these inputs
- Institution type, academic model and operating scale
- Priority workflows with a normal path and an exception
- Mandatory access, integration and usability requirements
Work through the decisions
- Rank requirements by institutional impact and distinguish mandatory needs from preferences.
- Use fictional scenarios in the demonstration and record what is demonstrated, explained or unresolved.
- Compare scope and responsibilities alongside commercial proposals, then assign owners to open questions.
An evaluation record with observed behavior, dependencies, unanswered questions and decision owners.
KEEP THE HANDOVERS CONNECTED
Each stage leaves something the next one needs.
- 01
Evaluate
An evaluation record with observed behavior, dependencies, unanswered questions and decision owners.
- 02
Configure
Approved configuration scenarios, role boundaries and a maintained decision register.
- 03
Migrate
Reconciled records, reviewed exceptions and acceptance from the teams that own the data.
- 04
Launch
Business sign-off, trained users, active support ownership and an agreed follow-up review.
- 05
Operate
A clear change record, reviewed access and a prioritized improvement plan tied to institutional work.
Evaluation & launch documentationChoose the right level of detail → Know where an operational question belongsSEE HOW THE WORK CONNECTS
Read the public model in context
Public guidance explains the operating concepts; deployment details need a scoped review.
- 01
Choose the right level of detail
Start with the academic structure and record ownership if the institution is defining requirements. Move to migration and integration evidence when source systems are known. Use role-based practice and acceptance checks when preparing for a pilot.
- 02
Know where an operational question belongs
An existing account or learner-record issue belongs with the institution’s authorized administration. A public website error can use Qentak’s support form. Neither route should require sending passwords, credentials or sensitive student records through a general public enquiry.
Illustrative workflow · Shape the details around your institution.
A CLOSER LOOK
Use public guidance to prepare the implementation conversation.
This documentation explains evaluation and rollout responsibilities. Institution-specific configuration, authenticated administration and provider contracts require the agreed delivery scope and the appropriate controlled documentation.
Choose the right level of detail
Start with the academic structure and record ownership if the institution is defining requirements. Move to migration and integration evidence when source systems are known. Use role-based practice and acceptance checks when preparing for a pilot.
Know where an operational question belongs
An existing account or learner-record issue belongs with the institution’s authorized administration. A public website error can use Qentak’s support form. Neither route should require sending passwords, credentials or sensitive student records through a general public enquiry.
Need to investigate a specific requirement?
Use the capability directory to find the relevant workflow, the architecture pages for technical evaluation and the readiness guide to identify the institutional owner.
TURN THE READING INTO A USEFUL CONVERSATION
Bring your questions. Start with your context.
Use a workflow, a checklist or an unresolved decision to shape a tailored demonstration.


