Lab+: Reverse engineering the future states

The vision of future states

The Lab+ research-backed visions of government service delivery show three future state models in which people benefit from government in a far more seamless and responsive way than they are able to now. See the "Lab+: Potential future states for government service delivery" blog post for details about these models:

  1. Conversational services
  2. Proactive delivery
  3. Help me plan

The visions are useful to us in that they allow the opportunity for everyone to step away from pre-conceived ideas of what would be required into the future, unconstrained by traditional barriers in order to plan towards a state which could allow outcomes like these.

The future state models allow us to work backwards and reverse-engineer the components and requirements of the vision. Below is a snapshot of our first attempt to identify the sorts of functionality that would be required to support the three future states, namely proactive service delivery, conversational service delivery and the self selecting guidance option. We purposefully have stayed away from specific technologies, but rather have explored some of the functionality required. This gives us a chance to then map tech to functions as a secondary step rather than jumping straight to solutions which may limit the possibilities.

Many thanks to Lee Dowsett for pulling together this report, and to the various people (technical, analytics, designers, data) who contributed their ideas from across our team as a first go at quite a tricky conceptual exercise.

Please add other ideas into the comments below. We will likely do some form of open workshop on this in the near future to explore, prototype and build some demonstrators of what would be required to support the future states. The whole experiment has strongly supported the notion of "government as a platform", which has been encouraging.

Image is a cluster of key words from this blog post like: information, customer, ability, people and provide.
A word cloud formed using key words from this blog post.

Required functionality

Our first draft of required functionality is:

  • Openly, programmatically accessible, and reusable information about:
    • All government services, both those that are directly provided from or funded by government
    • Versioned, dated eligibility rules for those services:
      • Eligibility needs to be quite sophisticated around conditions and attributes about people
      • Communication on change to the users
      • Terms and conditions
    • Rules around evidence requirements and where that evidence can be found
    • Whether someone meets an evidence check, without transmitting the evidence (verifiable claims)
    • Appropriate trust environment to allow trustworthy parties to share or validate personal information in a seamless way and to prevent untrusted parties from doing the same
  • Openly, programmatically accessible, transactional services in order for government back-ends to take requests to provide service to individuals and businesses

Culture change

  • The cultural conditions to match security requirements to different situations; watertight security requirements aren't needed for all situations (for instance, for unclassified information). Just because it’s digital doesn't mean it must be behind walls, or behind more closed walls than is in the non-digital space.
    • The ability to catch wrongdoing in other ways ie audit, throttling, abuse pattern matching, etc

Legal and technical

  • Legal and technical ability to use information about people to proactively push relevant information services to those that want that
    • Ways to know how – and the means to – contact people via their chosen method, eg their email address and maintenance of that information
    • The technical (and legal) ability to ‘watch’ for events, changes in circumstances, age thresholds, etc and react accordingly to provide proactive service or start the conversation on providing newly eligible service
    • The ability to record and use the creation and cessation of relationships between people ie marriage, death in proactive or reactive service delivery in areas which are administered separately at present
    • Customer control over what intermediaries may do on their behalf. This need not be always an explicit technical exercise, leg, rules and agreements as well as implicit consent are a factor.
    • Push channels must know about changes quickly enough
  • Legal and technical ability to join up to other areas of life and commercial systems like transport payments

User consent, security and privacy

  • Some form of user consent/user control framework including delegations for authorising verification or sharing of information for a nominated purpose
  • Lightweight or no-weight security principles for moving around between technical silos that still maintain things like session integrity experience
  • Some form of profile functionality, irrelevant of whether that is centralised or distributed, but ideally under the control of the user:
    • An immutable record of interactions with government for use by the person
    • Ability to store information or flags derived from it
    • Ability to verify that information and record the verification
    • Ability for users to find out about and amend their information - a path
    • And for people to amend records on their behalf (agency, council, tax agent)
    • Core establishment of natural identity and the digital expression of that in a unique way
    • Core establishment of entity and machine identity and Connection of that to natural identity
    • Frameworks or principles to guide when that identity should need to be used - minimum viable identity, step-up identity, ‘trusted self’
    • Frameworks or principles designed for the digital world around appropriate consent, authorisation, permission
  • The ability to ask questions/ for authorisation from customers and record/act on the result

Supporting people

  • Multifaceted, all agency customer service capability to resolve issues and amend data about customers
    • Multi-agency truly customer centric chat functionality
    • The ability to share information between agencies/3rd parties around a service conversation including appropriate context and history including linkable identity in some contexts, perhaps temporarily for specific user authorised transactions
    • The ability to get customer consent to involve other parties and to provide a pathway if the answer is no
    • The ability to give trustable archives of conversations to customers
    • A variety of experiences to provide to different needs
    • An appropriate level of personal information to provide warm customer service without being creepy
    • Skills-based routing and a shared culture of customer service
    • Save state for long-running conversation with breaks to look for evidence etc
    • The ability to supply more evidence to government securely and verifiably when it is needed
    • Possibly some form of machine learning to update and improve customer journeys based on feedback, common pathways, analytics and metadata.
  • Genuine customer understanding and engagement in order to get true consent
  • Participation of third parties in order to reach a greater portion of New Zealand if not all - incentives and low or no barriers
    • Just enough identity could come from third-party customer information
  • The ability for customers to provide evidence of data about them being incorrect, and the ability to appropriately verify that evidence

Shifting the public sector view

  • Cultural shifts in government around:
    • how we perceive and manage risk - move from ‘don't get the agency on the front page’ to ‘ship good stuff quickly’
    • network-based security
    • how we finance change.

What next?

There are also some ideas around making content available as an API. Our assessment is that there is “content” like the description of a service which might be best served up from a database of services, but contextual content specific to a service channel is likely to also include highly specific content to that channel which may not provide a significant benefit in being made programmatically available. Similarly there may be other functions that don’t provide major benefits in componentising, but more experimentation is required to explore where this line can be drawn.

Another unclear but inferred requirement would be an evidence base of service analytics, ideally anonymised, to understand the user journeys across agencies, across services, and to understand the all of government picture of services so that when services change, we can see the impact across the system. Such an evidence base could also inform non-digital service delivery, some form of personalisation services, and ongoing machine learning of user pathway mapping. Potentially. smiley face


Lab+ is housed in the Service Innovation Lab, which is an experiment carried out under the leadership of the ICT Partnership Framework’s Service Innovation Group. It's managed by the Service Innovation Team in Department of Internal Affairs in partnership with Assurity Consulting.

Check out earlier blog posts about Lab+ and the Service Innovation Lab.

Follow us on Twitter at @NZLifeEvents.

Comments are closed.

Navigate Posts