Pilot Launch Support

What sits inside a pilot launch

A pilot is the working phase where your internal team and our verification team run live cases through a controlled flow. We look at the session invite, the handoff into the video call, the document capture sequence, face comparison checks and the way consent is recorded for audit use.

The aim is to expose friction before volumes rise. That may mean tightening the greeting script, changing the order of prompts, adjusting what the customer sees on screen or deciding where a manual review step should sit. We also check whether the process suits different branches, call centres or compliance teams that will later use the same route for customer due diligence.

• Guided session dry runs with real case handling
• Script review for document prompts and identity checks
• Liveness prompts and face match sequence testing
• Record capture checks for POPIA aware storage controls
• Escalation points for unclear documents or failed checks

How the pilot is structured

We start with a working map of the journey. That includes who invites the customer, who reviews the file, what the agent says, how the handoff to your staff works and where exceptions land when the document is blurred, expired or incomplete. From there, the pilot is run in stages rather than as one large launch.

First we confirm the journey against your operating rules. Then we test the live flow with your staff watching or joining the process. After that, we compare what was planned with what actually happened and mark the changes that matter. If you need, we also adapt the escalation design so a failed session does not stall the wider onboarding queue.

• Journey mapping and step order review
• Session testing with selected customer scenarios
• Exception review for mismatches and poor captures
• Escalation routing for support, review or retry cases
• Launch notes for internal sign off and next steps

Timing, volume and control points

Pilot timing depends on how many journeys you want to test, how many staff members need training and whether the process has to sit inside an existing onboarding system. A small pilot may only need a narrow set of test cases, while a broader launch can cover several departments, multiple sites and more than one workflow rule.

The pilot is also where practical timing issues show up. A script that looks neat on paper may slow an operator down. A document prompt can be too early, or a consent step can sit in the wrong place. We track those points carefully, because a few seconds in the wrong spot can create a queue at the back end. For businesses in Johannesburg, Pretoria, Cape Town, Durban and Gqeberha, we also make sure the setup suits teams working across regions and shifts.

The hands-on work before go live

Before a full release, we usually refine the language your agents use, check the sequence of verification prompts and test the reporting fields your staff will rely on. If your team needs a lighter or stricter review path, we help shape that too. The purpose is not to overcomplicate the launch, it is to reduce uncertainty when real customers start moving through the flow.

• Agent script design updates for clearer guidance
• Quality monitoring on sample sessions and outcomes
• API coordination where your system needs integration checks
• Staff training for supervisors, verifiers and support teams
• Operational reporting fields for pilot analysis

We can also help your internal team understand which cases need a second look and which can proceed without delay. That support matters when account opening is tied to downstream checks, because the pilot should reflect the way your business actually works, not a clean demo version.

Pricing approach and scope choices

Pricing for pilot launch support is normally shaped by scope rather than by a fixed one-size amount. The main inputs are the number of journeys to test, the amount of staff training required, whether API coordination is needed and how much reporting detail your team wants from the pilot period. If you want a narrow review of scripts and timing, that is a different brief from a multi-team rollout with escalation design and live issue handling.

We usually separate the work into planning, live pilot support and wrap-up adjustments. That helps your team see where the spend sits and which parts are linked to implementation rather than ongoing operations. It also makes it easier to compare a basic launch with a fuller rollout that includes refresh training or change request support later on.

Aftercare once the pilot is closed

Once the pilot finishes, the useful work is in the review notes. We capture what changed, where agents hesitated, which checks needed clearer wording and what should be revised before wider use. If your team wants a cleaner handover, we can also package the updated scripts, the agreed escalation path and the revised reporting view into a final working set.

Aftercare is practical. It may include refresh training for new staff, a change request review when your onboarding rules shift, or a follow-up on quality monitoring if the first live cases show repeated errors. The aim is to leave your team with a steadier process and fewer surprises once the service is carrying regular customer volumes.

Working from Rosebank with teams across the country

Our base is in Rosebank, Johannesburg, and we assist businesses across South Africa that need remote video identity verification for account opening and customer onboarding. That includes teams in Johannesburg, Pretoria, Cape Town, Durban, Gqeberha, Midrand and Sandton, where internal structures can vary even when the verification standard stays the same.

Some clients want a pilot that links closely to one operations team. Others need a broader setup that spans a few branches and support functions. We keep the work focused on the live process, the human handover and the record trail, so the pilot can stand up to day to day use rather than only looking good in a planning note.