Service NSW omni-channel reference architecture (OCRA) delivers customer services uniformly across multiple delivery channels. OCRA enables the customer to switch channels seamlessly without the need to restart the service.
Service NSW offers customer services on behalf of multiple downstream agencies. When offering services, it is critical to offer equivalent capability across all delivery channels, where:
- each downstream agency offers a different set of services at different levels of maturity and capability
- each customer may interact with Service NSW across multiple channels, for example face to face, over the phone, mobile, digital.
For Service NSW to provide equivalent capability across all agency services, it must supplement the capability of the downstream agencies.
The overall aim of the architecture pattern is to deliver omni-channel capability. That is where capability delivered for one agency in one channel, can be provided to all agencies across all channels, without the need for major refactoring or rework.
What does the architecture pattern enable?
- multi and omni-channel service delivery experience
- overarching security
- standardisation of services
- componentised transactions
- scalability and performance
- value added Service NSW capability.
Who should use this?
Project owners who need to implement customer services or transactions.
Characteristics of projects suitable for this pattern:
- Customer centricity - ability to deliver customer capability equally through one or more channels
- Independence of user experience - ability to deliver UX in any technology, quickly and consistently
- Enables encapsulation of business logic - centrally located business logic used by all delivery channels
- Scalability and portability of solution - ability to deploy and scale the solution in a variety of environments (Amazon Web Services/Pivotal Cloud Foundry)
- Technology independence - ability to build and deploy in a variety of technology platforms to meet the market
- Low cost - low cost of licensing and low cost of delivery
- Security of data - data integrity and security of overall solution
How do you use this pattern?
An agency may implement all or some aspects of this architectural pattern within their respective application ecosystems. However, integration with the Service NSW implementation as an agency service is the highest value scenario. Contact the Digital and Middle Office, Service NSW, (see support tab) to find out how this architecture can support the delivery of your project.
A transaction progresses across these layers, where agencies own the fulfillment transaction.
Multi-channel delivery allows a single transaction across multiple channels but does not cater for channel switching. This occurs in the omni-channel experience.
Omni-channel delivery allows the customer to switch channels part way through a transaction. To achieve this the transaction saves (and later reloads) part way through a transaction. This allows the customer to save a state in one channel and reload the state in another.
As the omni-channel experience is desired across all transaction capability, the save/restore function is a prime candidate for a value added service. This component will allow any transaction to save its state and reload it at a future time.
The channel experience layer consists of independent channel specific components that deliver a channel specific user experience for the customer to interact with. Any transaction will have at least one channel experience component to allow the customer to interact via at least one channel. Most transactions will have multiple channel experience components, to allow the customer to interact with the transaction via multiple channels.
The channel experience is supported by a digital asset management platform that allows the clear separation of form from function.
The transaction logic consists of a single component that provides a limited set of APIs to interact with it. It orchestrates the interaction with the downstream agency and any value-added services (VAS).
The transaction logic is stateless, with no internal persistence of data - except for VAS.
Good design practice will necessitate that the transaction logic is independent of the user experience and has no practical knowledge of which user experience is calling it. This ensures that any transaction logic is channel agnostic, and so can be exposed through multiple channels as needed.
The impact of the channel agnostic design is that where Service NSW needs to enforce a business rule (such as ‘minimum age’), this rule is implemented in the transaction logic so that it can be applied equally across all channels.
- provides abstracted common capability to any internal transaction logic component
- is accessed via an abstraction layer
- provides an atomic level of functionality (single targeted capability)
- has no knowledge of which transaction component is calling them (outside of passed data)
- may internally implement capability such as persistence, or external system integration to assist in completing its function.
The intent is for the number of VAS to grow over time. This is so that when implementing transaction logic, if a capability is required that can be used across transactions, then this capability can be developed independently as a VAS.
The following VAS have been identified.
- transaction logging
- metrics logging
- receipt generation
- case management – integrated with salesforce
- customer management – integrated customer management with salesforce and others
- payment management – integrated with payment services platform
- JWT management
- transaction configuration
- proof of identity
- error mapping – error mapping of agency and system errors to user errors
- save / resume – support pause and resume a transaction across channels
- service management
- encryption / decryption.
- file writing
- file reading
- image store
- document store.
Future target capability
- signature store.
There are three abstractions layers that provide standard interaction between the various components that make up a transaction. They are secured using the relevant security protocols and placed in the appropriate DMZ. The layers are:
- transaction API, supporting channel delivery
- value added service (VAS) API, enhancing overall transaction, orchestrated by transaction logic
- agency API, standardising interaction between Service NSW and downstream agency services.
By leveraging the abstraction layers, and enforcing access control, the transaction logic and value-added components now reside within a secure environment.
The API abstraction layers govern access from external customers or the public, using a B2C security approach. The transaction API abstraction layer enforces all access control security (authentication and authorisation).
Access from downstream agencies is governed by the agency API abstraction layer using a B2B security approach (certificates).
Companion Animal Registry Program
The Companion Animal Registry (CAR) Program introduces a process to help customers register their pets with a local council.
The solution is based around the Service NSW omni-channel architecture. A customer registers with Service NSW (My Service NSW Account) with a low level of proof of identity. On micro chipping a new pet, they register it through the Service NSW portal by paying a one-time fee.
The transaction can be completed digitally or over the counter. On completion the customer gets a certificate showing proof of registration.
Service NSW has been asked to produce a digital application process, where customers can apply for vetting and certification by the Office of Children’s Guardian (OCG).
The digital-first approach allows a customer to initiate the transaction online using a browser. They then go to a Service NSW service centre to complete a proof of identity check and pay for the application.
The customer must complete a document verification service check, and provide several forms of identification, have a photo taken, and make a payment (if a paid worker) prior to submission.
The result of the application is that the customer’s details are sent to OCG for vetting and clearance. The application is only required for those customers engaged in the NDIS process.
International Drivers Permit
The International Drivers Permit introduces a process to customers which allows them to purchase a permit over the counter, or via a Service NSW kiosk.
Customers travelling overseas require this permit to allow them to drive in foreign countries. Often customers leave obtaining the permit to the last minute. Service NSW offers the ability to purchase the permit on the spot, over the counter.
The permit is in the form of a pre-printed card. The customer must provide a passport size photo. The photo is attached to the card and stamped. On payment the customer and card details are sent to the NRMA for fulfillment.
One Click Energy Switch Program
The One Click Energy Switch Program allows customers to compare energy prices and reduce energy costs, based on their current bill.
The customer uploads their bill and, through the use of a comparison engine, is presented with alternate providers (at a lower cost).
The program is based on the omni-channel architecture.
Energy Rebate Program
The Service NSW Energy Rebate Program allows customers to submit applications for an energy rebate. The rebate is funded by the Department of Planning, Industry and Environment (partner agency).
It allows Service NSW to manage and approve the customer application, with information relating to the program being made available to the partner agency. The solution also enables the payment of the rebate back to the customer.
Custodian agency and contact
Customer service delivery framework
Omni-channel reference architecture
Digital and middle office
Department of Customer Service
email: [email protected]
Service NSW can provide guidance on adoption of the omni-channel reference architecture, including demonstration of current implementations.