GBG Developers

Guides   |   Example Customer Workflows and API Steps

Example Customer Workflows and API Steps

INTRODUCTION

Customer workflows can be broadly split up into data-first and document-first procedures (the concept of data-first and document-first is used just to visualize example customer workflows; your actual customer workflow and business processes can take any form).

If a customer is encountered in your business process either remotely (for example the customer reached the online presence for the business and entered their details there) or through interaction with staff in (say) your retail premises, then you may opt to just use the Verify People functionality first, if that is the appropriate way to begin working with the customer. In other scenarios (particularly at airports for instance) it may be expected for the customer to have usable documents on-hand, and use of the Verify Document functionality instead may make more sense.

Dealing with customers in retail is more involved than that of course, and your customer may choose to only provide partial information initially, or the data may be incorrect if it was captured over the phone. As a result, when you have multiple ways to handle customers, you may choose to use the Identity Solution API calls at different locations in your application code, so that the information checks are appropriate to handle the customer. For instance, you would not want to reject customers at the stage when they are considering your services during a phone-call, due to lack of information captured at that point. In another example, you may wish to improve the delivery process for your customers by capturing very specific address information, and your process may pass the customer to an agent if the address cannot be captured with accuracy.

The examples below cover a small sample of possible customer workflows. Some deal with text data handling first and others may rely on cameras and document scanners early on in the customer workflow handling process.


MAKING A RESERVATION

A typical scenario for a consumer may be to make an online reservation for car rental, or for a hotel room. If a browser-based application is used by the customer then you may choose to optionally allow the customer to enter in their name and address details manually and performing an initial data verification using the Verify People API call. If the customer requirements dictate that the process needs to be sped up and a reduction in accidental mistyping is needed, then the Address API call can be used to rapidly perform more accurate address completions.

If customers are encountering your service from mobile devices with cameras, the Document Verification API call could be used to capture their details from a driving license or other form of identification. The Web and Mobile SDKs are another option; they contain pre-built code that can present a dialogue and buttons on the display for the user to press to turn on the camera and capture the information with on-screen guides.

 

AUTOMATED KIOSK ENCOUNTER

Self-service technologies such as kiosks are becoming increasingly popular across many industries. In the airline industry the processing cost for an e-ticket printed at a kiosk is one tenth that of a paper ticket, and less than one-fiftieth if the user prints the boarding pass prior to reaching the airport. A modern customer workflow in a car rental branch or an equipment hire store could involve a touchscreen where Verify People and Address APIs could be used as before to provide fast and accurate address completion and verification, however the customer expectation may be to immediately provide documents at a branch location. Document cameras or scanners attached to the kiosk can be used and the Verify Document API call will allow the transfer of an image file. If the document scan is merely required for speeding up an initial interaction and a loose tolerance is required, this can be specified within the API call. A strict tolerance setting is suitable for more stringent checks, for regulatory purposes or for forming the final agreement. 

In certain industries a combined decision may be required for multiple documents from the customer, or for verifying typed data in conjunction with documentary evidence. The Verify Document API call can be executed multiple times, or it can be combined with a Verify People API call. The first API call will return a parameter known as the person identifier. That identifier can be passed to subsequent API calls for combined decision.

The benefit of using the person identifier and the combined decision is that it saves the application software from needing to have hard-coded logic on the number of documents to verify and how to manage the result scores from each API call. All of that complexity is removed from the application and the Identity Solution can instead automatically generate a combined easy-to-understand decision.


REFERRALS TO BRANCH STAFF

As part of the workflow, there could be a requirement to perform additional verification if document scanners are faulty or for other business or legal reasons.

If multiple documents need to be verified then the combined decision and triangulation results are used. These greatly simplify the tasks of corroborating information across multiple API calls and confirming that they all refer to the same person.

The combined object is examined for a PASS result, which will indicate that all previous API calls also passed. The result code within the triangulation object needs to be checked to confirm that the last two API calls referred to the same person. The code value indicates how much of a match there was.


The flow chart above shows an example scenario where a user can enter information at a kiosk or other device for initial verification or to speed up the workflow. If the business logic determines that additional verification is needed, branch staff may assist with using document scanners to obtain corroborating information. The application can examine the combined and triangulation results for any number of documents (as defined by the business logic) in order to successfully manage the customer. If there is a fail result at any stage, the application may request the customer to provide additional documents (this is a business determination).


SUBSEQUENT ENCOUNTERS WITH A CUSTOMER

If a person has already been verified and performed a particular transaction, and is now about to collect an item from a pick-up location or obtain access to an event, it may make sense to accelerate the verification procedure rather than have the customer present all their details a second time. GBG Face Match technology can be used for this.

  1. First Encounter
    In the example below the customer has been verified using photo identification on their first encounter with the business and the application saved two returned identifiers along with the customer name and address into a database.

 



Second Encounter
On a subsequent encounter with the system as shown above, the user can manually enter their name and address without the need to present their documents a second time. Alternatively the user could present a ticket to allow the application to extract the person identifier from the database. The application retrieves the stored identifiers and uses them within a Face Match API call along with an image taken from a camera.

Optionally, at unattended locations special Liveness checks can be made to ensure the customer is actually present instead of a static photograph being presented to the camera.

Once a face match has been made, the user is granted access to the item or service that they are expecting. If the face match fails, an agent could attend or the user could be requested to enter additional details manually.

SUMMARY

The ability to support diverse customer workflows allows businesses to accept customers in unique ways. All of the workflows are supported by the Identity Solution through sequencing API calls in any desired combination to suit the customer workflow and business logic.

Subsequent API calls are chained using the returned identifier from the first API call.

Through multiple calls, it is possible to verify customers to any level using text entry and scanned or photographed documents and live video images. The Identity solution provides an easy-to-use PASS, FAIL or REFER decision that immediately allows the business to support the customer in the appropriate manner.

If you wish to explore using the APIs in different combinations to support your customer needs, please refer to the associated github repository which contains Identity Solution Python scripts (the API calls can be executed using multiple programming languages; we used Python for the demo code for this guide). Each Python file in the repository performs a single verification and the files can be chained together to try out any customer workflow.