WO2008067618A1

WO2008067618A1 - Methods and systems for providing on-demand data and for analysing customer requirements

Info

Publication number: WO2008067618A1
Application number: PCT/AU2007/001901
Authority: WO
Inventors: Derek Hornby; Martin Nicholas; Leuk Andersen; Paul Runyan
Original assignee: Crosssell Pty Ltd
Priority date: 2006-12-08
Filing date: 2007-12-10
Publication date: 2008-06-12

Abstract

Disclosed is a computer method and system for providing on-demand data in response to on-demand data requests. A plurality of source data is provided which is associated with a plurality of generated and stored sub-processed data, the sub-processed data being a function of the source data. A plurality of processed data being functions of one or more of the sub-processed data are generated and stored and utilised as the on-demand data. Upon receipt of a further on-demand data request, respective ones of the sub-processed data are recalculated if one or more of the source data with which the sub-processed data are associated have been updated. The sub-processed data may be a function of one or more other sub-processed data and/or source data, and at least some of the source data are updated at respectively different predetermined periodic times and/or randomly. Another embodiment is for analysing customer requirements, for example using the above method and system, where extracted data relating to historical, current and projected sales data are provided to a salesperson to facilitate making a sales task decision based on a comparison of the data.

Description

METHODS AND SYSTEMS FOR PROVIDING ON-DEMAND DATA AND FOR ANALYSING CUSTOMER REQUIREMENTS

TECI-INICAL FIELD

The present invention relates to methods and systems for providing and/or processing information, for example in relation to analysing customer requirements.

BACKGROUND ART

Several methods and systems, typically employing the use of software for execution on a computer, are available for analysing customer requirements, particularly to determine a customer's potential products needs. Customer Relationship Management (CRM) software is well known as a tool for providing and/or processing information, such as information relating to managing a customer relationship. CRM software is usually a computer database which enables a company to manage their customer relationships by storing and making available information about a customer for future use to improve the servicing of a customer's needs. CRMs have been developed to be an integrated repository of information for marketing and sales purposes for companies using the CRM to service their customers. Examples of CRM software products include those supplied by Salesforce.com, SAP and Siebel Systems. In practice, CRMs are characterised by many software "screens", or interlinked software application windows, where data relating to pipeline, interaction and leac information are each accessible via separate "screens". CRMs therefore can be inefficient and cumbersome in use. Also, CRMs have been designed to provide a "command and control" tool for companies, aiming to provide continuity should a customer manager leave the company and be replaced by another customer manager with no or little background experience with the leaving customer manager's customers.

CRMs are also characterised as repositories of too much information which cannot easily be accessed by individual users. CRMs are therefore often linked with Business Intelligence (BI) methods and associated software and systems, which aim to simplify and focus information gathering by an individual user. Traditionally, BI has been used by senior executives and analysts for producing end of month reports. BI software and systems are often characterised by extracting existing general ledger-type data relating to historical product sales made to respective customers and arranging the data in various product/customer combinations, or by product and/or product type. The BI software is often comprised of "analytics" modules which may be configured to analyse the historical data in conjunction with sales pipeline data. "Pipeline" sales are sales where a customer has requested and been sent a proposal for a product, but the product delivery is not yet complete. For example, where a bank customer has requested a proposal for a loan/mortgage contract with a bank, and the bank has sent the proposal to the customer, this sending of the loan/mortgage proposal to the customer is considered to be the start of the sales pipeline for the loan/mortgage product to the customer. The proposed sale will leave the pipeline when the agreed funds have been delivered to the customer. In BI systems, the historical and pipeline data can be arranged to provide an impression of the past and current purchasing patterns of a customer to a salesperson, or to a sales team leader, to help make future sales to that customer. Examples of BI software systems include those sold by JasperSoft, SAS and Oracle. BI and CRM software is particularly useful for focussed analysis of customer needs. BI and CRM software and systems may be used by managers of sales teams and salespersons to decide: which current products to promote; potential new products to be developed; most profitable products, or product types; which customers to ignore for the time being; which customers are exhibiting "at risk" behaviour; which customers have potential to grow; and so on.

Data in BI systems is typically updated at the end of a financial cycle, such as at the end of a quarter or month. This can impact on relevance of the data to the user accessing the information, as it may not be particularly up to date. It may only be possible to provide data • at such delayed intervals due to the relatively large volume of source data required to be processed to provide at least some data in CRM & BI systems, and also because some of the data used in the calculations may only be updated monthly. SUMMARY OF THE INVENTION

According to one aspect there is provided a method of providing on-demand data in response to on-demand data requests, the method comprising the steps of, on receipt of an on- demand data request: providing a plurality of source data which is associated with a plurality of generated and stored sub-processed data, the sub-processed data being a function of the source data; generating and storing a plurality of processed data as functions of one or more of the sub-processed data; utilising the processed data as the on-demand data; and upon receipt of a further on-demand data request, recalculating respective ones of the sub-processed data if one or more of the source data with which the sub-processed data is associated has been changed.

Optionally, the sub-processed data is a function of one or more other sub-processed data and/or source data.

Optionally, at least some of the source data are updated at respectively different predictable times and/or at least some of the source data are changed at unpredictable times. The predetermined times may comprise yearly, quarterly, monthly, fortnightly, weekly, daily, hourly, or scheduled time intervals. Optionally, the sub-processed data which is a function solely of said periodically updated source data has associated therewith a cached expiry tag which is itself associated with the periodic nature of the associated source data, and wherein the sub-processed data is re-calculated only if its expiry date has passed. The expiry date may be determined in relation to the earliest expiry date of the source data with which the sub-processed data is associated. Optionally, when the sub-processed data with an associated expiry date tag is recalculated, the expiry date tag is updated.

The processed data and sub-processed data may be stored in a cache, and the processed data and sub-processed data may be refreshed in their cache when they are updated.

Optionally, the method may comprise the steps, prior to the step of re-calculating the sub-processed data, of: reviewing at least some of the sub-processed data to determine whether a re- calculation of a reviewed sub-processed data would provide a different result; and tagging respective ones of the reviewed sub-processed data to indicate whether their re-calculation would provide a different result, such that in the step of re-calculating the sub-processed data only the sub-processed data which are tagged to indicate that re-calculation would provide a different result are recalculated. At least some of the sub-processed and processed data may be tagged with an expiry date, and the step of reviewing may comprise reviewing those sub-processed and processed data whose expiry date has passed. In one form, each tag is a metadata tag stored in the cache. Optionally, the expiry dates may be determined from expiry data in an associated look up table.

Optionally, a controller may determine whether a source data has been updated and, when a source data is updated, the controller may cause the associated sub-processed data and/or processed data to be re-calculated. Optionally, at least some of the source data may be updated periodically at predetermined times, and the controller may instruct the retrieval of updated said periodically changing source data at predetermined respective times relative to their periodic predetermined times.

Optionally, at least one of said sub-processed data is a function of two or more source data and when the two or more source data are updated at different times, the at least one sub- processed data may be refreshed when any of the two or more source data are updated. Alternatively, at least one of said sub-processed data may be a function of two or more source data and when the two or more source data are updated at different times, the at least one sub- processed data is refreshed when a predetermined one of the two or more source data is updated.

Optionally, the source data contains information relating to one or more of historical, current and projected sales data. At least some of the processed and sub-processed data may be obtained by performing analytics calculations on one or more source data and other sub- processed data. Optionally, at least some of the processed data and/or the sub-processed data is assigned a priority status and if one or more source data is updated such that two or more processed data and/or sub-processed data are to be refreshed,- those processed data and/or sub- processed data having a relatively higher order priority status are processed prior to those processed data and/or sub-processed data having a relatively lower order priority status. Priority status may be determined in relation to time sensitivity of the processed or sub- processed data to which a priority status is assigned.

The source data may be obtained from two or more locations. The two or more locations may comprise at least one of a physical location, a database, a data file, and a database table, a hard disc drive (HDD), and HDD partitions.

Optionally, the method is performed on a computer. The computer may be part of a computer network. For example, the type of network may comprise a local area network (LAN), a wide area network (WAN), the Internet, etc.

Optionally, the on-demand data is provided to a plurality of points of use of users. The points of use may comprise networked workstations. The networked workstations may comprise computer workstations. The on-demand data may comprise one or more of information relating to a user's customers, past sales, current sales, and projected sales.

The on-demand data may be refreshed at one or more points of use either periodically, or in response to a user request. The on-demand data may be called from one ore more of cached said processed data in response to the user request. The on-demand data request may be made by a user of the computer(s) and/or the on- demand request may be made by a software daemon which may be configured to make the on-demand request periodically or at scheduled time intervals.

According to another aspect of the invention there is provided a computer system for providing on-demand data in response to on-demand data requests, the system comprising: device for accessing one or more sources of a plurality of source data which is associated with a plurality of generated and stored sub-processed data, the sub-processed data being a function of the source data; device for generating a plurality of processed data as functions of one or more of the sub-processed data; storage device for storing the plurality of processed data; and means for utilising the processed data as the on-demand data; wherein, upon receipt of a further on-demand data request, the recalculating respective ones of the sub-processed data if one or more of the source data with which the sub-processed data is associated has been changed.

Optionally, at least some of the source data are changed at respectively different predictable times and/or at least some of the source data are changed at respectively different unpredictable times. The different predictable times may comprise yearly, quarterly, monthly, fortnightly, weekly, daily, hourly, or scheduled time intervals.

The storage device may comprise one or more caches. The system may comprise a controller configured to determine whether a source data has been updated and, when a source data is updated, the controller is configured to cause the associated sub-processed data and/or processed data to be re-calculated and stored in their respective cache. The system may further comprise a look up table accessible by the controller which defines when at least some of the source data is to be updated.

Optionally, at least some of the source data are updated periodically at predetermined times, and wherein the controller is configured to instruct the retrieval of updated said periodically changing source data at predetermined respective times relative to their periodic predetermined times. The source data may contain information relating to one or more of historical, current and projected sales data.

The system may further comprise means for performing analytics calculations" on one or more source data and other sub-processed data to provide at least some processed and sub- processed data.

Optionally, the controller may be configured to assign a priority status to at least some of the processed data and/or the sub-processed data and the controller is configured such that, if one or more source data is updated such that two or more processed data and/or sub- processed data are to be refreshed, the controller causes those processed data and/or sub- processed data having a relatively higher order priority status to be processed prior to those processed data and/or sub-processed data having a relatively lower order priority status. Priority status may be pre-determined in relation to time sensitivity of the processed or sub- processed data to which a priority status is assigned. Optionally, the source data may be obtained from two or more locations. The two or more locations may comprise at least one of a physical location, a database, a data file, and a database table, a hard disc drive (HDD), and HDD partitions.

Optionally, the system may be configured to provide the on-demand data to a plurality of points of use of users of the system. The on-demand data may comprise one or more of information relating to a user's customers, past sales, current sales, and projected sales.

Optionally, the on-demand data may be refreshed at one or more points of use either periodically, or in response to a user request.

According to another aspect there is provided a method of providing on-demand data, the method comprising the steps of: calculating processed data, thej>rocessed data being a function of one or more of a plurality of source data and a plurality of sub-processed data, the sub-processed data being a function of one or more of a plurality of other of said sub-processed data and the plurality of source data; when one of the source data is updated, re-calculating and storing each sub-processed and processed data associated with the updated source data; and utilising the processed data as on-demand data upon receipt of an on-demand data request.

According to another aspect of the invention there is provided a computer program stored on a computer readable medium for causing a computer to perform the method of any one of the above described method aspects and their optional features.

Sales analysis has typically been historic and reports on what has happened, rather than providing meaningful insight on what may happen. Given that sales analysis reports are typically produced after end-of-month sales and related data is signed off, information is received too late in the business/buying cycle. This may result in reactive behaviour in the sales function, and may be an inhibitor to proactive selling and sustainable revenue growth. The inventors have further recognised that to improve the sales environment, it is desirable to have real-time information on-demand, rather than relying on information which may be up to one month old. However, in reality, using prior art systems to provide the type of on-demand information provided by present described embodiments would use complex calculations of highly populated data sets, often held in separate software systems. In medium to large financial institutions, which may have several hundred to several thousand operators making ad hoc on-demand information requests, such information could not be provided quickly (say, in less than a few minutes) using prior art procedures. The inventors predict that, using computing systems currently used by financial institutions, significant response time delays of over one hour may be experienced by users, meaning the notion of ad hoc on-demand provision of information using current techniques is of little practical use. The inventors therefore propose breaking down the underlying calculations required to produce timely information in response to an ad hoc request into sub-calculations. Using knowledge of the nature of the raw or source data and in particular knowledge of when the source data is likely to be updated, these sub-calculations can be performed in a predictable and manageable manner, and the results of the sub-calculations saved, or cached, for use in further sub- calculations. Therefore, when an ad hoc on-demand request is made for information, at least some if not all sub-calculations have already been performed and their results are available to complete the ad hoc request. This has two immediate benefits. Firstly, the processing demand of the computer system is managed and spread out over time, thus reducing peak processing loads. Secondly, using typical methods, for each ad hoc request, calculations to meet the request would have to start from source data and work through steps to provide the information requested. In at least some of the present embodiments however, each ad hoc request could use results from sub-calculations already performed and thus save having to repeat already performed calculations. This benefit is apparent when considering the magnitude of data required to be processed and the magnitude of users making several ad hoc requests during the course of a working day.

According to another aspect of the invention there is provided a method for analysing customer requirements comprising the steps of extracting historical and/or current sales data from at least one data source; extracting projected sales data from at least one data source; and providing the extracted data to a salesperson to facilitate making a sales task decision based on the comparison.

The inventors have recognised that, for example in a banking context, core banking (including current account management, home loans, personal loans, etc), wealth management and insurance have converged and the systems of the previously separate entities are not aligned to a single management system but include many individual systems. Embodiments of the present invention address this issue by providing a system and method which has the ability to combine the disparate information into one package. Advantageously, by providing the extracted historical and/or current sales data together with projected sales data to a salesperson removes an undue administrative burden from the salesperson, allowing them to focus on the requirements of their customers and to reduce their time required to make decisions about which customers to target for future sales. Furthermore, prior art systems concentrate on manipulating historical and current data to aid sales staff in predicting how future sales with their customers may proceed. In contrast, the above aspect makes available projected sales data to the salesperson which can provide a more realistic appraisal of their customers future product needs and can more effectively make use of the salesperson's time in assessing how to manage their time for making sales, particularly when the projected sales data can be compared with historical and/o^'r current sales data.

Optionally, the method comprises the step, prior to the providing step, of processing the extracted data. Optionally the step of providing the extracted data comprises presenting the extracted information in a single place. Optionally, the single place comprises a single screen. Optionally, the single screen is a single software window.

Providing the software in a single software window further simplifies comparison bythe salesperson of the projected sales data with the historical and/or current sales data. This is a clear improvement with respect to prior art systems, where corresponding information can only be compared between different software programs, or handwritten notes.

Optionally the projected data is extracted from a location different to the location of the historical and/or current data.

For example, the projected sales data may reside on one data storage means (such as a hard disk drive, flash memory, etc), or in a saved file or files of one software program, whereas the historical and/or current sales data may reside on a different data storage means, or be in a saved file or files of a different software program.

Optionally the historical and/or the current sales data and the projected sales data relate to a plurality of customers, each customer having associated therewith one or more said historical and/or current sales data and one or more said projected sales data.

Also optionally, the historical and/or the current sales data and the projected sales data relate to a plurality of products for sale by the salesperson, each product having associated therewith one said historical and/or current sales data and one said projected sales data per respective customer.

The projected data may be determined by at least one user and entered into the at least one projected data source. The at least one user may be the salesperson.

Data may be entered into the projected data source via a different software window to the window mentioned above, but which is linked or tabbed from that window.

Optionally, at least one indicator is linked to a respective at least one projected event datum of the projected event data and configured to indicate to the user the likelihood of a customer buying a product relating to the linked event datum.

The use of indicators further enhances the ability of a salesperson using the method to clearly and quickly identify potential sales.

Optionally the at least one indicator is selected from a group of indicators, where one indicator of the group represents a positive likelihood of the third party buying the related product and another indicator represents a negative likelihood of the third party buying the related product.

Alternatively, the at least one indicator is selected from a group of three indicators, where a first of the group of indicators represents a positive likelihood of the third party buying the related product, a second of the group of indicators represents a negative likelihood of the third party buying the related product , and a third indicator represents a need for more information before it can be determined whether there is a positive or negative likelihood of the third party buying the related product..

Optionally the sales datum linked to the indicator represents either an estimated future sales value for a product associated therewith or is the equivalent of zero. The indicators may be'linked to respective projected sales data.

Optionally there is a plurality of the projected sales data for a plurality of respective customers. The customers may be sortable according to one or more predetermined variables with respect to one or more of the historical and/or current sales data and the projected sales data. The predetermined variable may comprise highest to lowest values of the projected sales data of respective said customers for one or more predetermined products.

Alternatively, the predetermined variable is selected from a group comprising: respective customer year on year growth; respective customer year on year decline; respective customer balances in growth; respective customer balances in decline; respective customer propensity to buy; raw potential of a respective customer. Additionally to, or in isolation of this group, the predetermined variable may comprise customer industry. For example, customers may be sorted according to the industry to which they belong, such as finance, legal, engineering, information technology, and so on such that the customers are displayed in industry groups. Alternatively, instead of sorting by industry, a user may select to view only those customers which belong to a selected industry.

Optionally data of only a predetermined subset of the products and/or customers is selected to be displayed. The respective products may be financial products. For example, the financial products may comprise one or more of home mortgage lending, business lending, investment lending, life insurance, mortgage insurance, general insurance, equity sales, unit trust sales, financial markets, merchant services, transactional accounts, credit accounts. Optionally the extracted data is provided in a two dimensional data array to the salesperson.

Alternatively, in addition to the two dimensional data array, the extracted data may be provided graphically to the salesperson. Optionally the graphical provision comprises graphically representing respective customers on a two dimensional plane, where an ordinate dimension represents the actual revenue of the customers and an abscissa dimension represents a potential revenue of the customers. A predetermined subset of the customers may be represented, the predetermined subset being selected from a group comprising: customers who have not been contacted by the salesperson within a predetermined past time period; customers who have a predetermined outstanding action to be performed by the salesperson; customers who require a predetermined activity to be performed within a predetermined time period; customers whose actual revenue and/or potential revenue are within a predetermined range; customers belonging to a particular industry; "at risk" customers; customers who have lagging deals.

The graphically provided extracted data may be provided in a separate, linked screen to a two dimensional data array of the extracted data.

The customers provided graphically may be selectable by user. If one of the customers is selected, additional predetermined information pertaining to the selected customer may be provided to the user.

The predetermined information may comprise one or more of historical sales data; current sales data; and projected sales data for the selected customer. . Optionally, the predetermined information may comprise one or more of historical sales data; current sales data; and projected sales data pertaining to the selected customer for one or more predetermined products.

According to another aspect of the present invention there is provided apparatus for analysing customer requirements comprising: means for extracting historical and/or current sales data from at least one data source; means for extracting projected sales data from at least one data source; and means for providing the extracted data to a salesperson to facilitate making a sales task decision based on the comparison.

Optionally, the means for providing the extracted data comprises means for presenting the extracted data in a single place. Optionally, the single place comprises a single screen. Optionally, the single screen is a single software window.

Optionally, the apparatus may comprise means for providing performing any one of the method steps with respect to the above aspect of the invention.

According to another aspect of the present invention there is provided a method for comparing product sales amounts of one of a plurality of persons with a corresponding benchmark, the one person having available to them a set of potential product sales to be completed in the future, the method comprising the steps of: using an amount of the product sales of the first person over a predetermined past time period, determining a projected amount of product sales of the first person over a predetermined future time period; and calculating the benchmark by forecasting an amount of corresponding sales achievable over a second predetermined future time period, the achievable amount representing an amount likely to be achieved by a predetermined at least one other person of the plurality of persons given the potential product sales of the first person to be completed in the future. Advantageously, this aspect can indicate to a salesperson or their manager one measure of how much their sales could improve, based on an estimated performance of one of their co-salespersons. This aspect may also be used in conjunction with the above described aspect.

Optionally, the step of determining an amount of sales over a predetermined time period for each person of the plurality of persons, and¹ wherein the amount of sales of the predetermined at least one other person is in a highest 75% of the amounts.

Alternatively, the amount of sales of the predetermined at least one other person is in a highest 50% of the amounts.

Further alternatively, the amount of sales of the predetermined at least one other person is in a highest 25% of the amounts. Further alternatively, the amount of sales of the predetermined at least one other person is between a highest 30% and 20% of the amounts.

Further alternatively, the amount of sales of the predetermined at least one other person is determined as the amount of sales achieved by a theoretical one of the plurality of persons ranked at 25% compared with the respective sales amounts of each of the plurality of persons when ranked in decreasing order of respective sales amounts.

Further alternatively, the amount of sales of the predetermined at least one other person is determined as an average of the amount of sales achieved by each of the plurality of persons ranked within the highest 25% of persons of the plurality of persons in terms of their respective sales amounts. The product sales may relate to products comprising financial products including home loans, insurance, business loans, financial advice, credit card account, savings account, line of credit, stock trading account.

The predetermined past time period may begin from period begins from the first day of the financial year and ends at the time the method is performed. Optionally the predetermined future time period begins from the day after the method is performed and ends on the last day of the financial year. Other appropriate time ranges may be used, depending on the requirements of the user of the method.

As will be understood, whereas the preferred features above are described with respect to financial products, the above aspects and their preferred features are also applicable to sales of other products, for example mobile telephones, other consumables, utilities

(electricity, gas and water supply), insurance, travel and holidays, and wealth management. As will be appreciated, any of the aspects and their optional features described above may be carried out by a processing device such as a computer.

According to another aspect of the present invention there is provided a computer program, stored on a tangible storage medium, comprising executable instructions that causes a computer to perform the method of any one of the preceding claims.

According to another aspect of the present invention there is provided apparatus for comparing product sales amounts of one of a plurality of persons with a corresponding benchmark, the one person having available to them a set of potential product sales to be completed in the future, the apparatus comprising: means for using an amount of the product sales of the first person over a predetermined past time period, determining a projected amount of product sales of the first person over a predetermined future time period; and means for calculating the benchmark by forecasting an amount of corresponding sales achievable over a second predetermined future time period, the achievable amount representing an amount likely to be achieved by a predetermined at least one other person of the plurality of persons given the potential product sales of the first person to be completed in the future.

Optionally, the apparatus may comprise means for performing any one of the method steps with respect to the above aspect of the invention for comparing product sales amounts. According to another aspect of the invention there is provided a method for analysing the customer requirements comprising the steps of: extracting historical and/or current event data from at least one data source; extracting projected event data from at least one data source; and providing to a user the extracted data to facilitate a comparison between the extracted historical and/or current data with projected data to facilitate the making of a task decision based on the comparison.

As will be appreciated, the event data may comprise sales data as described above, however may also comprise time data relating to tasks to be completed in a project management system. Furthermore, event data may relate to time, for example for time keeping where a user records their time spent performing predetermined tasks on one or more projects. An application of this comprises time recordal of solicitors where a solicitor will record their time for performing a given task for a given customer. In this aspect, the solicitor can compare their historical and/or current recorded time data with projected time estimated and allocated to the solicitor for- performing future tasks for their customer.

According to an alternative arrangement there is provided a method of providing on- • demand data comprising the steps of: providing a plurality of source data; generating and storing a plurality of sub-processed data as a function of the source data, wherein portions of the source data are associated with respective ones of the sub- processed data; generating processed data as functions of one or more of the sub-processed data; and utilising the processed data as on-demand data upon receipt of an on-demand data request, wherein the sub-processed data is recalculated in response to updating of the source data to which it is associated. According to an alternative arrangement there is provided a computer system for providing on-demand data, the system comprising: device' for accessing one or more sources of a plurality of source data; device for generating a plurality of sub-processed data as a function of the source data, wherein portions of the source data are associated with respective ones of the sub-processed data; storage device for storing the sub-processed data; device for generating processed data as functions of one or more of the sub-processed data; and means for utilising the processed data as on-demand data upon receipt of an on- demand data request, wherein the sub-processed data generating device is configured to recalculate the sub- processed data in response to updating of the source data with which it is associated.

According to another alternative arrangement there is provided method of providing processed data for use in an on-demand processing event, the method comprising the steps of: calculating and storing a plurality of processed data, each processed data being a ^• function of one or more of a plurality of source data and a plurality of sub-processed data, the sub-processed data being a function of one or more of a plurality of other of said sub- processed data and the plurality of source data; when one of the source data is updated, re-calculating and storing each sub-processed and processed data associated with the updated source data; and providing predetermined stored processed data as on-demand data upon receipt of an on-demand data request, wherein at least some of the source data change at respectively different periodic predetermined times.

For the purposes of the description of the preferred embodiments and the definition of the invention, for convenience, the terms "data" and "datum" include numerical data and datum, and null data and datum, unless the context requires otherwise. Furthermore, the term "on-demand data" is to be understood to mean data which is requested by a user, for example for display on a VDU; "processed data" is to mean data which is the result of one or more calculations and whose result is useable in its "processed" form as "on-demand data"; "sub- processed data" is to mean data which is derived from a calculation whose result may be used with other "sub-processed data" or "source data" for further calculation to form another "sub- processed data" or "processed data"; "source data", also known as "primitive data" is to mean raw data; "periodic data" is to mean data which changes in a predictable rnanner, such as at fixed intervals or scheduled intervals (discussed in further detail below); and "volatile data" is to mean data which changes unpredictably (discussed in further detail below). As will be understood, in some circumstances, certain "sub-processed" data may be considered as "processed data". That is it may be both useable in further calculations to form further sub- processed data or processed data, or it may be useable in its "sub-processed" form as "on- demand data". Unless otherwise stated, the features described above with respect to a particular embodiment may be combined with one or more features of other embodiments described above and in the following detailed description. BRIEF DESCRIPTION OF THE DRAWINGS

Preferred embodiments of the invention will now be described, by way of example only, with reference to the accompanying drawings in which: Figure 1 is a schematic diagram illustrating a computer system on which embodiments may be performed;

Figures 2 to 8 illustrate screen views of preferred embodiments of several aspects of the present invention;

Figure 9 illustrates a prior art schematic data tree diagram; Figures 10a, 10b are schematic data tree diagrams in accordance with an embodiment;

Figure 1 1 is a schematic data tree diagram in accordance with another embodiment; Figure 12 illustrates an example of a data tree diagram utilising the embodiment illustrated in Figure 1 Oa; and

Figure 13 is a schematic diagram of a system embodiment.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

A preferred embodiment is a method for analysing customer requirements such as their propensity to purchase one or more products, or types of products, which a user of the method may sell to one or more customers. The method is arranged for use by users who are employees, contractors, directors etc of a company. In the following examples illustrated in Figures 2 to 7, the user is a frontline salesperson of a financial institution, such as a bank, building society, credit union, etc. As will be understood, alternative embodiments may be directed to use in a context other than a financial institution. For example, the user of an alternative embodiment may be a frontline salesperson for a telecommunication company, or a general insurance company. Alternatively, embodiments could be arranged for use in, for example, equity market analysis, project management, or manufacturing sales.

While not intending to be an exhaustive or limiting list, typical product types available for sale by such financial institutions include home loan mortgages, personal and/or business credit cards, savings accounts, cheque accounts, current accounts, business loans, business lines of credit, investment loans, insurance such as life insurance, home and contents insurance, mortgage insurance, income protection insurance and travel insurance, share stock and other equity brokerage, and so on. Each of these product types may include two or more actual products. For example, the financial institution may provide for sale to its customers several credit card products, such as, but not limited to, MasterCard®, Visa® and/or Bankcard®.

A preferred embodiment of the method is configured for use on a system such as a computer system 10, an example of which is illustrated schematically in Figure 1 and described as follows. The computer system 10 in this instance is configured as a Local Area Network (LAN) having a server 12 controlled by a central processing unit (CPU) 13. Workstations 14a, 14b are connected to the LAN using known methods. As will be understood, whereas Figure 1 illustrates only two workstations 14a, 14b, many more workstations may be connected to the network, either remotely or by direct cable connection. In the example illustrated in Figure 1, each workstation 14a, b comprises a computer 16a, 16b, a Visual Display Unit (VDU) 18a, 18b and an input device in the form of a keyboard 20a, 20b and a mouse 22a, 22b. Database storage sources in the form of dedicated hard disk drives (HDDs) 24a, 24b, 24c are arranged on the server 12 for access by salespersons connected via the workstations 14a, 14b to the server to data stored thereon. The database storage sources in alternative embodiments may be located in separate files on one HDD of the server 12, may be located on separate workstations connected to the server 12, external HDDs connected to the server 12 or may be located on separate servers accessible via a workstation 14a,b. In an alternative embodiment, the database storage devices may be configured as electronic files stored on a HDD of the server 12. The preferred embodiments may be implemented by software running on the system 10, the software being arranged to implement the functionality of the preferred method embodiments discussed in detail below. As will be understood, alternative software and/or hardware architecture may be utilised for carrying out the method embodiments.

In the preferred embodiment, historical sales data is stored on database HDD 24a. This historical sales data may be obtained from general ledger data of a proprietors or known system relating to sales of particular products by particular customers of the company whose salespersons employ the method. Current sales data in the form of pipeline sales data is stored on database storage HDD 24b. Projected sales data in the form of estimated future sales data is stored on database storage HDD 24c. The general ledger and pipeline sales data are gathered and stored in their respective HDDs 24a, b in a known manner. This data may be considered as "hard" data in the sense that the general ledger sales data is a record of actual past sales and the pipeline sales data is a record of data relating to sales for which the customer has requested a proposal or is committed. The estimated future sales data is not hard data but rather is estimated data gathered by one or more salespersons from contact with the customer, or gathered indirectly by one or more salespersons, and input into database storage HDD 24c by the one ore more salespersons via their respective workstation 14a or 14b. The general ledger data is updated daily, whereas the pipeline and estimated future sales data is updated in real time.

The embodiment is configured such that the general ledger, pipeline and estimated future sales data can be extracted from their respective database storage HDD 24a, b, c and arranged in a single place, in this embodiment being a single software scrollable window 26 which is displayable on the VDU 18a, b of a salesperson's workstation 14a or 14b to allow visual comparison between the extracted data. An example of how this data may be arranged is illustrated in Figure 2 which shows a simplified view of a software program screen that may be viewed by a salesperson. In the example illustrated in Figure 2, for convenience there are illustrated six products, and three customers to which products may be sold. As will be appreciated, in practice there may be tens or hundreds of customers, and tens of products which may or may not be grouped by product type. Data is configured in a spreadsheet-like arrangement, where each datum is in a datum cell. For each customer there is illustrated historical, pipeline and estimated sales data for each respective product, where applicable, as indicated in Figures 2 and 3. Totals of the historical sales, pipeline sales and estimated sales data for each customer are displayed in the far right hand .totals column 32. Where there is no available data for sales of a particular product, a cell associated with that sale of product is left blank, having a "null value". For example, referring to Figure 2, customer 1 has not purchased product 6 and therefore the cell corresponding to the historical sales of product 6 is null.

Depending on the requirements of the salesperson, the data can be sorted based on predetermined variables. For example, illustrated in Figure 2 is a "major products" view as indicated by button 36. That is to say, when the major products view is selected, only those products designated as major products are shown on the VDU 18a, b and the related data sorted accordingly. In this example, there are six major products. Referring to Figure 3, the salesperson can sort the data by selecting button 36 with their mouse 22 to reveal a dropdown menu 38 listing particular data views available to the salesperson. For example, the salesperson may select a view to arrange the customers in order of highest to lowest estimated data values, independent of product. This enables the salesperson to determine quickly and easily the customer or customers with the highest estimated potential sales such that those customers may be contacted by the salesperson to make a sale. Other views which may be selected from the dropdown menu 38 are listed in Figure 3 and include: customer's next most likely product to purchase; the financial institution's most popular products within the product listing; most popular product bundles within the product listing; "balances in growth" customers, where customer's product purchasing activity has been increasing over time; customer's "year on year decline", which arranges customers in order of those customers whose purchasing history has been declining with time; a customer's raw potential for purchasing a product (where they are currently not purchasing the product); and those customers indicating a propensity to buy a particular product or product from a product group. "Propensity to buy" is where the customer is exhibiting behavioural characteristics suggesting they will/will not use a particular product. Propensity to buy is determined by a customer's known use of marketing materials provided by the financial institution, such as attending seminars and requesting marketing material. As will be understood, in alternative embodiments, there may be fewer or additional views. The details for each of these views, when selected, may be processed on demand from the relevant data or pre-calculated at regular intervals, such as hourly or once daily, and stored for future reference (when selected for viewing) depending on the computer processing required to determine the view in question. For example, less processing intensive views such as most popular products,

"balances in growth", and "year on year decline" can be processed on demand, when selected for viewing by the user. Other more processing intensive views, such as "raw potential" and "propensity to buy" which take into account more variables than the aforementioned less processing intensive views can be pre-processed hourly or daily and stored for later display when selected by the user. The fact that these particular views are pre-processed does not greatly affect the accuracy of the information displayed, as they rely on information which does not necessarily change more frequently than once per hour. As will be understood, in other embodiments, some or all the views may be processed and calculated on demand, or some or all the views may be pre-processed or calculated at regular intervals, such as hourly or daily. Given practical expectations of users, it is preferred that when a user selects a view it is displayed within 5- 10 seconds. Therefore, whether or not a view is calculated/processed on demand or pre-processed/calculated at regular intervals will depend on how quickly the view can be displayed to the user once selected.

Another predetermined variable on which the data may be sorted is customer industry type. This is embodied in Figures 2 to 4 by button 39 which, when selected provides a drop down menu similar to the operation of menu 36. When selected, burton 39 provides a list of industries by which the customers can be sorted. These include, but are not limited to: finance; engineering; marketing; legal sales; other; and all (the default as illustrated in Figures 2 to 4). Other embodiments may include more or fewer industries for a salesperson to select. When selected, only those customers who belong to the selected industry are shown in the window 26. This further aids the salesperson in sorting their information into a more usable form.

As illustrated in Figures 2 and 3, some cells corresponding to estimated future sales data comprise an indicator linked to the datum in the datum cell, whether that datum be a numerical figure or a null value. There are three types of indicator derived from six key characteristics of a customer in relation to purchasing a product in question. The six characteristics include: purchasing decision maker of the customer; purchasing process of the customer; customer uses or has potential to use the product; the current supplier of the product to the customer; estimated required value amount of the product in question; and description of the sales opportunity. At least some of the information relating to these characteristics is obtained from data entered into or calculated by the financial institution's third party CRM software package. The present system can therefore be tailored to be integrated with the third party CRM package such that it can extract the characteristics information from the CRM software package. Where this is either not possible, or the CRM package does not have information relating to some or all of the six characteristics, a further - data entry window (for example as illustrated in Figure 8) may be made available to the user to enter this data. The further data entry window may be accessible from one or all of the windows illustrated in Figures 2 to 5, or may be a separately accessed data entry window.

If none of the six characteristics have been determined for the customer with respect to the product in question, no indicator is applied to the corresponding estimated future sales datum cell; the opportunity of future sales to the customer is considered '"unqualified". If all characteristics have been determined for a particular customer in relation to a particular product, and they indicate a positive likelihood of the customer purchasing the product, a first indicator, for example illustrated in cells denoted at 40 in the form of light shading, is provided in the datum cell representing a positive likelihood of the customer buying the related product; the opportunity of future sales to the customer is considered "qualified". For example, light shading in cell 40a indicates a high chance that customer 1 will buy product 4. Furthermore, as illustrated, it is estimated that customer 1 will purchase product 4 in the amount of $100,000. If only some but not all of the six characteristics have been determined for a particular customer with respect to a particular product, a second of the three indicators is provided, for example as illustrated in cells 42 in the form of vertical bars, representing a part-known likelihood of the corresponding customer buying the related product; the • opportunity of future sales to the customer is considered "pre-qualified". For example, the vertical bars of cell 42a indicates that further information is required with respect to customer 1 purchasing product 6. Lastly, if all or enough of the characteristics have been determined for a particular customer in relation to a particular product to indicate a negative likelihood of the customer purchasing the product, a third of the three indicators is provided in the form of dark shading 44 representing a negative likelihood of a corresponding customer purchasing the related product. For example, the dark shading illustrated in cell 44a indicates that customer 2 is unlikely to purchase product 5. In an alternative embodiment, the three indicators are in the form of green, yellow and red cell shading for positive, unknown and negative likelihoods, respectively. Other appropriate indicators may also be used. Also, as will be understood, additional or fewer of the six above characteristics may be used to determine likelihood of purchase.

If an estimated future sales datum cell has no indicator, or a part-known indicator (eg cell 42a' s vertical bars) for a given customer and/or product, this is an indication to the salesperson that they or a fellow employee of the financial institution needs to perform some research into the customer's purchasing requirements and behaviour in relation to the financial institution's products offered for sale. This estimated data and/or likelihood of purchase can be obtained either by directly contacting the customer or from background . research on the customer's purchasing activities. For example, it may be discovered by the salesperson that customer 2 has already purchased product 5 from a competitor to the financial institution, that they are happy with the competitor's product and do not want to change product supplier. Therefore, product 5 is indicated for customer 2 as an unlikely future sale event for the salesperson. On the other hand, the salesperson may have been contacted by customer 1 requesting information for product 4 and that they are positively considering purchasing product 4 from the salesperson, while providing the salesperson with information allowing the salesperson to identify the six characteristics for the customer. In this case, customer 1 is indicated as a possible purchaser of product 4. Once all the six characteristics of the customer in relation to purchasing the product are known, the estimated future sales data cell in relation to the customer and product can be indicated as having a positive likelihood of a sale.

Figure 4 illustrates a re-arrangement of the customers based on a selection of "Raw Potential" from the drop down menu 38. The customers, and their related historical, pipeline and estimated future sales data, have been re-arranged in decreasing "raw potential" order for product 4, based on their estimated future sales data with a positive likelihood of purchase by the customer. Therefore, since customer 3 has an estimated $900,000 of future sales with positive likelihood, compared to $100,000 for customer 1 and null for customer 2, the descending customer order illustrated is customer 3, customer 1, customer 2. The "Raw Potential" view illustrated in Figure 4 also comprises additional useful information. Rows 45 summarise the number of cells in terms of positive likelihood, negative likelihood, part- known likelihood and unknown likelihood. The percentage totals of these likelihoods for the salesperson is shown in the far right column headed "Me%". For comparison, a list of corresponding percentage totals for a "quartile 1 performer" is provided in the column headed "Ql%". A quartile 1 performer is a salesperson whose sales activities are within the top 25% of the salespersons of the financial institution. In this embodiment, the "Ql%" data is calculated as achieved by theoretical salesperson who is ranked at 25% with respect of the salespersons of the financial institution. In the data illustrated in Figure 4, the quartile 1 performer has 40% of their estimated future sales data qualified as having a positive likelihood of conversion. This is in contrast to the salesperson using the system whose percentage positive likelihood is 22% - lower than the quartile 1 performer. This gives an indication to the salesperson as to where he is placed among his colleagues. Similarly, in ^■ comparison of negative, part-known and unknown likelihoods, it is seen that the salesperson is under performing with regard to negative and unknown likelihoods in comparison with quartile 1 performers, while he fares better in comparison with respect to part-known likelihoods.

The features of the embodiment described above help, the salesperson to focus their time on selling their products, without wasting their time on attempting to assess which customer to contact next to make a sale.

As described above, the historical data is sourced from the company's general ledger from HDD 24a for display on the screen illustrated in Figures 2 to 4. The estimated future sales data on the other hand is sourced from a different location (HDD 24c) on the network and entered using the interface shown in Figure 8 and the user's respective mouse 22a, b and/or keyboard 20a, b in a different window, such as the window illustrated in Figure 8, which is linked to the main window illustrated in Figures 2 to 4.

The window illustrated in Figure 5 represents an opportunity analysis of the selected customer. It is at this screen that data obtained by the salesperson, for example by interaction with the customer, can be entered and viewed. Detailed background information regarding customer interactions and other strategic and industry information with respect to the customer may also be viewed on this screen. For example, in the industry customer information box 46 there may be viewed details such as the type of industry to which the customer belongs; size of the customer in terms of number of employees; the most popular product and most popular bundle in the customer's industry; key industry drivers for the customer; the average cross sell for the customer's industry; and the customer's actual cross sell. Depending on the variable in question, this information will typically be derived from the financial institution's CRM package and/or from information entered via the window illustrated in Figure 8. In the strategy and stated objectives box 48 the salesperson can list objectives obtained from conversations with the customer, together with the employee of the customer from which the information was obtained and the date on which the information was obtained. The last five interactions box 50 and the last five deals box 52 are self explanatory as the titles of the box suggest, and can list last five deal and interactions in terms of their relevant date, product description, revenue, etc. The data displayed in the window illustrated in Figure 5 may be linked to the data in the window illustrated in Figure 8, where applicable.

Figure 6 illustrates a screen of an alternative embodiment which may be used in conjunction with or in isolation of the above described embodiment. This embodiment comprises a method for comparing sales amounts of one of a plurality of persons, in the form of sales teams, with the corresponding benchmark. A sales team will include a plurality of salespersons. The revenue amounts of each sales team represents the cumulative revenue amounts of the salespersons who are members of the sales team. In this embodiment, this revenue information is presented on a revenue graph 53. The plurality of sales teams are members of an overall sales team. In the example illustrated in Figure 6, there are ten sales teams, including an Adelaide sales team, which is highlighted and which will be referred to below. In this method, one sales team (the Adelaide sales team in the example of Figure 6) has available to them a set of potential activities in the form of potential sales to be completed in the future. Firstly, a cumulative value of the sales history of the sales team is determined, as illustrated by the solid line 54. A forecasting algorithm is used to determine a projected amount of measurable activities of the salesperson over a predetermined future time period. This projected amount of measurable activities is in the form of future sales, and is illustrated by a broken line 56. In calculating the projected amount of measurable activities, the forecasting algorithm takes into account the salesperson's historical revenue, estimated future sales data, percentage positive conversion of estimated future sales data into actual sales, and their typical turn around time of sales deals as a function of how long it takes a sale of a product from being entered as a pipeline sale to being converted to an actual product sale. In this example, the predetermined future time period is the time from the present day to the end of the financial year. The financial year is illustrated in graph 53 along the X axis by quarters of the financial year (Ql, Q2, Q3, Q4). This estimated future sales data can be compared against the sales team's target illustrated by line 60 in graph 53. In this example, the Adelaide sales team is below its target. Furthermore, as seen from line 56, if the sales team follows its present path of sales, it will not achieve its target 60. If provided with this information alone, it is difficult for the sales team or its manager to determine whether it is underperforming or whether its target is unrealistically high. Therefore, to help with this assessment, there is provided a benchmark for comparison with the estimate of sales of the sales team. The benchmark is illustrated in Figure 6 by broken benchmark line 62. The benchmark is calculated by forecasting an amount of future sales which it is estimated would be achieved by another sales team of the overall team given the potential sales and leads of the first mentioned sales team, the average turn around time for members of the other sales team to convert sales in the pipeline to actual sales, and the percentage conversion of estimated future sales to actual sales. The bench mark is calculated over a second predetermined period of time, which in this case is the same as for the projected future sales of the first mentioned sales team; from the present day to the end of the sales team's current financial year.

The other sales team is a theoretical sales team who represents a sales team whose sales activities (being the measurable activities described above) are ranked about 25% in the team. That is, the theoretical sales team can be considered as the theoretically lowest member of the highest quartile sales team in terms of sales activities. As is evident from the benchmark line 62 illustrated in Figure 6, it is calculated that such a sales team would exceed the Adelaide sales team's target represented by target line 60 given the Adelaide sales team's potential sales and leads. In another arrangement, rather than comparing a sales team's performance against a benchmark, the performance of a salesperson can be compared against the members of the overall sales team, or against members within the salesperson's team (such as "Adelaide" in the example). In this arrangement, the performance of a salesperson can be compared against a benchmark which represents a theoretical salesperson ranked at 25% of sales in the overall sales team, in a similar manner as described above. Furthermore, depending on the company's requirements, an individual salesperson can be compared against a theoretical benchmark ranked at 25% of sales activities of a subset. This would allow easy comparison within the respective sales team subsets.

As mentioned above, the embodiment illustrated in Figure 6 can be used in combination with the first mentioned embodiment. For example, the benchmark may be calculated using the projected estimated sales data captured and stored in database 24c. In one embodiment, a software program product is executed and determines of each sales team member their sales activities over time and the volume of their estimated future sales with positive likelihood of success. From this data, each team member is ranked within the team from highest to lowest in terms of historical sales data. An estimated historical sales volume of the theoretical salesperson ranked at about 25% of the team is then calculated. It is assumed the sales activities of the theoretical salesperson increases over time, taking seasonal variability into account. From this, the likely projected sales of the theoretical person can be determined given their projected future sales. This can then be mapped across to any one of the team members to determine how the theoretical salesperson would^'perform given their potential future sales with positive likelihood of success. As will be understood, for all team members in the bottom 75% of their team in terms of historical sales, volumes, the benchmark future sales data (eg as represented by benchmark line 62) will be higher than their projected sales data (eg as represented by line 56). Therefore when this benchmark and projected sales^" data is represented to the salesperson in a manner such as illustrated in Figure 6 with respect to the first mentioned salesperson, the sales team members armed with this information can be inspired to improve their sales performance. This inspiration would come in the knowledge that at least a quarter of their fellow team members would achieve above their sales performance given the same projected potential sales. As will be understood, should this impact on the sales performance of the bottom 75%, the overall sales performance of the team would be improved, which places upward pressure on the sales volume and projected future sales volume of the theoretical salesperson. Therefore, this can positively feed back into the overall team sales performance to encourage the team members to perform to their full potential.

To further provide a salesperson, or a leader/manager of a sales team, with information regarding an individual or sales team performance, additional information can be provided in the same viewing area, or software window, as the revenue graph 53. This additional information includes a pipeline summary 64, opportunity analysis 66, sales activity 68 which is arrangeable by week, month, quarter and annual sales activity, and a league ladder 70 which is arrangeable by individual salespersons or sales team. The information provided in this window can be dynamic, being updated at regular intervals, such as hourly, half daily or daily. The theoretical salesperson and theoretical sales team used for the benchmark in the above embodiment is calculated as the being ranked at about 25% of sales activities of the sales team. As will be understood, in alternative embodiments, the theoretical salesperson may be calculated at any predetermined rank, for example within the range of within the highest 75% or 50% of sales activities, or between the highest 30 and 20% of sales activities. Also, in an alternative embodiment, the theoretical salesperson may be calculated as an average of sales activities of the highest 25% of all members. Also, in addition to the above mentioned features, the forecast may also take into account seasonality (where sales activity is relatively less at certain times of year) and historical trends. As will be evident, the embodiment described with respect to Figure 6 can help encourage salespersons performing below the theoretical 25% salesperson to focus on improving their sales activities.

The embodiment illustrated in Figure 7 can be used in combination with either of the above described embodiments or in isolation. Figure 7 illustrates a screen which may be linked to the screen to the previous embodiments and which shows a modified weighted quadrant graph to help a salesperson visualise their customers in terms of growth potential, need to retain, potential targets to win, and customers that require qualification. Where the customer may lie within this quadrant graph is a reflection of their actual revenue, scaled on the Y axis (the ordinate), and their potential revenue, scaled on the X axis (the abscissa). The potential revenue is based on estimated future sales data with a positive likelihood of success (as described above in relation to Figures 2 and 3) and pipeline data, whereas the actual revenue is based on historical sales data. For illustrative purposes, the three customers discussed above with respected Figures 2 to 5 are used in this embodiment. In this embodiment, the salesperson with responsibility for customers 1 , 2 and 3 can graphically and intuitively determine which of these customers should be targeted first for a potential sale, where the most promising sales prospects will be with those customers listed in the top right hand quadrant 71a (in this case customer 3). After the customers in the top right hand quadrant have been approached, the salesperson can then decide which customers to approach based on those have high actual revenue and low potential revenue (in quadrant 71b) and therefore require servicing to retain that revenue (in this case customer 1), and those customers which have no historical sales at the present time but have an indication of high estimated future potentials sales and are therefore potential customers to win (quadrant 71c; this does not apply to any of customers 1, 2 or 3 in this illustration). Lastly, the salesperson can easily determine from the quadrant graph which customers have provided relatively low historical actual revenue and have low potential to provide future .revenue (quadrant 7 Id; in this case, customer 2). These customers can be ignored or contact of these customers can be deferred. As is evident from Figure 7, the quadrants are weighted, where the first quadrant 71a is the largest of the quadrants, the fourth quadrant 7 Id is the smallest of the quadrants, and the second and third quadrants 71b,c are the same size as each other, are smaller than the first quadrant 71a and larger than the fourth quadrant 7 Id. This weighting provides a more realistic interpretation of which customers to target and which to defer compared with prior art quadrant graphs whose quadrants are of equal size. As explained above, in practice a salesperson may be responsible for 10s or 100s of customers. Therefore, in practice, this weighted quadrant graph will be highly populated and it can therefore provide a salesperson with a quick overview of which customers to concentrate on in terms of making sales and which can perhaps be ignored or contact deferred. In this embodiment, it is possible for the salesperson to select quadrants individually to illustrate only one quadrant at a time on the screen. This is achieved by selecting which quadrant to view via drop down menu 72. Also, to further enhance the ability of the quadrant graph, it is possible for the salesperson to display on the quadrant graph those customers which meet predetermine variables. The variables in this embodiment are represented by drop down menu 74, whose selectable menu items are self explanatory. For example, it is_. possible to display only those customers which are considered "unloved customers" where no contact has been made with the customer within the last 3 months. It is also possible to display only those customers who ^■ are considered to be "customers at risk" where for example it is known that a competitor to the financial institution is actively pursuing the customer for sales of competing products, the customer has a declining number of transactions, the customer is paying off their debts, and/or where a customer is exhibiting behaviour similar to previous "lost" customers prior to the lost customers leaving the financial institution. The data arrangements from drop down menu 74 may be determined from customer data entered via the window illustrated in Figure 5, together with historical and pipeline data, depending on the menu item selected. In a preferred arrangement of this embodiment, it is possible for a salesperson to select a customer displayed in the quadrant graph by using their mouse 22 to the displayed customer of interest. When selected, a "pop up" window displays more detailed information regarding the particular customer. For example, the pop up window may display historical sales data, pipeline sales data, estimated future sales data, and/or the products for which the customer is known to have a positive likelihood of purchasing. "Double clicking" a customer of interest with the mouse 22 will display the screen illustrated in Figure 5 to the salesperson to provide them with further background information regarding the customer in question.

In another arrangement of the embodiment illustrated in Figure 7, instead of using the quadrant graph as a visual comparison of customers, it can also be arranged as a visual comparison of salespersons in a sales team. For example, salespersons in a sales team may be shown as points on a graph, where the Y axis represents actual revenue over a predetermined time period (eg year-to-date) and the X axis represents unrealised potential revenue. This would allow, for example, a leader of a sales team to assess comparatively aspects of the performance of members of their sales team. Similarly to the embodiment described above, each salesperson would be represented as a point on the quadrant graph, and each point would be selectable to allow a user to obtain further information about the salesperson having been selected. The examples illustrated in Figures 2 to 5 show three customers and six products. As will be understood, a salesperson of financial products could potentially have a portfolio of over one hundred customers, and a product list of over 50 products in several categories. Also, the historical data is listed in Figures 2 to 4 as a single figure for each product per customer. In an alternative embodiment, the historical data may be divided and illustrated in different components depending on the salesperson's requirements. For example, the historical data may be arranged in three rows per customer relating to the last year to date, current year to date, and 12 month rolling average for each product corresponding to each customer. Another embodiment will now be described, with reference to Figures 9 to 13, which may be. used in conjunction with any of the above described embodiments. This embodiment is a method of providing on-demand data, such as the data displayed in Figure 2.

Figure 9 illustrates a prior' art theoretical approach to calculating information, such as the above described financial information, where diamond A represents processed data for viewing and use by a user, and circles 100 represent unique source data or "primitive" data. The processed data A is a function of each of the source data 100. As will be understood, in practice in a financial institution, there may be over one million unique source data, and there may be over fifty unique processed data A to be represented to a user in various formats, such as those illustrated in Figures 6 and 7. Furthermore, where the processed data A is made available to frontline salespersons of the financial institution, there may be five hundred to two thousand individual salespersons requiring access to the processed data A. In some calculations of single processed datum, processing time may be in the order of minutes, such as five to fifteen minutes. Traditionally, this approach would be used to^' calculate processed data A at the end of a monthly financial cycle, for example. Given the lengthy time for calculation, it would typically be run over night outside of users working hours. As will be understood, it is not practical to be able to provide the processed data A on-demand to the users, when considering the number of processed data required and the number of users. If one source data were to be updated, the routine for providing processed data A would have to be re-run for the processed data A to be up to date.

Figures 10a and 10b illustrate a theoretical approach to another embodiment, where like reference numerals denote like parts, which allows practical provision of on-demand data which overcomes or ameliorates the problems associated with the prior art example represented in Figure 9. Generally speaking, this embodiment provides on-demand data calculated from multiple data sources using complex equations in real time to multiple users by breaking up the complex calculations into sub-calculations, or sub-processes, and performing the sub-processes over time, caching the sub-calculation results for later processing. Referring to Figures 10a,b, instead of attempting to calculate processed data 102 in one process, the calculation, or equation, is broken down into manageable sub-processes 104 and the result of each sub-process stored, in this embodiment cached. As illustrated in Figure 10a, each sub-process 104 is associated with a subset of one or more source data 100, and/or one or more other sub-process. For example, sub-process 104a is associated with sub- processes 104b, c and source data 100a. Sub-process 104a may therefore also be considered as associated with source data 100b and 100c via associated sub-processes 104b,c. Also in this embodiment, there is a process data 106 which is a result of a final stage process and which is cached for on-demand access when required by a user. In this sense, the on-demand data 108 provided to the user can be cached data, in that the on-demand user request recalls the pre-processed "data 106 from its cache as opposed to performing a processing or calculation action in itself. In an alternative arrangement, the final process stage to provide data 106 is performed in response to an on-demand request by a user and as such is not cached prior to a user on-demand request. This general arrangement is similar to "memoizaϋon". However, memoization is limited to a straight batch process, where once a sub-routine has been performed and its associated sub-processed data cached, it no longer changes. Memoization is not practical nor used for long running applications whose source data changes within the lifetime of the application. The present embodiment differs from memoization in several respects, as will be apparent in the following discussion.

In the embodiments illustrated in Figures 9 to 13, each sub-process 104 is requested to recalculate, or refresh, when one of a sub-process 104 or source data 100 with which it is associated is refreshed. Using the example illustrated in Figure 10b, source data 100a has changed. This necessitates the recalculation and cache refreshing of, in turn, sub-process data at 104a, 104d and process data 106, as will be described in more detail below. As will be appreciated, only those sub-calculations required to provide sub-process data 104a, 104d and process data 106 are required to be performed and their results cached in order to take into account the change to source data 100a. This provides an advantage in reducing the amount of processing required to provide the on-demand data 108. Figures 10a, 10b illustrate a simple tree diagram with source data 100 which is used to provide one processed data 106. As will be understood, the topology of the interaction could be more complex to provide more than one processed data from a plurality of source data with some overlapping of source data used to provide more than one processed data. Figure 1 1 illustrates one such example where like reference numerals denote like parts. In Figure 11₃ two processed data 106a, 106b are obtained from several calculations of sub-processed data 104 derived from a plurality of source data 100. Figure 12 illustrates a simplified example of a tree structure for a frontline salesperson of a financial institution. In this example, as illustrated, the source data comprises "quantity of loans per bank branch" 110a, "average loan revenue" 110b, "number of branches" 1 10c, "quantity of deposits per branch" HOd, "average deposit revenue" HOe, "staff A cost" HOf, "credit facility cost" 11Og, "staff B cost" 11Oh, "marketing cost" 11Oi and "automatic teller machine (ATM)" costs 1 10j. Sub-processes in this example comprise "home loan revenue" 112a, "deposit revenue" 112b, "home loan cost" 112c, "deposit cost" 1 12d, "total revenue" 112e and "total cost" 112f. The processed data available to be called by an on-demand query in this example comprises "profit" 114. As will be understood from the above description in relation to Figures 10a, 10b, the data and sub-processing structure means that a change in one source data does not require recalculation using all source data to arrive at processed data "profit" 1 14. For example, in one scenario, a user wants to check on a current "profit" 1 14 standing, and there have only been changes to source data for "marketing costs" HOi. In this scenario, "total revenue" 112e and "home loan cost" 112c remain unchanged. However, given that "total cost" 112f is a function of "deposit cost" 112d, which is in turn a function of the changed "marketing cost" HOi, "deposit cost 1 12d and "total cost" 1 12f will need to be recalculated before determining "profit" 1 14. The detail of how this may be calculated follows.

Referring again to Figures 10a,b, each source data 100 falls into one of two categories with respect to life cycles: those data which are refreshed, or updated, in a predictable manner, either periodically or by schedule; and those data which are refreshed in an unpredictable manner, such data also being known as "volatile data". The data which refreshes periodically may refresh at different times, such as monthly (for example on the last day of each month, the first Tuesday of each month, the fifth day of each month, etc), fortnightly, weekly, daily, each business day, hourly, and so on. Data which undergoes scheduled changes may change, for example, five minutes after closing time of the Australian Stock Exchange on every second Tuesday of each month. The data which refreshes in an unpredictable manner may be refreshed, for example, in response to a user updating customer information.

Figure 13 illustrates an embodiment of part of a computer system which may be employed to perform the above described method. In this system, source data is sourced from several separate primary systems. Source data may be derived from push and pull data services 124a,c and/or system data 124b, each of which may be sourced from independent and separate systems. A data integrator 126 extracts and translates source data from the primary systems for use with the present embodiment. A switch 127 directs data to be analysed in response to a user request (described in more detail below). A data mapper 128 adapts the data from the data integrator 126 to a system internal call format. The sub- processed data is stored in a cache 132. A web adapter 136 in combination with an authenticator 137 is employed to translate between the internal call format used in the system and hypertext transfer protocol (HTTP) to allow the use of a front end graphical user interface (GUI) 138 in an extensible mark-up language (XML) for displaying the on-demand data to a user on their networked desktop workstation computer, or similar end user device, for example in one or more display formats as described above and illustrated in Figures 1 to 8. In this embodiment, the GUI is scripted in Asynchronous JavaScript and XML (AJAX). Optionally, as is used in this embodiment, an HTTP accelerator/frontside cache operator 139, or third party proxy, can be used in combination with an accelerator cache 140 for caching of HTTP responses from the web adapter 136 in a known manner. In use, the flow of data through the system works on a top-down data "pull" model, as opposed to a bottom-up data "push" model. This approach can provide a relatively simple and uniform compositional structure that can model the hierarchical nature of the sub- processing of data required in the present embodiment. The pull model used in this embodiment splits the processing into linked stages, where an output of one stage is the input of the next, but implements each stage as a distinct component. This has several advantages in reducing complexities of programming, but prior art methods have their own problems which are addressed by this embodiment. The pull model operates both on demand from user data requests, and proactively by performing scheduled calculations to refresh sub-processed data so that it is ready for use when a user request is made. To improve the efficiency and to simplify each of these processes, each sub-processed data which is associated or derived solely from source data known to change periodically and predictably is determined as having an expiry date relating to the source data associated therewith having the shortest lifespan. The life cycle of each sub-processed data can be predetermined, given that the lifecycle of the source data with which it is associated is known, and stored in a data lifecycle model 142. Therefore, each time these sub-processed data are recalculated, a metadata expiry date is cached in associate with its corresponding recalculated sub-processed data, based on its entry in the data lifecycle model 142. Following is an example where this expiry tag is useful. Referring to Figure 1 Ob, if a user makes an on- demand request for processed data 108, the system will call on processed data 106. Prior to releasing data 106, the system via the switch 127 will check the expiry date of data 106. If it has not expired and is therefore current, data -106 will be returned to the user as 108. If the expiry date of data 106 has passed, the system via switch 127 will check the expiry date of sub-processed data 104d and the two source data which are used to calculate data 106. If for example the two source data 100 are determined not to be expired, but the expiry date associated with sub-processed data 104a has passed; then the switch will check the expiry dates associated with the source data 100a and sub-processed data 104b, 104c, and so on, until the associated source data which has expired is identified. The, the sub-processes can be calculated and propagated back up the data pipeline to the user on-demand data 108. When each sub-processed data is recalculated, its expiry date is updated, using the data lifecycle model 142, and stored in the cache 132 in association with the recalculated sub-processed data. In this way, unnecessary re-calculation of data which is otherwise current is avoided. Where a sub-processed data is associated with two or more periodically changeable source data, the expiry date for the sub-processed data will be associated with the expiry date of the source data with the shortest expiry date. In an alternative embodiment, in this situation the expiry date for the sub-processed data will be associated with the expiry date of the source data having the shortest lifecycle.

The expiry date may be a predetermined length of time after the associated source data with shortest lifecycle is known to expire. For example, where a sub-processed data is associated with a source data which expires at 9am on each Monday, the expiry date of the associated sub-processed data may be at 9:05am on each Monday. As will be understood, this data calculation would not be possible where any of the sub-processed or processed data are derived from volatile data, as it is not possible to provide an accurate expiry date for such data. In this case, sub-processed and processed data undergoes a validation process to allow checking of such data prior to recalculation. In this embodiment, the validation process utilises validation keys. Validation keys are used to tag sub-processed and processed data which is derived from one or more volatile data, or from periodic data whose expiry date has passed, by validation keys structurally recursive and the system that processes them procedurally recursive. In this embodiment, it works as follows. All operations (recalculations) will include processing and providing a validation key in their request inputs and return validation keys with their responses. These validation keys are metadata which are stored in the cache 132 associated with their respective source data, sub- processed data and processed data. When a request from the switch 127 during a recalculation of a sub-processed data is made for a result that has been cached but doesn't have an expiry, the switch 127 further calls the operation that produced it with a conditional request passing in the cached validation key. This repeats recursively all the way down through related sub-processed data 104 of the sub-processed data structure. When all the source data and sub-processed data that provide inputs to a sub-processed or processed data return the equivalent of a "Not-Modified" response, the platform causes the operation to by pass further processing a return a "Not-Modified" response in turn. If any of the sub- operations returns a new response the calling operation also produces a new response. Therefore, when a "Not-Modified" response is returned for a source data and its associated sub-processed and processed data, it is known that the source data for each of those associated sub-processed and processed data is not changed and so, where applicable, the top- down recalculation steps of processed and sub-processed data can occur in the knowledge that the volatile source data from which it is derived is current. Therefore, where appropriate, the recalculation can use cached sub-processed data. When a "Modified" response is returned, the recalculation steps must call all the way down the pipeline to the modified volatile source data before recalculation can occur.

One would expect that the use of a validation checking step of sub-processed and processed data derived from at least one volatile source data would increase the overall time taken to provided the on-demand data to^' a user, given that it introduces the additional checking step. However, as has been surprisingly found by the inventors, in situations where there are many thousands of source data and sub-processes to be performed, the validation checking step can reduce the number of sub-process recalculations and therefore reduce the overall processing time.

If the above described calculations were to be performed solely in response to a request from a user, there may be unacceptable delays in providing the user with up to date data. For example, some recalculations may take up to 10 minutes. This is particularly so when many users are accessing the same system. This embodiment therefore also makes use of scheduled and rdactive calculations to "prime" the cache 132 with non-expired and/or "Not-Modified" validated sub-processed and processed data 104, 106. Cache "priming" ensures that, when a user request is made, at least some of the sub-processed and processed data is within expiry date limits, or validated as "Not-Modified". Therefore, when an actual user makes an on-demand data request, the number of recalculations required to be performed can be reduced such that data is provided within acceptable user time limits. Priming is particularly useful for those sub-processed and processed data recalculations known to be time intensive. Scheduled priming is run by the scheduled priming daemon 144. The scheduled priming daemon makes scheduled dummy requests for processed data to ensure at least some of the non-vόlatile cached sub-processed and processed data is within its expiry date, using processes described above. Depending on the on-demand data to be updated, the schedule priming daemon 144 may be set to make a dummy request using knowledge of when source data is likely to be updated, or to send periodic dummy requests. The priming schedule 146 maintains times for when the schedule priming daemon is to make particular dummy requests. A "reactive priming engine" 148 is used to recalculated sub-processed and processed data which are derived from at least one volatile source data. Rules for when the reactive priming engine 148 is to send dummy requests are stored in the reactive priming rules 150 and are configured depending on the volatile source data in question and user requirements. For example, depending on the volatile source data in question, recalculations which use data derived from volatile source data may be scheduled to be recalculated weekly, monthly or in reaction to an event such as a currency exchange rate exceeding a set upper limit or a value of a client's product portfolio dropping below a set lower limit. In an alternative- embodiment, only scheduled priming is used, where sub-processed and processed data derived from one or more volatile data are provided with a set expiry date.

Where required, an actual user on-demand data request will take precedence over a priming dummy data request.

In one embodiment, the reactive priming engine 148 is in communication with the switch 127 and the switch 127 is configured to let the reactive priming engine 148 be called upon when specific predetermined results are updated. This feature may not be present in alternative embodiments.

In another embodiment, the cached data is stored in more than one cache, for example, it may be shared between the cache 132 and the accelerator cache 140. Referring to Figure 13, additional features of the above embodiment include the use of application modules 154 which perform analytics on the data, and an asynch reactor 156. The application modules 154 of this embodiment make use of an alert dispatcher 155. The alert dispatcher 155 can be used to dispatch alerts to a user based on rules applied from one or more of the application modules 154. For example, when a customer is determined to be displaying characteristics based on their up to date and recent transaction history of a customer "at risk" (as described above), an alert may be sent to the salesperson responsible for that customer, such that the salesperson can decide whether or not to approach the "at risk" customer to understand why they may be using a competitor's services. Another example of an alert dispatched by the dispatcher 155 may include where a salesperson identified a that a customer may be interested in purchasing a particular product, but has not, within a predetermined time, followed up the potential sale with that customer.

The data lifecycle model 142 may take the form of a table which defines a schedule for each data stored in the cache 132. The switch 127 is configured to check the data from the data lifecycle model 142 during recalculations to update an expiry date a recalculated sub- processed data. This allows for sub-processed and processed data to be available on-demand for a user when the user calls the data. As described above, when a user makes an on-demand data request, he may be provided with cached processed data rather than causing a process to occur to calculate a result.

At some times, it may not be possible to provide refreshed sub-processed data within an acceptable timeframe (eg within 3 seconds), for example, when the system has not finished recalculating sub-processed data, or several users have made particular on-demand requests requiring additional non-scheduled data refreshing. As will be understood, one or some of the additionally expired data may either be unlikely to have changed significantly or may not greatly effect the outcome of refreshing the sub-processed data in question. In this case, the user is provided with expired data or in order to provide data which reasonably closely approximates an ideal refreshed sub-processed data within the acceptable time frame. This may be termed a "best effort" result, or use of "soft-real time data", which reduces impact and overload on processing and optimises throughput of refreshed data. In instances where processing resources may be near to full capacity such that it is not possible to perform all scheduled (primed) re-calculations of sub-processed or processed data, re-calculations are prioritised and those re-calculations are queued in order of priority. Priority is set in the calculation rules. In situations where a user has made an on-demand request and the system can't provide results in a predetermined time (eg 1 seconds), the user is provided on their VDU with the out-of-date cached processed data. In one arrangement, this out-of-date processed data is refreshed on the user's VDU once the re-calculation has been performed and the processed data re-calculated. In a further embodiment, the out-of-date processed data may be displayed on the user's VDU in a different form to up-to-date data. For example, the out- of-date data may be displayed to the user in a different colour in comparison with other data, or it may be surrounded by a box or similar indicia. In this way, the user knows they are reviewing out-of-date data which is to be refreshed.

Components of the system of this embodiment is controlled by a management utilities module 158 which can be manipulated via a management console 160. The management utilities 158 can be manipulated to alter, for example, the application- modules 154 or their associated rules, the data lifecycle model 142, the priming schedule 146, the reactive priming rules 150, and so on.

In use, the switch 127 directs sub-processed data for processing and therefore directs data to the application modules 154 to perform analytics on the source data and sub-processed data.

The system also operates to prime the cache 132 with re-calculated sub-processed and processed data, using a synchronous pull pipeline data model, in anticipation of a user requesting the data. A reference herein to prior art is not an admission that the prior art forms part of the common general knowledge in the art in Australia.

In the claims which follow and in the preceding description of the invention, except where the context requires otherwise due to express language or necessary implication, the word "comprise" or variations such as "comprises" or "comprising" is used in an inclusive sense, i.e. to specify the presence of the stated features but not to preclude the presence or addition of further features in various embodiments of the invention.

Claims

CLAIMS:-

1. A method of providing on-demand data in response to on-demand data requests, the method comprising the steps of, on receipt of an on-demand data request: providing a plurality of source data which is associated with a plurality of generated and stored sub-processed data, the sub-processed data being a function of the source data; generating and storing a plurality of processed data as functions of one or more of the sub-processed data; utilising the processed data as the on-demand data; and upon receipt of a further on-demand data request, recalculating respective ones of the sub-processed data if one or more of the source data with which the sub-processed data is associated has been changed.

2. The method of claim 1 wherein the sub-processed data is a function of one or more other sub-processed data and/or source data.

3. The method of claim I or 2. wherein at least some of the source data are changed at respectively different predictable times and/or at least some of the source data are changed at unpredictable times.

4. The method of claim 3, wherein the different predictable times comprise one or more of yearly, quarterly, monthly, fortnightly, weekly, daily, hourly, or scheduled time intervals.

5. The method of any one of the preceding claims, wherein the processed data and sub-processed data are stored in a cache, and wherein the processed and sub-processed data are refreshed in their cache when they are updated.

6. The method of any one of claims 3 to 5 wherein sub-processed data which is a function solely of said periodically updated source data has associated therewith a cached expiry date tag which is itself associated with the periodic nature of the associated source data, and wherein the sub-processed data is re-calculated only if its expiry date has passed.

7. The method of claim 6 wherein the expiry date is determined in relation to the earliest expiry date of the source data with which the sub-processed data is associated.

8. The method of claim 6 or 7 wherein when the sub-processed data with an associated expiry date tag is recalculated, the expiry date tag is updated.

9. The method of any one of the preceding claims wherein each respective sub- processed data which is a function of at least one non-periodically updated source data is tagged with a validation key relating to the last occasion the sub-processed data was recalculated.

10. The method of claim 9 comprising the step, prior to performing the recalculation step on those sub-processed data which are a function of at least one non- periodically updated source data, of checking the validation key for the sub-processed data and each other subsequent sub-processed data and/or source data associated with the sub- processed data, and, if the validation key of any of the sub-processed data, subsequent associated sub-processed data and/or source data are determined to have changed, recalculating each subsequent associated sub-processed data and the sub-processed data and at the same time updating their validation key.

11. The method of any one of the preceding claims, wherein the source data contains information relating to one or more of historical, current and projected sales data.

12. The method of any one of the preceding claims, wherein at least some processed and sub-processed data is obtained by performing analytics calculations on one or more source data and other sub-processed data.

13. The method of any one of the preceding claims, wherein at least some of the processed data and/or the sub-processed data is assigned a priority status and wherein if one or more source data is updated such that two or more processed data and/or sub-processed data are to be refreshed, those processed data and/or sub-processed data having a relatively higher order priority status are processed prior to those processed data and/or sub-processed data having a relatively lower order priority status.

14. The method of any one of the preceding claims, wherein the priority status is determined in relation to time sensitivity of the processed or sub-processed data to which a priority status is assigned.

15. The method of any one of the preceding claims, wherein the source data is obtained from two or more locations.

16. The method of claim 15, wherein the two or more locations comprise at least one of a physical location, a database, a data file, and a database table, a hard disc drive (HDD), and HDD partitions.

17. The method of any one of the preceding claims, wherein the method is^' performed on a computer.

18. The method of claim 17, wherein the computer is part of a computer network.

19. The method of any one of the preceding claims, wherein the on-demand data is provided to a plurality of points of use of users.

20. The method of claim 19 wherein the points of use comprise networked ■ computer workstations.

21. The method of any one of the preceding claims, wherein the on-demand data comprises one or more of information relating to a user's customers, past sales, current sales, and projected sales.

22. The method of any one of the preceding claims, wherein the on-demand data is refreshed at one or more points of use either periodically or in response to a user request.

23. The method of claim 21 wherein the on-demand data is called from one or more of cached said processed data in response to a user request.

24. The method of any one of the preceding claims wherein the on-demand data request is made automatically periodically such that at least some of the sub-processed data does not require recalculating when the on-demand request is made by a user.

25. The method of claim 24 wherein a software daemon is configured to make the on-demand request periodically.

26. A computer system for providing on-demand data in response to on-demand data requests, the system comprising: device for accessing one or more sources of a plurality of source data which is associated with a plurality of generated and stored sub-processed data, the sub-processed data being a function of the source data; device for generating a plurality of processed data as functions of one or more of the sub-processed data; storage device for storing the plurality of processed data; and means for utilising the processed data as the oh-demand data; wherein, upon receipt of a further on-demand data request, the recalculating respective ones of the sub-processed data if one or more of the source data with which the sub-processed data is associated has been changed.

27. The system of claim 26, wherein at least some of the source data are changed at respectively different predictable times and/or at least some of the source data are changed at respectively different unpredictable times.

28. The system of claim 27, wherein the different predictable times comprise one or more of yearly, quarterly, monthly, fortnightly, weekly, daily, hourly, or scheduled time intervals.

29. The system of any one of the preceding claims, wherein the storage device comprises one or more caches.

30. The system of any one of claims 26 to 29, wherein the source data contains information relating to one or more of historical, current and projected sales data.

31. The system of any one of claims 26 to 30, comprising means for performing analytics calculations on one or more source data, and other sub-processed data to provide at least some processed and sub-processed data.

32. The system of any one of claims 26 to 31, wherein the source data is obtainable from two or more locations.

33. The system of claim 32, wherein the two or more locations comprise at least one of a physical location, a database, a data file, and a database table, a hard disc drive (HDD), and HDD partitions.

34. The system of any one of claims 26 to 33 configured to provide the on-demand data to a plurality of points of use of users of the system.

35. The system of claim 34 wherein the points of use comprise networked computer workstations.

36. The system of any one of claims 26 to 35, wherein the on-demand data comprises one or more of information relating to a user's customers, past sales, current sales, and projected sales.

37. The system of any one of claims 26 to 36, wherein the on-demand data is refreshable at one or more points of use either periodically or in response to a user request.

38. The system of claim 36 configured such that the on-demand data is called from one or more of cached said processed data in response to the predetermined action of the user.

39. A computer program stored on a computer readable medium for causing a computer to perform the method of any one of claims 1 to 25.

40. A method for analysing customer requirements comprising the steps of: extracting historical and/or current sales data from at least one data source; extracting projected sales data from at least one data source; processing the extracted data; and providing the extracted data to a salesperson to facilitate making a sales task decision based on the comparison.

41. The method of claim 40, wherein the step of providing the extracted data comprises presenting the extracted data in a single place.

42. The method of claim 41 , wherein the single place comprises a single screen.

43. The method of claim 42, wherein the single screen is a single software window.

44. The method of any one of claims 40 to 43, wherein the projected data is extracted from a location different to the location of the historical and/or current data.

45. The method of any one of claims 40 to 44, wherein the historical and/or the current sales data and the projected sales data relate to a plurality of customers, each customer having associated therewith one or more said historical and/or current sales data and one or more said projected sales data.

46. The method of any one of claims 40 to 45, wherein the historical and/or the current sales data and the projected sales data relate to a plurality of products for sale by the salesperson, each product having associated therewith one said historical and/or current sales data and one said projected sales data per respective customer.

47. The method of any one of claims 40 to 46, wherein the projected data is determined by at least one user and entered into the at least one projected data source.

48. The method of any one of claims 40 to 47, comprising at least one indicator linked to a respective at least one projected event datum of the projected event data and configured to indicate to the user the likelihood of a customer buying a product relating to the linked event datum.

49. The method of claim 48, wherein the at least one indicator is selected from a group of indicators, where one indicator of the group represents a positive likelihood of the third party buying the related product and another indicator represents a negative likelihood of the third party buying the related product.

50. The method of claim 49, wherein the at least one indicator is selected from a group of three indicators, where a first of the group of indicators represents a positive likelihood of the third party buying the related product, a second of the group of indicators represents a negative likelihood of the third party buying the related product , and a third indicator represents a need for more information before it can be determined whether there is a positive or negative likelihood of the third party buying the related product.

51. The method of any one of claims 48 to 50, wherein the sales datum linked to the indicator represents either an estimated future sales value for a product associated therewith or is the equivalent of zero.

52. The method of any one of claims 48 to 51 , wherein the indicators are linked to respective projected sales data.

53. The method of any one of claims 40 to 52, comprising a plurality of the projected sales data for a plurality of respective customers.

5

54. The method of any one of claims 40 to 53, wherein the customers are sortable according to one or more predetermined variables with respect to one or more of the historical and/or current sales data and the projected sales data.

I O 55. The method of claim 54, wherein the predetermined variable comprises highest to lowest values of the projected sales data of respective said customers for one or more predetermined products.

56. The method of claim 55, wherein the predetermined variable is selected from a 5 group comprising: respective customer year on year growth; respective customer year on year decline; respective customer balances in growth; respective customer balances in decline; respective customer propensity to buy; raw potential; next most likely product; most popular product; most popular product bundle. 0

57. The method of any one of claims 40 to 56, wherein data of only a predetermined subset of the products and/or customers is selected to be displayed.

58. The method of any one of claims 40 to 57, wherein the respective products are financial products. 5 .

59. The method of any one of claims 40 to 58, wherein the financial products comprise one or more of home mortgage lending, business lending, investment lending, life insurance, mortgage insurance, general insurance, equity sales, unit trust sales. 0

60. The method of any one of claims 40 to 58, wherein the extracted data is provided in a two dimensional data array to the salesperson.

61. The method of any one of claims 40 to 60, wherein the extracted data is provided graphically to the salesperson.

62. The method of claim 61 , wherein the graphical provision comprises graphically representing respective customers on a two dimensional plane, where an ordinate dimension represents the actual revenue of the customers and an abscissa dimension represents a potential revenue the customers.

63. The method of claim 61 or 62, wherein a predetermined subset of the customers is represented, the predetermined subset being selected from a group comprising: customer who have not been contacted by the salesperson within a predetermined past time period; customers who have a predetermined outstanding action to be performed by the salesperson; customers who require a predetermined activity to be performed within a predetermined time period; customers whose actual revenue and potential revenue are within a predetermined range; customers at risk.

64. The method of any one of claims 61 to 63, wherein the graphically provided extracted data is provided in a separate, linked screen to a two-dimensional data array of the extracted data.

65. The method of any one of claims 61 to 64, wherein the customers provided graphically are selectable by a user, and wherein when one of the customers is selected, additional predetermined information pertaining to the selected customer is provided to the user.

66. The method of claim 65, wherein the predetermined information comprises one or more of historical sales data; current sales data; and projected sales data for the selected customer.

67. The method of claim 65, wherein the predetermined information comprises one or more of historical sales data; current sales data; and projected sales data pertaining to the selected customer for one or more predetermined products.

68. The method of any one of claims 40 to 67, wherein the extracting and/or processing steps occur at predetermined times or on demand.

69. A method for comparing product sales amounts of one of a plurality of persons with a corresponding benchmark, the one person having available to them a set of potential product sales to be completed in the future, the method comprising the steps of: using an amount of the product sales of the first person over a predetermined past time period, determining a projected amount of product sales of the first person over a predetermined future time period; and calculating the benchmark by forecasting an amount of corresponding sales achievable over a second predetermined future time period, the achievable amount representing an amount likely to be achieved by a predetermined at least one other person of the plurality of persons given the potential product sales of the first person to be completed in the future.

70. The method of claim 69, comprising the step of determining an amount of sales over a predetermined time period for each person of the plurality of persons, and wherein the amount of sales of the predetermined at least one other person is in a highest 75% of the amounts.

71. The method of claim 69, wherein the amount of sales of the predetermined at least one other person is in a highest 50% of the amounts.

72. The method of claim 69 wherein the amount of sales of the predetermined at least one other person is in a highest 25% of the amounts.

73. The method of claim 69, wherein the amount of sales of the predetermined at least one other person is between a highest 30% and 20% of the amounts.

74. The method of any one of claims 69 to 73, wherein the product sales relate to products comprising financial products including home loans, insurance, business loans, financial advice, credit card account, savings account, line of credit, stock trading account.

75. The method of any one of claims 69 to 74, wherein the predetermined past time period begins from the first day of the financial year and ends at the time the method is performed.

76. The method of any one of claims 69 to 74, wherein the predetermined future time period begins from the day after the method is performed and ends on the last day of the financial year.

77. The method of any one of claims 40 to 76, wherein the method is carried out by a processing device such as a computer.

78. A computer program, stored on a tangible storage medium, comprising executable instructions that cause a computer to perform the method of any one of claims 40 to 76.

79. Apparatus for analysing customer requirements comprising: means for extracting historical and/or current sales data from at least one data source; means for extracting projected sales data from at least one data source; and means for providing the extracted data to a salesperson to facilitate making a sales task decision based on the comparison.

80. The apparatus of claim 79, wherein the means for providing the extracted data comprises means for presenting the extracted data in a single place.

81. The apparatus of claim 80, wherein the single place comprises a single screen.

82. The apparatus of claim 81, wherein the single screen is a single software window.

83. Apparatus for comparing product sales amounts of one of a plurality of persons with a corresponding benchmark, the one person having available to them a set of potential product sales to be completed in the future, the apparatus comprising: means for using an amount of the product sales of the first person over a predetermined past time period, determining a projected amount of product sales of the first person over a predetermined future time period; and means for calculating the benchmark by forecasting an amount of corresponding sales achievable over a second predetermined future time period, the achievable amount representing an amount likely to be achieved by a predetermined at least one other person of the plurality of persons given the potential product sales of the first person to be completed in the future.