Map the onboarding journey before any build starts
Start with the full customer path, not just the video session. The team needs to know where the applicant enters, which fields are captured, who reviews the file, and what happens if the document image is unclear or the face match needs another look.
List each touchpoint in order. That usually includes pre-checks, consent capture, the live guided session, document images, face comparison, liveness checks, case notes, decisioning, and record storage. If the journey crosses more than one system, name the handover point and the owner at each step.
- Customer entry point and channel
- Required fields, files, and consent statements
- Review step for the agent or operations team
- Decision outcome and audit record location
- Escalation point for failed or incomplete cases
Set the data fields the workflow must carry
Video KYC integration works best when the data model is fixed early. Decide what must travel with each case, such as identity number, name, contact details, session reference, document type, review status, and the final outcome. Keep field names consistent across systems, because small naming changes create avoidable work later.
Think carefully about record keeping too. A clean file should show who captured the document, who reviewed the session, when consent was recorded, and where the supporting evidence sits. That supports POPIA handling and routine internal audit checks without making the process heavier than necessary.
- Core customer identifiers
- Session reference and timestamps
- Document capture fields
- Outcome status and reason codes
- Audit trail and retention location
Plan the API links and exception paths together
Technical integration is not only about the happy path. Your build should handle dropped sessions, incomplete document images, duplicate applications, and cases that need manual review. If those exceptions are not mapped early, operations end up creating workarounds that are hard to support later.
API coordination should cover authentication, payload structure, event updates, and error handling. Agree on what triggers a retry, what becomes a manual task, and which status marks a case as closed. The cleaner this is on paper, the less guesswork sits in the live process.
- Request and response fields
- Status updates between systems
- Error messages that staff can understand
- Retry rules for interrupted sessions
- Manual review route for exceptions
Write the agent script around actual session flow
A guided video session needs a script that feels steady and practical. The agent should explain each step in plain language, ask for the correct document, check that the face and document belong together, and keep the customer moving through the session without rushing key checks.
Script design should also cover consent, image quality, and what happens if a document is blurred or the applicant steps out of frame. A good script keeps the tone neutral and the instructions consistent, which makes staff training easier and improves the quality of each file.
Train the team on quality, not just system clicks
Training should cover both the tool and the judgement calls around it. Staff need to know how to spot a weak image, when to pause a file, how to note an anomaly, and when to hand a case into escalation. That is especially useful when there are multiple client teams working from the same process but with different internal rules.
Refresh training matters after launch too. New staff, changed scripts, updated fields, or a revised review flow can all shift the way the work is handled. Short, focused refresh sessions keep the process aligned without turning every change into a large project.
- Session handling and document checks
- Face comparison and liveness cues
- Quality thresholds for images and notes
- Escalation steps for uncertain cases
- Refresh training after process changes
Use pilot results to stabilise the live rollout
A pilot launch is where the process gets tested under normal pressure. Watch the case flow, review failure reasons, check whether handovers are clear, and note where users pause or repeat steps. This is also the time to confirm whether reporting gives the operations team enough detail to manage volume and exceptions.
After the pilot, settle the open items before wider rollout. That may mean adjusting the agent script, tightening the review checklist, or changing a status label that confused staff. Once the process is live, ongoing change request support and operational reporting keep the service steady without forcing the client team to start over.
- Pilot volume and case outcome review
- Common failure reasons
- Reporting gaps and status issues
- Escalation design adjustments
- Go live stabilising notes
