Patent Publication Number: US-2019196682-A1

Title: Customer service systems and portals

Description:
TECHNICAL FIELD 
     The disclosure relates to computer-implemented customer service systems, methods, portals and user interfaces. In particular, the disclosure relates to computer-implemented customer self-service systems, methods, portals and user interfaces, which may be used for utilities, such as electricity, gas and water, and taxation agencies, for example. 
     BACKGROUND 
     In utility industries, customer self-service portals may be provided by utility retailers to allow payment of bills and management of users&#39; utility accounts. Many of the portal systems on the market are point solutions specific to a utility retailer and are built around the utility retailer&#39;s backend systems. This often creates a risk of unauthorised external access to the backend systems and databases. 
     In the tax industry, customer self-service portals may be provided to allow businesses and individual tax payers to manage their tax. This may include, for example, government tax registration, enquiries and payments. These portals may create a risk of unauthorised external access to the government backend systems and databases. 
     Many of the portals on the market have a bill payment page from which details can be entered and a bill can be paid. However, it is often difficult or unintuitive for a user to find the bill payment page and complete a payment. 
     There is a desire to provide computer-implemented customer self-service systems, methods, portals and/or user interfaces that address or ameliorate problems or shortcomings associated with previous portals and/or to at least provide a useful alternative thereto. 
     SUMMARY 
     Some embodiments of the disclosure provide a deployable customer self-service (CSS) system comprising: 
     a user interface; 
     a web portal configured to load and display the user interface; 
     a service configured to provide data to the user interface based on a system of record or third party service; and 
     an integration connector for connecting the service to the system of record or third party service such that the service is agnostic to the format of the system of record or third party service. 
     The deployable CSS system may comprise a plurality of user interfaces, and the web portal may be configured to selectively load and display the user interfaces. 
     The deployable CSS system may comprise a plurality of services, and the services may be selectively loaded to provide data to a selected user interface based on the system of record or third party service. 
     The deployable CSS system may comprise one or more base web portals, base user interfaces and/or base services. 
     The deployable CSS system may comprise one or more web portals, user interfaces and/or services that extend the base web portals, base user interfaces and/or base services for the deployment. 
     The deployable CSS system may comprise one or more closed modules comprising one or more web portals, user interfaces and/or services that extend the base web portals, base user interfaces and/or base services for the deployment. 
     The deployable CSS system may comprise a plurality of integration connectors that convert one or more formats used by the system of record or third party service to a standard format used by the service(s). 
     The integration connectors may communicate with the services via a standard protocol and/or in a standard format. 
     The integration connectors may comprise one or more drivers selectable based on the system of record or third party service to interface between the services and the system of record or third party service. 
     The deployable CSS system may comprise a plurality of portals, such as an end user portal to be accessed by an end user and a system administration portal to be accessed by a company. 
     The user interface(s), the web portal(s), the service(s) and the integration connector(s) may be closed modules that are not editable upon deployment. 
     The services may include a caching service that controls retrieval of data from the system of record or third party service and a database to store cached data. 
     The caching service may include configuration rules defining caching priorities for one or more categories of data. For example, the configuration rules may be specified in a configuration table. 
     The one or more categories of data may include a first category of data that is required in real time, a second category of data that is required as soon as possible, and a third category of data that is cached periodically. 
     The caching service may be configured to retrieve data in the first category of data for the user interface or service from the system of record or third party service. 
     The caching service may be configured to retrieve data in the second or third category of data for the user interface or service from the database. 
     The deployable CSS system may invalidate one or more categories of data. The caching service may be configured to retrieve data in an invalidated category of data for the user interface or service from the system of record or third party service. 
     Some embodiments of the disclosure provide a deployed CSS system comprising: 
     a user interface; 
     a web portal configured to load and display the user interface; 
     a service configured to provide data to the user interface based on a system of record or third party service; 
     an integration connector selected based on the system of record or third party service to interface between the service and the system of record or third party service such that the service is agnostic to the format of the system of record or third party service. 
     The user interface, the web portal, the service and the integration connector may be closed modules that are not editable. 
     Some embodiments of the disclosure provide a computer-implemented method for deploying a deployable CSS system, the deployable CSS system comprising: 
     a user interface; 
     a web portal configured to load and display the user interface; 
     a service configured to provide data to the user interface based on a system of record or third party service; and 
     one or more integration connectors for connecting the service to specific types of system of record or third party service such that the service is agnostic to the format of the system of record or third party service; the method comprising: 
     receiving, from a computing device, specifications of the system of record or third party service; 
     selecting an integration connector specific to the system of record or third party service to interface between the system of record or third party service and the service; and 
     deploying the deployable CSS system with the selected integration connector to a data centre. 
     The computer-implemented method may comprise selecting one or more industry specific closed modules to be deployed as part of the CSS system, where the industry specific closed modules comprise one or more user interfaces, web portals and/or services. 
     The one or more industry specific modules may be selected based on an identifier of an industry received from the computing device. 
     Some embodiments of the disclosure provide a deployable customer self-service (CSS) system comprising a user interface, a service, and an integration connector for connecting the service to a system of record such that the service is agnostic to the format of the system of record, wherein the service is configured to: 
     receive usage data associated with sites in an area from the system of record via the integration connector; 
     determine a usage for a specified site based on the usage data; 
     determine an average usage for the sites in the area based on the usage data; and 
     display, in the user interface, a site usage identifier identifying the usage for the specified site and an average area usage identifier identifying the average usage for the sites in the area. 
     The site usage identifier and the average area usage identifier may be coloured according to a level of usage. 
     The usage for the specified site and the average usage for the sites in the area may be determined according to a billing period of a user at the specified site. 
     The user interface may comprise a map and a location identifier that identifies a location of the specified site on the map. The location identifier may be coloured according to a level of usage for the specified site. 
     Some embodiments of the disclosure provide a method comprising: 
     receiving, via a communications network from a computing device, a request to access a CSS portal; 
     transmitting, via the communications network to the computing device, a user interface to display on the first computing device, the user interface comprising a payment button located at a fixed location at a right side of the user interface; 
     receiving, via the communications network from the computing device, a request based on an actuation of the payment button; and 
     transmitting, via the communications network to the computing device, a second user interface to facilitate making a payment. 
     The method may comprise receiving, via the communications network from the computing device, a request to view a second user interface; and 
     transmitting, via the communications network to the computing device, the second user interface to display on the first computing device, the second user interface comprising the payment button located at the fixed location at the right side of the second user interface. 
     The fixed location may be a fixed location in a window or a fixed location on the screen. The payment button may stay located at the fixed location in the window or on the screen when scrolling. The payment button may form part of a payment division that stays located at the fixed location. The division may display a payment amount with the payment button. 
     The term “system of record” as used herein refers to an information storage system that is an authoritative data source for a given data element or piece of information. 
     The term “button” as used herein may refer to any element of a graphical user interface which a user can select, for example, via a mouse or touchscreen, to perform a particular action. 
    
    
     
       BRIEF DESCRIPTION OF DRAWINGS 
         FIG. 1  illustrates a deployable CSS system. 
         FIG. 2  illustrates a computer-implemented method for deploying the deployable CSS system. 
         FIG. 3  illustrates an overview of a deployed CSS system. 
         FIG. 3 a    illustrates an overview of a deployed CSS system including a base and one or more modules. 
         FIG. 4  illustrates a first example deployed CSS system that has been deployed in a cloud data centre and interacts with a utility data centre. 
         FIG. 4 a    illustrates a second example deployed CSS system that has been deployed in a cloud data centre and interacts with a tax agency&#39;s data centre. 
         FIG. 5  illustrates a third example deployed CSS system for a utility application. 
         FIG. 6  illustrates a fourth example deployed CSS system that has been deployed in a cloud data centre for a utility application. 
         FIG. 6 a    illustrates a fifth example deployed CSS system that has been deployed in a cloud data centre for a utility application. 
         FIG. 6 b    illustrates a sixth example deployed CSS system that has been deployed in a cloud data centre for a tax application. 
         FIG. 7  illustrates a seventh example of a deployed CSS system that has been deployed in a utility data centre. 
         FIG. 8  illustrates a cache management system for managing data retrieval from system(s) of record. 
         FIG. 9  illustrates a method for providing a payment interface. 
         FIG. 10  illustrates an end user portal including a payment button for a utility related application 
         FIG. 11  illustrates another end user portal including a payment button for a utility related application. 
         FIG. 12  illustrates an end user portal including a lodgement button for a tax related application 
         FIG. 13  illustrates example flow charts showing functions that may be performed in the deployed CSS system. 
         FIG. 14  illustrates example flow charts showing functions that may be performed in a deployed CSS system for a utility related application. 
         FIG. 15  illustrates example flow charts showing functions that may be performed in a deployed CSS system for a tax related application. 
         FIG. 15 a    illustrates example flow charts showing further functions that may be performed in a deployed CSS system for a tax related application. 
         FIG. 16  illustrates a location based analytics user interface for a utility related application. 
         FIG. 17  illustrates example components of a deployed CSS system that are used for location based analytics. 
     
    
    
     DESCRIPTION OF EMBODIMENTS 
     Embodiments of customer self-service (CSS) system described herein may connect to a company backend system, for example, to allow a customer to perform actions and view data in relation to the company. In one example, the CSS system may connect to a utility company backend system, for example, to allow a customer to perform actions and view data in relation to utilities provided by the utility company. In one example, the CSS system may connect to a government backend system, for example, to allow a customer to perform actions and view data in relation to tax provided by a taxation agency. The CSS system may be agnostic of the company backend system to which it connects allowing the CSS system to be deployed to connect with a range of different backend systems. This may be achieved, for example, by providing a closed system and by selecting specific drivers to integrate the closed system with specific backend systems and/or providing a plugin framework that may connect the closed system with various backend systems, such as a customer information system (CIS), a meter data management system (MDMS) and a network management system (NMS) for utility related applications, or a public service revenue management system (PSRM) for tax related applications. 
       FIG. 1  illustrates a deployable CSS system  100 . The deployable CSS system  100  comprises one or more web portals  110 , one or more user interfaces  120 , one or more services  130  and one or more integration connectors  140 . 
     The one or more web portals  110  are configured to load and display the one or more user interfaces  120 . The one or more services  130  are configured to provide data to the one or more user interfaces  120  based on one or more systems of record and/or third party services. The one or more integration connectors  140  are for connecting the services to the one or more systems of record and/or third party services. The one or more services  130  are agnostic to the formats of the one or more systems of record and/or third party services. 
     Each web portal  110  may be configured to selectively load and display the one or more user interfaces  120 , for example, based on the actions of a user. The one or more services  130  may be selectively loaded to provide data to a selected user interface  120  based on the system of record or third party service. The integration connectors  140  may communicate with the one or more services  130  via a standard protocol and/or in a standard format. 
     The integration connectors  140  may comprise a plurality of drivers or plugins. During deployment, one or more drivers may be selected based on the system of record or third party service to interface between one or more of the services  130  and the system of record or third party service. For example, the one or more drivers may be selected to convert from a protocol and/or format used by the system of record or third party service to the standard protocol and/or the standard format of the services  130 . 
     The one or more web portals  110  may include an end user portal to be accessed by an end user, a utility administration portal to be accessed by a utility company, and/or a user administration portal to be accessed by a system administrator. 
     The user interface(s), the web portal(s), the service(s) and the integration connector(s) may be closed modules that are not editable upon deployment. This may prevent unauthorised access to the system(s) of record and/or the third service(s) via the one or more web portals  110  by isolating the system of record(s) and/or the third party service(s) from the web portal(s)  110 . 
       FIG. 2  illustrates a computer-implemented method  200  for deploying the deployable CSS system  100 . At  210 , the method  200  comprises receiving, from a computing device, specifications of the system of record or third party service. The specifications may include, for example, an application program interface (API) used to maintain or access the system of record or the third service, a protocol (e.g. Simple Object Access Protocol (SOAP) over Hypertext Transfer Protocol Secure (HTTPS)) used to access the system of record or third party service, or a format of the system of record or third party service. 
     At  220 , the method  200  comprises selecting an integration connector specific to the system of record or third party service to interface between the system of record or third party service and the services. For example, a server may store associations between specifications for systems of record or third party services and drivers, and may select the driver specific to the system of record or third party service based on the stored associations. 
     At  230 , the method  200  comprises deploying the deployable CSS system with the integration connector to a data centre. The data centre may be a data centre that is also used to store the system of record or may be a separate data centre such as a cloud data centre. 
     For example, in a deployment such as a utilities related deployment, the integration connectors may connect the services to Meter Data Management Systems (MDMS), such as EnergyIP™ and Itron™, Retail Billing Systems, such as Gentrack Velocity™, SAP and Oracle™ Customer Care and Billing (CC&amp;B), Ticketing and Case Management Systems, such as Zendesk™, and/or Content Management Systems (CMS), such as Sharepoint™ and Sitecore™. 
     The deployable CSS system may be deployed using OutSystems rapid application development platform utilising ASP.NET and Oracle database technologies. During deployment, a utility company may be able to select between two platform as a service (PaaS) implementation options: onsite deployment using the utility provider&#39;s infrastructure; or hosted deployment using a cloud environment. 
     The OutSystems platform contains a rich set of industry standard adaptor technologies that facilitate seamless integration of many other application interfaces. The selectable integration connectors may include drivers that allow the deployable CSS to connect to various mission critical applications such as Oracle CC&amp;B, SAP and Gentrack. 
     Using an OutSystems Cloud Platform, instances of the deployable CSS may be created that have the same code base. These instances may run seamlessly on a range of devices and form factors, such as desktop computers, notebooks, tablets, and mobile phones. That is, the instances may be deployed to run natively and display user interfaces correctly on such devices and form factors. The instance may also be accessible via a range of browsers such as Google Chrome™ 23 or newer, Internet Explorer 9 or newer, Mozilla Firefox 17 or newer and Safari 6 or newer. 
     In some embodiments, the integration connectors include pre-built connectors that can be leveraged to integrate with enterprise backend systems, such as those provided by Oracle CC&amp;B. 
       FIG. 3  illustrates an overview of a deployed CSS system  300  comprising an instance of the deployable CSS  100  which comprises the web portal(s)  110 , the user interface(s)  120 , the service(s)  130  and the integration connector(s)  140 . The integration connector(s)  140  comprise one or more drivers  350  selected based on the system of record  360  to interface between the service(s)  130  and the system of record  360 . The integration connector(s)  140  may also comprise one or more plugins  340  selected to customise the functionality of the deployed CSS  300 . The driver(s)  350  and/or plugin(s)  340  may be selected to customise the system  300 , for example, per installation, business or region. 
     The deployable CSS  100  may be deployed as closed code that is not editable. For example, the web portal(s)  110 , the user interface(s)  120  and the service(s)  130  may be closed modules that are not editable. The driver(s)  350  and/or plugin(s)  340  may also be closed modules that are selectable during deployment to customise the deployed CSS  300 , but are not editable. 
       FIG. 3 a    illustrates an overview of a deployed CSS system  302  comprising an instance of a deployable CSS base  102 , an instance of one or more deployable CSS modules  104 , and one or more integration connectors  140 . The deployable CSS base  102  comprises web portal(s)  110 , user interface(s)  120  and/or service(s)  130 , which constitute a base set of components for the deployable CSS  100 . The deployable CSS module(s)  104  comprises web portal(s)  110 , user interface(s)  120  and/or service(s)  130 , which constitute a custom selection of components specific to the application for which the CSS system  302  is deployed. The integration connector(s)  140  comprise one or more drivers  350  selected based on the system of record  360  to interface between the service(s)  130 , of the deployable CSS base  102  and the deployable CSS module(s), and the system of record  360 . The integration connector(s)  140  may also comprise one or more plugins  340  selected to customise the functionality of the deployed CSS  302 . The deployable CSS module(s), driver(s)  350  and/or plugin(s)  340  may be selected to customise the system  302 , for example, per installation, business or region. 
     The deployable CSS  102  and/or the deployable CSS module(s)  104  may be deployed as closed code that is not editable. For example, the web portal(s)  110 , the user interface(s)  120  and the service(s)  130 , of the deployable CSS base  102  and the deployable CSS module(s)  104 , may be closed modules that are not editable. The deployable CSS module(s)  104 , driver(s)  350  and/or plugin(s) may also be closed modules that are selectable during deployment to customise the deployed CSS  302 , but are not editable. 
       FIG. 4  illustrates a first example deployed CSS system  400  that has been deployed in a cloud data centre  402 , such as an Amazon Web Services (AWS) data centre. The portals  110  can be accessed from the cloud data centre via the Internet to display the user interfaces  120  on a computing device. The services  130  associated with the user interfaces  120  request data via the integration connectors  140 . 
     The integration connectors  140  comprise a customer care and billing (CC&amp;B) driver  410 , a meter data and management service (MDMS) driver  420 , and a network management system (NMS) driver  430 . The integration connectors  140  send requests  440  to a utility data centre  404 . The utility data centre comprises a demilitarised zone (DMZ)  450  including an hypertext transfer protocol (HTTP) server or reverse proxy  452 . The DMZ may be used to isolate service(s) that are provided to external networks from the utility&#39;s corporate network. The HTTP server issues requests to web service definition language (WSDL) endpoints in the utility&#39;s corporate network  460 . The WSDL endpoints include an NMS API  462  to retrieve data from an NMS  472 , a CC&amp;B API  464  to retrieve data from a CC&amp;B system  474 , and an MDMS API  466  to retrieve data from an MDMS  476 . 
     For example, the utility data centre  404  may be an Oracle based system comprising an Oracle HTTP server (OHS), an Oracle NMS API  462  to retrieve data from an Oracle NMS  472 , an Oracle CC&amp;B API  464  to retrieve data from an Oracle CC&amp;B system  474 , and an Oracle MDMS API  466  to retrieve data from an Oracle MDMS  476 . The integration connectors  140  may then comprise an Oracle CC&amp;B driver  410 , an Oracle MDMS driver  420  and an Oracle NMS driver  430 . 
       FIG. 4 a    illustrates second example deployed CSS system  401 , wherein the integration connector(s)  140  comprise a public service revenue management system (PSRM) driver  435 . The integration connector(s)  140  send requests  440  to a tax agency&#39;s data centre  405 . The tax agency&#39;s data centre  405  comprises a demilitarised zone (DMZ)  451  including an hypertext transfer protocol (HTTP) server or reverse proxy  452 . The HTTP server  452  issues requests to web service definition language (WSDL) endpoints in the tax agency&#39;s corporate network  461 . The WSDL endpoints include a PSRM API  477  to retrieve data from a PSRM  478 . 
     For example, the tax agency&#39;s data centre  405  may include an Oracle based system comprising an Oracle HTTP server (OHS) and an Oracle PSRM API  477  to retrieve data from an Oracle PSRM  488 . The integration connectors  140  may then comprise an Oracle PSRM driver  435 . 
       FIG. 5  illustrates a third example deployed CSS system  500  for a utility related application. The deployed CSS system  500  comprises web portals  110 , user interfaces  120 , services  130  and integration connectors  140  which include drivers  560 . The web portals  110  comprise an end user portal  514  and a utility administration portal  512 . The user interfaces  120  comprise an account management user interface  521 , a bill payment user interface  522 , a stop/transfer user interface  523 , a billing and consumption user interface  524 , a faults and enquiries user interface  525 , a translation management user interface  526  and a plugin management user interface  527 . The user interfaces  120  may also comprise a mobile app  528  which can be downloaded to a mobile computing device to interact with the deployed CSS system  500 . The user interfaces  120  may be loaded selectively into the portals  110 . 
     The services  130  comprise an account management service  531 , a bill payment service  532 , a stop/transfer request service  533 , a billing and consumption service  534 , a faults and enquiries service  535 , a translation service  536 , a plugin service  537 , a weather service  538 , a geographic information system (GIS) service  539 , an address service  540 , a mail service  541 , a payment service  542 , a portal user service  543  and an administrator user service  544 . The account management service  531  manages end user registration, user security, user profile maintenance, account linkages, and utility administration user management. The bill payment service  532  manages aspects of bill payments including once off payments, regular auto payments and bill smoothing. The stop/transfer request service  533  manages requests from end users to either stop a service associated with their address or transfer one or more services to a new service address. The billing and consumption service  534  provides billing and consumption information to the billing and consumption user interface  524 . The faults and enquiries service  535  enables end users to log faults/enquiries or outage requests with the utilities provider. The translation service  536  manages translation of data into different languages for the user interfaces  120 . 
     The weather service  538  retrieves historical weather information from one or more weather providers which may then be utilised by the end user portal  514  for various capabilities, such as providing weather overlays on usage or billing history graphs in the billing and consumption user interface  524 . The GIS service  539  retrieves geospatial information from one or more GIS providers which may then be utilised by the end user portal  514  for various capabilities, such as displaying locations of outages on a map in the faults and enquiries user interface  525 . The address service  540  retrieves and validate addresses from one or more address verification providers which may then be utilised by the end user portal  514  for various capabilities, such as auto completion and validation of address for transfer of services via the stop/transfer user interface. The mail service  541  compiles email messages based on workflow actions within the deployed CSS system  500 , and sends email notifications to respective end users. The payment service  542  manages interactions with third party payment gateways  581 , for example, to execute bill payments. The portal user service  543  manages users for the end user portal  514 , such as during registration with the portal and login to the portal. The administrator user service  544  manages users for the utility administration portal  514   
     The plugin service  537  manages plugins  570  that can be selected specific to the deployment to extend the CSS system  500 . A plugin template  545  is provided which may specify a required format or syntax for the plugins. The plugins  570  shown include a translation plugin  571  to extend the translation service, a theme plugin  572  to theme the user interfaces  120 , a menu plugin  573  to provide or extend a menu in the end user portal  514 , and a behaviour plugin  574  to define one or more behaviours of the user interfaces  120 . 
     The integration connectors  140  include non-functional requirements (NFRs)  550  and a set of drivers  560  that can be selected specific to the deployment. A weather driver  561  connects to a third party weather service  583  to retrieve historical weather data for a given location. An address driver  562  connects to a third party address verification service  582  to validate addresses. A system of record driver  563  connects to the customer&#39;s back end system web services, for example, Oracle CSS Web services  584 , to receive data from a system of record, such as usage history or billing history. 
     The NFRs  550  and other integration connectors  140  provide integration to deployment specific applications or connect to third party APIs to connect to these applications. For example, the integration connectors  140  may interface with backend systems of a utility provider by using specific APIs and translating data into a common information model as required by the services  130 . The integration connectors  140  may provide messaging and routing components and manage data flows between the services  130 , components and backend enterprise systems or third party systems. 
       FIG. 6  illustrates a fourth example deployed CSS system  600  for a utility related application. The deployed CSS system  600  is deployed in a cloud data centre  402 . The one or more integration connectors  140  receive data from a utility data centre  404 , and/or one or more third party application programmable interfaces (APIs) or applications  670 . For example, as shown, the one or more integration connectors  140  may include a SOAP API  650  to interface between the services  130  and the API(s)  660  of the utility data centre  404 , and a Representational State Transfer (REST) API  652  to interface between the services  130  and the third party APIs or applications  670 . For example, the API(s)  660  may include the NMS API  462 , the CC&amp;B API  464  and the MDMS API  466  shown in  FIG. 4 . 
     The third party APIs and applications  670  may be utilised by the system to deliver capabilities as required by the system  600 . The third party APIs and applications  670  shown include a Google Maps™ API  672  which may be utilised by the service(s)  130  when displaying outage maps, a Google Analytics™ API  674  which may be used for tracking web analytics and usage in the portal(s)  110 , an address auto completion and validation API  676  which may be used by the service(s)  130  when receiving addresses in the user interface(s), a weather API  678  which may be used to provide historical weather information to the service(s)  130 , and a payment gateway  680  which may be used by the bill payment service  532  for bill payments. For example, the address auto completion and validation API  676  may be an API that is used to connect to SmartyStreets, the weather API  678  may be an API that is used to connect to OpenWeatherMap, and the payment gateway  680  may be an API that is used to connect to payeezy, eWay, PayPal™ or Authorize.net. 
     The one or more integration connectors  140  may also include OAuth connectors for third party authentication, such as Facebook™ connect and Google™ connect, and SMS gateway connectors, such as Twillio™. 
     The system  600  may comprise a database  640  to store some of the information received via the integration connectors  140 . The database  640  typically will only contain minimal information and cached data, and most information used by the system will be stored and updated within the system(s) of record. For example, the database  640  may store details such as a user profile, linked account details and portal lookup data. 
     Utility system administrators  602  may use a computing device  606  to connect via the Internet to a utility administration portal  512  on cloud data centre  402 . End users  604  may use a computing device  606  to connect via the Internet to an end user portal  514  on the cloud data centre  402 . The mail service  541  may connect to an end user&#39;s or customer&#39;s SMTP server  690  to send email notifications to respective end users. For example, the email notifications may notify the end user(s) of outages or other issues in relation to the utility. 
       FIG. 6 a    illustrates a fifth example deployed CSS system  601  for a utility related application. The deployed CSS system  601  is deployed in a cloud data centre  402 . The deployed CSS system  601  comprises a CSS base  102 , a CSS module  104  and one or more integration connectors  140 . The CSS base  102  may comprise one or more base components that may be used for a range of applications, deployments and/or industries. For example, the base components may comprise core or general user interfaces  120  and/or services  130 . The CSS base  102  comprises an account management core component  611 , an administration core component  612 , a payments core component  613 , a weather data core component  614 , a translation core component  615 , a chat core component  616 , a form components component  617 , a file storage component  618 , a menu core component  619 , a notification core component  620 , a PDF generator component  621  and common components  622 . 
     The CSS module  104  comprises a utility administration portal  512  and an end user portal  514 . The CSS module  104  comprises additional components that may comprise interfaces  120  and/or services  130  that extend the base components for the deployment. The additional components may be stand alone or inherit functionality from one or more of the base components. The additional components include a utility account management component  625 , a utility administration component  626 , a utility billing and usage component  627 , a location based analytics component  628 , a utility outages component  629  and a utility cache component  630 . The CSS module  104  may comprise portals  110  and components that customise the CSS base for a deployment or a type of deployment. In the example shown in  FIG. 6   a,  the CSS module  104  is for utility related deployments. For example, the account management core component  611  may provide core account management functions and/or interfaces that may be used in different applications, and the utility account management component  625  may provide additional account management capabilities and/or interfaces that are specific to utility related deployments. 
     The one or more integration connectors  140  receive data from a utility data centre  404 , and/or one or more third party application programmable interfaces (APIs) or applications  670 . The third party APIs and applications  670  shown include a Google Maps™ API  672  which may be utilised by the service(s)  130  when displaying outage maps and location based analytics information, Google Analytics™  674  which may be used for tracking web analytics and usage in the portal(s)  110 , an address auto completion and validation API  676  which may be used by the service(s)  130  when receiving addresses in the user interface(s)  120 , a weather API  678  which may be used to provide historical weather information to the service(s)  130 , a payment gateway  680  and a PayPal payment gateway  684  which may be used by the payments core component  613  and the utility billing and usage component  627  for bill payments, and Twillio™  682  which may be used by the utility outages component  629  to send SMS notifications for outages. 
     The system  601  may comprise a database  640  to store some of the information received via the integration connectors  140  as discussed above. Utility system administrators  602  may use a computing device  606  to connect via the Internet to a utility administration portal  512  on cloud data centre  402 . End users  604  may use a computing device  606  to connect via the Internet to an end user portal  514  on the cloud data centre  402 . 
       FIG. 6 b    illustrates a sixth example deployed CSS system  605  for tax related applications. The deployed CSS system  605  is deployed in a cloud data centre  402 . The deployed CSS system  605  comprises a CSS base  102 , a CSS module  104  and one or more integration connectors  140 . The CSS base  102  comprises the same services  130  as in the fifth example deployed CSS system  601  in  FIG. 6   a.    
     The CSS module  104  may comprise portals  110  and components that customise the CSS base for a deployment, a type of deployment, or a specific industry. In the example shown in  FIG. 6   b,  the CSS module  104  is for tax related deployments. The CSS module  104  comprises a tax administration portal  513  and an end user portal  514 . The CSS module  104  comprises a tax account management component  632 , a tax administration component  633 , a tax registration component  634 , a tax lodgement component  635 , a tax service requests component  636  and a transaction history component  637 . 
     The one or more integration connectors  140  receive data from a tax agency&#39;s data centre  405 , and/or one or more third party application programmable interfaces (APIs) or applications  670 . For example, as shown, the one or more integration connectors  140  may include a SOAP API  650  to interface between the services  130  and the API(s)  660  of the tax agency&#39;s data centre  405 , and a Representational State Transfer (REST) API  652  to interface between the services  130  and the third party APIs or applications  670 . For example, the API(s)  660  may include the PSRM API  478 . 
     The third party APIs and applications  670  may be utilised by the system to deliver capabilities as required by the system  605 . The third party APIs and applications  670  shown include Google Analytics™  674  which may be used for tracking web analytics and usage in the portal(s)  110 , an address auto completion and validation API  676  which may be used by the service(s)  130  when receiving addresses in the user interface(s)  120 , a payment gateway  680  and a PayPal payment gateway  684  which may be used by the payments core component  613  and tax lodgement component  635  for tax lodgement, Twillio™  682  which may be used by the services  130  to send SMS notifications regarding tax, and Auskey  686  that may be used for Single Sign On. 
     Government system administrations or tax system administrators  603  may use a computing device  606  to connect via the Internet to a tax administration portal  513  on cloud data centre  402 . Tax payers  604  may use a computing device  606  to connect via the Internet to an end user portal  514  on the cloud data centre  402 . 
     In some embodiments, the fifth example deployed CSS system  601  may be instead deployed in a utility data centre  404 . In some embodiments, the sixth example deployed CSS system  605  may be instead deployed in a tax agency&#39;s data centre  405 . 
       FIG. 7  illustrates a seventh example deployed CSS system  700 . The deployed CSS system  700  is deployed in a utility data centre  404 . The one or more integration connectors  140  receive data from within the utility data centre and from one or more third party application programmable interfaces (APIs) or applications  670  external to the utility data centre  404 . For example, as shown, the one or more integration connectors  140  may include a REST API  652  to interface between the services  130  and the third party APIs or applications  670 . 
     Utility system administrators  602  may use a computing device  606  to connect via the Internet to the utility administration portal  512  on utility data centre  404 . End users  604  may use a computing device  606  to connect via the Internet to the end user portal  514  on the utility data centre  404 . 
       FIG. 8  illustrates a cache management system  800  for managing data retrieval from the system(s) of record. The cache management system  800  comprises the database  640  to store cached data and a caching service  810  that controls retrieval of data from the system(s) of record  850 . The caching service  810  may include configuration rules defining caching priorities for one or more categories of data. For example, the configuration rules may be specified in a configuration table. The caching service  810  may use asynchronous mechanisms, such as binary partition tree processes, to fetch data from the system of record and cache it to the database based on the configurable rules. 
     The one or more categories of data may include a first category of data that is required in real time, a second category of data that is required as soon as possible, and a third category of data that is cached periodically. The first category of data may include, for example, user data when creating a new account. The second category of data may include, for example, a payment history. The third category of data may include, for example, monthly average temperature. 
     The caching service  810  may be configured to retrieve data in the first category of data for the user interface  120  from the system of record  850 . The caching service  810  may be configured to retrieve data in the second and/or third category of data for the user interface  120  from the database  850 . 
     The deployed CSS system may invalidate one or more categories of data, for example, when a new account is created. The caching service  810  may be configured to retrieve data in an invalidated category of data for the user interface from the system of record  850 . 
     In some embodiments, user interfaces and service within the deployed CSS system may directly access cache tables (read operations) to take advantage of OutSystems platform, such as via True Change, and allow simple calculations to be performed with the data, such as maximum, minimum, average, sorting, pagination and filtering. 
     Embodiments of the deployable and deployed CSS systems described herein may be used in conjunction with a wide range of backend systems without the need for adapting or changing the deployable CSS system. This benefit is provided by having a closed deployable CSS system which can be customised by deployment with integration connectors, such as plugins and drivers, to suit a customer&#39;s needs. For example, the deployable CSS system may be deployed in multiple countries, multiple languages and multiple legislative jurisdictions by adapting the deployable CSS system with suitable plugins. Customer messages may also be adapted via plugins. The deployable CSS system may be deployed to function with backends running different proprietary billing systems, with and on behalf of different utilities and/or organisations, by using integration connectors, such as drivers or APIs, which work with the backend system and the services. For example, the backend systems may include, but are not limited to, SAP, Oracle and Gentrack backend systems. 
     The closed nature of the deployable CSS systems may also isolate the backend from the end user providing improved privacy and cyber security when compared to many existing systems. For example, manipulation via the internet, such as code insertion, cannot occur in the closed parts of the system and therefore an end user cannot gain unauthorised access to information on the system of record. 
       FIG. 9  illustrates a method  900  for providing a payment interface for a utility related application. At step  910 , the method  900  comprises receiving, via a communications network from a computing device, a request to access a customer service portal. 
     At step  920 , the method  900  comprises transmitting, via the communications network to the computing device, a user interface to display on the first computing device, the user interface comprising a payment button located at a fixed location at a right side of the user interface. The payment button may form part of a payment division that stays located at the fixed location. The division may display a payment amount with the payment button. 
     The fixed location may be a fixed location in a window or a fixed location on the screen. The payment button or payment division may stay located at the fixed location in the window or on the screen when scrolling. The payment button or payment division may persist over a plurality of user interfaces. For example, a request to view a second user interface may be received via the communications network from the computing device, and the second user interface comprising the payment button located at the fixed location may be transmitted via the communications network to the computing device to display on the computing device. 
     At step  930 , the method  900  comprises receiving, via the communications network from the computing device, a request based on an actuation of the payment button. 
     At step  940 , the method  900  comprises transmitting, via the communications network to the computing device, a second user interface to facilitate making a payment. 
     In one aspect of the disclosure, a payment button is visible in the portal at all times. For example, the payment button stays permanently placed on the right hand side of the screen or window regardless of whether a user scrolls or changes to another user interface. In preferred embodiments, the payment button on the right hand side of the screen is displayed in exactly the same position consistently regardless of what user interface a user is viewing in the portal. This may allow a user to always be able to actuate the payment button in a single click to facilitate quick and easy payment of a bill. 
     Such positioning of the payment button is based on studies of where the eyes move when reading a page, where a user clicks when reading a page, and what information a user processes to pay a bill. The persistence of the payment button in the same position may also train a user to instinctively look for the payment button in that position. 
     Studies have shown that greater than 70% of customers start on the left of the screen and move to right where often a ‘decision’ point is expected or reached. That is, a user will prefer to look to the right of their screen to take action. This is also reinforced by reading from left to right in Western countries. A Westerner&#39;s eye typically travels down, eye movements scan and then end up finishing on the right hand side panel. 
     Additionally, the user interface as a whole may be designed based on knowledge of how people read web pages as well as hard copy bills. For example, navigation features are located on the far left of the page. This is where people typically look to find a list of current options (reference is made to https://www.nngroup.com/articles/horizontal-attention-leans-left/). The main content starts on the left but to the right of the navigation. The most important content is showcased between one-third and halfway across the screen or window as this is where users typically focus their attention the most. Secondary content may be placed further to the right, if needed. 
     The above placement of the payment button and other aspects of a user interface may be applied in the deployable CSS system  100  or another billing system. In the deployable CSS system  100 , the payment button may persistent on the right hand side of all user interfaces  120  in the end user portal  514 . In some implementations, the location of the payment button will not change between deployments. 
       FIG. 10  illustrates an end user portal  1010 . The end user portal  1010  comprises a left navigation panel  1020 , a top navigation panel  1030 , main content  1040  and a payment panel  1050  at a right of the portal  1010 . The payment panel  1050  comprises a payment button  1060  and is visible in the portal  1010  at all times. For example, the payment button  1060  or the whole payment panel  1050  stays permanently placed on the right hand side of the screen or window regardless of whether a user scrolls or changes to another user interface. In preferred embodiments, the payment button  1060  or the whole payment panel appears exactly in the same position consistently regardless of what user interface a user is viewing in the end user portal  1010 . This may allow a user to always be able to actuate the payment button  1060  in a single click to facilitate quick and easy payment of a bill. For example, a bill may be paid via a payment screen in a small number of clicks, such as three clicks, to make a payment. 
     Based on the studies described above, in the portal  1010  shown in  FIG. 10 , the information for the usage is what customers will see first, and then their eye travels to the right and the final eye placement is on the right hand side panel where the payment button  1060  is located. 
     This may deliver significant benefits to both a customer and retailer, in that a customer may be required to make less decisions and may find the payment button more intuitively than in other bill payment systems. As a result a retailer may have bills paid more quickly. 
     The payment panel  1050  in the embodiment shown also includes other features to assist with customer decisions regarding bill payment, such as a current bill button  1065  that when actuated displays a current bill, a display of a price  1070  to be paid, a display of previous bill prices and percentage change in price  1080 , bill payment options  1075  and an advertising space  1090 . The due date may be displayed in a format that is based on a user&#39;s region or location settings. The bill payment options  1075  are shown to include a direct debit link to set up direct debiting for the user and an eBilling link to set up electronic billing. The previous bill prices and percentage change in price  1080  may include the price of the last bill and the price of the bill from the same period the year before. The percentages may be colour coded to indicate an increase or a decrease in the price. Where there is insufficient data or no previous bill, the percentage may be omitted. 
     Advertisements may be dynamically displayed in the advertising space  1090  of the payment panel  1050 . For example, the following advertisement message may be displayed in the payment panel  1050  as a default: “Pay before your due date and receive a 5% discount!”. The advertising space or other parts of the web portal may also be used by a company to promote and cross sell products and services. 
     The main content  1040 , or user interfaces, may show consumption of a utility in a table or graph, such as a past 12 months energy consumption retrieved from a system of record and weather (current and seasonal) information retrieved from external weather service. The weather information may include current and trend weather patterns, past and projected storm conditions, past and predicted adverse weather conditions, and past and projected natural disaster (warning) type events, such as bushfire warnings. 
     The end user portal may allow a user to view outage details retrieved from a system of record. For example, the outage details may include past, past trend and/or planned outage information on a utilities network. 
     The information that CSS system retrieves from the systems of record may also include information on one or more of the following: solar energy generated or used, home battery storage, on and off premise electric vehicle energy management, peak vs non peak tariffs, access to community and/or local micro grids. Such information and analytics may be made available through smart meter installation and application. 
     The end user portal may allow a user to self-manage their utility settings. For example, the interfaces may display graphs and tables based on the information that CSS system retrieves from the system(s) of record and/or third party service(s) to allow intelligent energy management decision making for customers. Customers may configure their utility account via the end user portal based on the provided information to arrive at “best configuration” for daily, weekly, monthly energy management. 
     The CSS system may also provide backend analytics for the utility company to assist informed decision making on buying into the market, based on how consumers have used the energy management information provided to them. For example, an analytics framework may receive data from the CSS system via the integration connectors and provide the backend analytics. 
       FIG. 11  illustrates an end user portal  1012  that may be used instead of the end user portal  1010 . The end user portal  1012  comprises a left navigation panel  1020 , a top navigation panel  1030 , main content  1040  and a payment panel  1050  at a right of the portal  1010 . The payment panel  1050  comprises a payment button  1060  and is visible in the portal  1010  at all times. 
     The main content  1040  may include one of the user interfaces  120  and shows consumption of a utility in a graph, goals and targets for the user, and tips for how the user can save energy. 
       FIG. 12  illustrates an end user portal  1014  for tax. The end user portal  1014  comprises a left navigation panel  1020 , a top navigation panel  1030 , main content  1040  and a lodgement panel  1250  at a right of the portal  1014 . The lodgement panel  1250  comprises a lodgement button  1260  and is visible in the portal  1014  at all times. For example, the lodgement button  1260  or the whole lodgement panel  1250  stays permanently placed on the right hand side of the screen or window regardless of whether a user scrolls or changes to another user interface. In preferred embodiments, the lodgement button  1260  or the whole lodgement panel  1250  appears exactly in the same position consistently regardless of what user interface a user is viewing in the end user portal  1014 . This may allow a user to always be able to actuate the lodgement button  1260  in a single click to facilitate quick and easy lodgement of a tax return. 
     The lodgement panel  1250  also comprises payroll tax details  1270  and edit buttons to edit the payroll tax details  1280 . When the edit buttons are selected, the main content  1040  may be updated to enable editing of the payroll tax details, or a popup window may be generated to enable editing of the payroll tax details. Therefore, details for a tax return can be updated and lodged in a small number of clicks using the features of the lodgement panel  1250 . The lodgement panel  1250  comprises a payment period indicator  1290  to indicate the taxation period to which the tax return relates. The lodgement panel  1250  comprises a due date indicator  1295  to indicate a date by which the tax return is required to be lodged. The main content  1040 , or user interfaces, may show a monthly tax return history and/or an annual tax return history. 
       FIG. 13  illustrates example flow charts showing functions that may be performed in the deployed CSS system. The functions include account management functions  1310 , login and dashboard functions  1320 , billing management and display functions  1330 , bill viewing and quick payment functions  1340 , payment functions  1350 , outages and fault information and reporting functions  1360 , and usage monitoring and management functions  1370 . The functions also include portal administration functions  1380  and knowledge management functions  1390  that are only accessible via the utility administration portal. 
       FIG. 14  illustrates example flow charts showing functions that may be performed in the deployed CSS system for a utility related application. The functions include billing functions  1410 ; manage account functions  1415 ; account information functions  1420 ; usage functions  1425 ; payments functions  1430 ; usage comparison functions  1435 ; knowledge management and search functions  1440 ; start, stop and transfer services functions  1445 ; outages, faults and enquiries functions  1450 ; communication and notifications functions  1455 ; entry and summary dashboard functions  1460 ; portal administration functions  1465 ; quick view and pay functions  1470 . Some of the functions, such as the knowledge management and search functions  1440  or the portal administration functions  1465  may only be accessible via the utility administration portal. 
       FIGS. 15 and 15   a  illustrate example flow charts showing functions that may be performed in the deployed CSS system for a tax related application. The functions include manage account functions  1510 , entry and home page functions  1520 , account history functions  1530 , service requests functions  1540 , tax registration and registration updates functions  1550 , lodgement and amendment functions  1560 , portal administration functions  1570 , and group management functions  1580 . Some of the functions, such as the portal administration functions  1570  may only be accessible via the tax administration portal. 
       FIG. 16  illustrates an end user portal  1016  showing an example location based analytics interface  1600  in the main content  1046 . The end user portal  1016  also shows a payment panel  1056  at a right side of the end user portal  1016 . The location based analytics interface  1600  comprises a visual representation  1610  which may be used for comparing a utility user&#39;s usage to the average usage of utility users in their area. For example, the location based analytics interface  1600  may compare the utility user&#39;s usage from their last bill to the average of their postcode&#39;s usage for the same period. This may be a user&#39;s usage for the previous month, for example for users with interval meters, or a user&#39;s usage for their most recent billing period (e.g. quarterly), for example for users with basic meters. 
     The visual representation  1610  may comprise a map  1620  showing an area surrounding a specified site associated with the user. For example, the specified site may be associated with an account of the user in the deployed CSS system, such as for billing for utility usage. The site may be, for example, a house, unit, block of units, office building, office, industrial site, mining site, or any other type of site for which a usage may be measured for a user. The map  1620  may be generated in the location based analytics interface  1600  by the location based analytics service based on the Google™ API. The visual representation  1610  also comprises a location indicator  1630  which indicates a location of the specified site on the map  1620 . The map  1620  may be centred on the location indicator  1630 . Where a user&#39;s account identifies multiple sites, the visual representation  1610  may comprise a location identifier  1630  for each site. The location identifiers may be selectable to select among the user&#39;s sites. 
     The location identifier  1630  may be or include an icon or other identifier that is pinned at the location of the site on the map  1620 , for example. In the example shown, the location identifier  1630  may be coloured according to a usage range in which the user&#39;s level of usage falls. A key  1660  may be displayed below the map  1610 . The key may identify categories of usage  1662 , a usage range for each category  1664 , units of measure  1666  and a colour  1668  representing each category. For example, if the user&#39;s usage falls within a low usage category, such as 1-300 kWh, the location identifier  1630  may be coloured green. If the user&#39;s usage falls within a medium usage category, such as 301-600 kWh, the location identifier  1630  may be coloured orange. If the user&#39;s usage falls within a high usage category, such as &gt;601 kWh, the location identifier  1630  may be coloured red. If there is no data on the user&#39;s usage available to the system, the location identifier  1630  may be coloured blue. While colour has been described to represent each category, in other embodiments categories may be distinguished by other means, such as a shape or fill pattern of the location identifier  1630 , for example. 
     The visual representation  1610  may comprise a pop-up window  1640  that shows a comparison of the usage at a site of the user with an average usage of surrounding users, for example, users from the same area, suburb or region. The pop-up window  1640  may be shown by default, or opened when the location indicator  1630  for the site is selected. The pop-up window  1640  may comprise an area identifier  1642 , an average area usage identifier  1644 , a site usage identifier  1646  and a period identifier  1648 . The area identifier  1642  may identify, for example, the premise&#39;s suburb and/or the premise&#39;s postcode. The average area usage identifier  1644  may identify, for example, the average usage for the postcode. The average usage may be for the period of utility user&#39;s last bill and/or in the service type&#39;s unit of measure e.g. 603 kWh. The site usage identifier  1646  may identify, for example, the utility user&#39;s usage from their last bill. The utility user&#39;s usage may be in the service type&#39;s unit of measure e.g. 254 kWh. The period identifier  1648  may identify, for example, the period to which average area usage identifier  1644  and the site usage identifier  1646  relate, such as the period of utility user&#39;s last bill. 
     The average usage for the area and the site usage in the pop-up window may be colour-coded based on the usage range in which they fall. The colour-coding may be the same as the colouring used for the location identifier(s)  1630 . 
     In this example, the location based analytics may be referred to as “neighbourhood watch”, for example, because a user may be compared to their neighbourhood or area. The location based analytics interface  1600  may be accessed via the user portal by selecting a “neighbourhood watch” menu item from the left navigation panel. 
     The utility administration portal may display a location based analytics administration interface to configure the location based analytics interface  1600 . The location based analytics interface  1600  may be configured by changing the categories  1662 , the usage ranges  1664 , the units of measure  1666  and/or the colours  1668 . For example, the location based analytics administration interface may provide controls or forms by which categories  1662 , usage ranges  1664 , units of measure  1666  and/or colours  1668  may be added, deleted or modified. In one example, the following categories and settings are implemented by default: 
     
       
         
           
               
             
               
                 TABLE 1 
               
             
            
               
                   
               
               
                 Example default categories and settings 
               
            
           
           
               
               
               
               
               
            
               
                   
                 Category 
                 Unit of Measure 
                 Range 
                 Colour 
               
               
                   
                   
               
               
                   
                 No Data 
                 kWh 
                   0 
                 Blue 
               
               
                   
                 Low 
                 kWh 
                  1-300 
                 Green 
               
               
                   
                 Medium 
                 kWh 
                 301-600 
                 Orange 
               
               
                   
                 High 
                 kWh 
                 &gt;601 
                 Red 
               
               
                   
                   
               
            
           
         
       
     
       FIG. 17  illustrates an overview of location based analytics system functionality in a deployed CSS system. The deployed CSS system is deployed in a cloud data centre  402 . The deployed CSS system comprises a location based analytics user interface  1710  that is displayed in an end user portal  512  and a location based analytics administration interface  1720  that is displayed in a utility administration portal  514 . Information is provided to the location based analytics user interface  1710  and the location based analytics administration interface  1720  by a usage analytics service  1730 . A usage analytics driver  1740  is deployed as an integration connector to interface between the usage analytics service  1730  and a usage analytics system  1760  in a utility data centre  404 , such as a utility organisation&#39;s system of record. A cache management service  1750  and a database  640  may be used to cache data from the usage analytics system  1760 . 
     The CSS system may determine average usage for the area and the utility user&#39;s usage via data received by the usage analytics driver  1740  from the usage analytics system  1760 . The average usage for the area and the utility user&#39;s usage may be based on a selected service for the site. For example, if the utility user is viewing an electricity service for the site, the data displayed is the user&#39;s electricity usage and the average electricity usage for the area. In some embodiments, the CSS system may be connected via one or more integration connectors to one or more other systems of record, such as other utility company&#39;s systems such that data from different utility companies can be collected to provide more complete data for an area. 
     While the CSS system has been described for use in relation to utilities and tax, in some embodiments the CSS system may be deployed for other applications such as telehealth, proximity group messaging, FinTech (finance focussed technology) or home management, for example. In some embodiments, components may be deployed for these applications as a module which modifies the base components as discussed above 
     In one example, a CSS system for telehealth may provide telecommunication techniques for the purpose of providing telemedicine, medical education, and health education over a distance. This may allow exchange of health information and provide health care related services across geographic, time, social and cultural barriers, for example. The CSS system may comprise the following example components: a portal administration component, a quick view and pay component, a payment component, an account settings component, an account information component, a knowledge management component, a registration, login and forgot password component, and a communication and notifications component. 
     In one example, a CSS system for proximity group messaging may provide the ability for an individual to connect with social groups for a given proximity Individuals may use the CSS system to create/join different social groups and interact with members within a given proximity, for example. The CSS system may comprise the following example components: a portal administration component, a knowledge management component, a registration, login and forgot password component, and a communication and notifications component. 
     In one example, a CSS system for FinTech may be used to provide new technology and innovation for the delivery of financial services. Financial technology companies consist of both start-ups and established financial and technology companies trying to replace or enhance the usage of financial services of incumbent companies. The CSS system may comprise the following example components: a portal administration component, a quick view and pay component, a payment component, an account settings component, an account information component, a knowledge management component, a registration, login and forgot password component, and a communication and notifications component. 
     In one example, a CSS system for home management provides a centralised portal for consumers to manage appliances. The appliances may be managed automatically, programmatically and/or remotely based on time or on responses or signals from other appliances or sensors, for example. Appliances may also be managed manually. Home automation can improve the energy efficiency of a house, enabling consumer savings, reduced energy usage and also reducing appliance operating time. The CSS system may comprise the following example components: a portal administration component, a quick view and pay component, a payment component, an account settings component, an account information component, a knowledge management component, a registration, login and forgot password component, and a communication and notifications component. 
     Throughout this specification the word “comprise”, or variations such as “comprises” or “comprising”, will be understood to imply the inclusion of a stated element, integer or step, or group of elements, integers or steps, but not the exclusion of any other element, integer or step, or group of elements, integers or steps. 
     Any discussion of documents, acts, materials, devices, articles or the like which has been included in the present specification is not to be taken as an admission that any or all of these matters form part of the prior art base or were common general knowledge in the field relevant to the present disclosure as it existed before the priority date of each claim of this application. 
     It will be appreciated by persons skilled in the art that numerous variations and/or modifications may be made to the above-described embodiments, without departing from the broad general scope of the present disclosure. The present embodiments are, therefore, to be considered in all respects as illustrative and not restrictive.