Meritura assessment workflow
Know what can move. Know what needs a decision.
Assessment software needs to explain the state of the case, not just display a queue. Use this walkthrough framework to inspect the evidence, ownership and exceptions behind each transition in Meritura.
Available to evaluate · supported scope and configuration confirmed in a walkthrough
Meritura is assessment-operations software for awarding organisations and EPAOs. It supports operating records and human decisions; it is not an assessment organisation, a regulator or a promise of recognition or a particular result.
UK-hosted, GDPR-compliant
Illustrative workflow
Follow the work through Meritura by Journey.
Review readiness
Accept, query or return the submitted material through an owned intake decision.
Start with the case
One record, several different questions.
A readiness query, an allocation decision and a quality finding all need attention, but they do not need the same action or person. A useful assessment workspace distinguishes the operating question from the evidence needed to answer it.
Meritura’s current software proposition brings case control, delivery records, marking, quality and human result release together. Evaluate the route with the roles that will use it and the assessment activity you intend to support.
| Stage | Question to demonstrate | Evidence to inspect |
|---|---|---|
| Intake | Can this case be accepted, or must something be queried? | Submitted material, applicable context and a recorded reason. |
| Allocation | Is the proposed person appropriate for this case? | Competence, conflict review and the allocation decision. |
| Delivery | What has been recorded and what remains outstanding? | Scheduled activity, evidence, delivery and marking records. |
| Quality | Is there an unresolved finding that should stop progression? | Review, response and the decision that resolves it. |
| Release | Who can release this outcome? | Authority, completed prerequisites and the retained decision. |
A complete case
Trace a normal path without skipping the gates.
Choose a fictional case with the normal evidence and roles your organisation needs. Start from intake and follow it through assessment activity to quality review. At each stage, ask what changed, who changed it and where the supporting record can be opened.
Then inspect the release step with the person who would hold that authority. The evaluation should show the supported controls rather than treat a screenshot of a finished case as proof that every prerequisite was checked.
- Identify the plan or assessment context retained with the case.
- Show the allocation, relevant review and named owner.
- Open the evidence and delivery or marking records.
- Resolve a quality finding through the supported route.
- Check the outcome record and any configured acknowledgement.
A case that should stop
The exception is part of the product.
After the normal path, introduce one deliberate gap. For example, an evidence item is missing or a quality finding remains unresolved. Ask what the system shows, which action is permitted and how the person responsible learns what is required.
Do not accept a test that resolves the issue by giving every user administrator access or editing a final record outside the intended workflow. A credible evaluation retains the reason, the owner and the controlled return to work.
Roles and organisation boundaries
Test the view a person should have.
The product’s role and organisation model should fit the assessment operation you are buying it for. Test a coordinator, an assessor, a quality reviewer and a read-only reviewer where those roles are relevant. Include a person who should not be able to view or change the example case.
Request the control evidence needed for procurement, including scope-specific access, audit and recovery information. A public website or a synthetic preview does not by itself prove a customer deployment’s controls.
Capture the result of the walkthrough
Leave with a supported scope and an exception list.
Record the case used, roles tested, methods and records demonstrated, exports inspected and gaps found. Classify each capability as demonstrated in the configured application, dependent on configuration, planned or outside scope.
Use that record to agree the next step with the product team. Confirm implementation responsibilities, support, data arrangements and commercial terms separately. Software supports the operating process; it does not decide regulatory status or replace an organisation’s professional judgement.
Questions before the next step
A clearer view of Meritura by Journey.
Why test a blocked case as well as a completed one?
A completed example shows the intended path. A blocked example shows how the team identifies missing information, prevents the wrong next step and returns the work to an owner.
Does a dashboard total prove readiness or quality?
No. Open the underlying case, evidence, review and decision. A total is useful for attention, but the operating judgement needs the supporting record.
What should be included in a product acceptance record?
Keep the scenario, environment, roles, capabilities demonstrated, gaps, relevant exports and the person accepting the result. Record what remains dependent rather than silently treating it as available.
Make the next conversation useful
Start with the work.
Explore the fit.
Bring your workflow, the people involved and the decisions you need to make.