Where the queue sits in the verification flow
The manual review queue is the holding point for cases that do not pass straight through automated checks. A customer may have a blurred document image, a mismatch in name details, a weak video signal, or a face comparison that needs a second set of eyes. Instead of forcing a rushed decision, the case moves into a controlled review step with notes, status tags, and clear handover records.
In practice, the queue supports remote onboarding teams that handle FICA customer due diligence and keep evidence tied to the session record. The review step can include document capture, facial comparison, liveness prompts, consent capture, and comments from the verification agent. It is a practical fit for banks, fintechs, insurers, lending teams, and any business that opens accounts online but still needs human oversight for exceptions.
- Exception routing for low-quality images, data mismatches, or incomplete session steps
- Human sign-off fields for approve, decline, refer, or request more information
- Review notes linked to the session record for audit use
- Status tracking that shows where a case sits in the queue
Queue sizes and workflow options that teams actually use
The queue can be set up as a single review stream or split into several lanes. Some clients prefer one general queue for all exceptions. Others want separate lanes for identity documents, face match issues, consent gaps, and escalations that involve higher-risk profiles. That structure helps larger operations keep work moving without mixing every problem into one pile.
Typical options include case priority flags, timeout markers, reason codes, and reviewer assignment rules. A small team may only need one review lane with a simple approve or reject outcome. A bigger operation may want staged review levels, where a first reviewer handles routine exceptions and a senior reviewer handles more sensitive cases. The queue can also be shaped around branch teams, call centre teams, or central compliance teams working across Johannesburg, Pretoria, Cape Town, Durban and Gqeberha.
- Single queue, split queue, or multi-level review path
- Reason codes for document, face, consent, or session issues
- Priority handling for urgent onboarding cases
- Reviewer notes and escalation routing for complex files
Where manual review helps most in South African onboarding
Manual review suits services that need controlled decisions before a customer account is opened, especially where identity evidence must be checked carefully and the record kept clean. It is useful for remote video sessions in Rosebank, Johannesburg and for national teams that serve customers across the country without bringing everyone into one office.
Common fit areas include banking onboarding, insurance applications, credit checks, mobile wallet openings, rental verifications and business account approvals. It also helps when a customer joins from a weaker network area, uses an older identity document, or presents a session that needs a closer look before approval. For teams in Sandton, Midrand or Pretoria, the queue reduces pressure on frontline staff because the odd case has a proper route instead of being left in a chat thread or on a manager's phone.
- Remote onboarding with exception handling built into the process
- Useful when image quality, name matching or face match needs review
- Supports controlled decision making for higher-risk applications
- Works for local and national customer bases
Fitting the queue into your existing systems
Integration work usually starts with workflow mapping, then moves to API coordination and field matching so the queue sits neatly inside the client's onboarding stack. If your team already uses a case management tool, CRM, or internal approval portal, the queue can be linked so reviewers see the right details without jumping between systems. That keeps the process practical for operations teams and reduces duplicated entry.
Implementation often includes status labels, reviewer permissions, audit notes, and escalation triggers. Client teams may also ask for pilot launch support so the queue is tested on live cases with a narrow group of reviewers before wider use. Where needed, staff training covers how to read exception reasons, how to handle a liveness miss, and how to record a clean decision trail. The setup is then adjusted with change request support or refresh training when the process changes.
- Workflow mapping for the full onboarding path
- API coordination for case status, notes and decision updates
- Staff training for reviewers, ops teams and supervisors
- Escalation design for sensitive or borderline cases
Care, review discipline and record keeping
The queue itself does not need physical maintenance, but the review process does need discipline. Teams should keep reason codes tidy, close old cases properly, and make sure notes match the decision that was taken. If the queue is being used for POPIA-aligned record keeping, session proof must remain tidy and access must stay limited to the people who need it for their work.
Good practice includes checking image clarity before sending a case for review, avoiding vague comments, and keeping escalation wording consistent across the team. Quality monitoring helps spot repeat errors such as poor document capture or missed liveness prompts. A short refresher session now and then keeps reviewers aligned when forms, scripts or approval rules change.
- Keep review notes brief, specific and traceable
- Close exceptions with a clear outcome code
- Use quality monitoring to spot repeat process faults
- Refresh training when scripts or rules shift
Details to pin down before the queue is switched on
Before a manual review queue is put into use, the client should confirm the decision levels, case labels, reviewer roles and what evidence must sit with each file. It also helps to agree the order of checks, whether one reviewer can finalise a case, and when a matter must move to a senior reviewer or compliance contact. Those rules matter more than the screen layout.
Other details include the document types accepted, the exception reasons that should trigger review, the fields needed for reporting, and how long review records must remain accessible in the system. If the queue is being added to a live onboarding flow, pilot launch support is useful for testing case handoffs, escalation design and report output before wider rollout. For teams operating across Johannesburg, Cape Town, Durban, Gqeberha and Pretoria, that planning keeps the process consistent across branches and central operations.
- Decision levels and reviewer permissions
- Exception reasons that must trigger manual review
- Report fields and audit note requirements
- Record retention and access control settings
Key facts
| Product type | Manual review queue for video identity exception handling |
|---|---|
| Core use | Routes cases needing extra human checks before approval |
| Review signals | Document quality, face comparison, liveness prompts, consent gaps |
| Workflow fit | Single queue or multi-level review path |
| Integration options | Workflow mapping, API coordination, status updates, reporting |
| Support services | Staff training, pilot launch support, escalation design, refresh training |
