DUTCH TRANSPORT CUSTOMER CARE PORTAL

Currently the search is static and relies on removing and reentering the data to find accounts. A live search will speed up the time to find the account of the caller and thus reduce waiting times.

On the phone with the customer, and with GDPR ruling, consent must be given to access the details of the caller.

Once consent is given, the tokens used to travel by the passenger are shown. The products on these tokens are shown to help identify the need of the caller. Once a token is selected, the functions on right are available to use. These represent the types of calls received by the customer care centres.

Each tab of the account represents different information, this tab is related to the tokens of the account. All tokens, even tokens that are inactive are still shown for queries related to blocking / replacements. Clicking any token will bring up the token details.

Here we can see a breakdown of the token. The details, products, and trips taken on this token are shown.

The functionality on the right is context-specific in terms of the token details we are viewing. Certain tokens cannot be replaced by the OVChipkaart providers e.g. a Mastercard.

Here we can see how the functionality changes depending on the token type.

An example of the blocked tokens. Old products and trips are still available to view but token functionality is no longer available.

Two versions here are shown, blacklisting a bank card, and blacklisting a travel card as a valid token for travel.
Context specific dialogue cues are given to the representative alongside specific functionality.

The reasoning behind this is that although we can blacklist an OVChipkaart and transfer the funds to the bank account of the caller, the bank card is a direct expense item. We can also replace a travel card but the caller’s bank must replace their card and block from future financial transactions. These dialogues are important to clarify as each token is unique and must be accounted for.

Protocol of the representatives for replacement of cards is to verify details of the caller to ensure the new card is delivered to the correct address.

New functionality here is to offer to transfer select products to the new card for the caller for ease of use. Unselected products are returned to the pouch

Sometimes a replacement card is not received by a caller in time. This is sometimes due to long weekends / wrong address / maintenance of system etc. This information on the process date / delivery date is useful information for the representative to know to inform the caller. Certain scenarios also speed up the sending process, replacement of lost cards have a 24 processing time whereas new cards have a 3-5 working day processing time.

When travelling, sometimes a passenger can exit a station that does not have hard-gating. These stations have a bollard to check out with and when travelling is second nature it can skip the mind of the passenger. The other common scenario is tapping the gate and passing true and the gate not registering the tap. These scenarios result in 20 euro being taken out of the card balance, so a common call type is to rectify a missing checkout.

Here we can check the token used and where it was checked in at. Then the available stations from there are shown. As the OV Chipkaart can be used on all transport, a transport to another method is also possible. This distinction is required to allow the payment of the transport operators who provide the separate services.

Another common call type is refunds, this could be due to mischarge of trip, missing checkout, automatic top up occurring multiple times.

The category and value of refund is needed for ticket keeping and processing, the added value of choosing the payment method on file to refund to is for the ease of the caller.

Student deal travel is dealt with an external party but is required to log for ticket and support metrics.

The use case was discovered that if a caller has bound a new token, they may wish to transfer a product to a more useful token for them. This screen pulls all the products on one token, and the available tokens bound to the caller that the product can be switched to.

Certain tokens have the ability to automatically top themselves up when they reach a certain limit.

Here the functionality is extended to allow the user to select the payment method which will top up the balance.

Here we see the payment methods used by the caller, certain ones are direct expense and others are based on a balance.
Selecting a paymentmethod will show the details.

Here we see the history of payments undergone by the payment method. Each payment is a collection of trips and these trips are shown once a payment is selected. The functionality is similar to the token functionality in that we can allow automatic top up, remove a payment or update the details.

Similar to how the consumer apps show the information, this tab allows the representative to see exactly what the caller can see on their phone. This allows a better understanding as currently this functionality is not available and requires the representative to rely on what the caller is telling them.
This screen also allows the representative to refund a select trip in case of double-charging or check-out problems.

Here we can see active products for the caller. We can see the tokens they are bound to and remove / transfer them.