Patent Application
20130018982
A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.
One or more implementations relate generally to an automated process for presenting to a user of a user system recommended information from a customer relationship management system on a cloud computing platform.
The subject matter discussed in the background section should not be assumed to be prior art merely as a result of its mention in the background section. Similarly, a problem mentioned in the background section or associated with the subject matter of the background section should not be assumed to have been previously recognized in the prior art. The subject matter in the background section merely represents different approaches, which in and of themselves may also be inventions.
Customer relationship management (CRM) refers to methodologies and strategies for helping an enterprise develop and manage customer relationships in an organized way. A CRM system typically refers to a software-based solution implemented on one or more computer devices that collect, organize and manage customer and sales information. Most CRM systems include features that allow an enterprise to track and record interactions, including emails, documents, jobs, faxes, and scheduling. These systems typically focus on accounts rather than on individual contacts. They also generally include opportunity insight for tracking sales pipelines and can include added functionality for marketing and service. Other CRM systems also offer sales force automation features that streamline all phases of the sales process. For example, such CRM systems can support tracking and recording every stage in the sales process for each prospective client, from initial contact to final disposition. In addition, CRM systems can support enterprise marketing, technical/customer support and service, event and meeting calendaring, and predictive analytics.
Typically, a CRM system can collect, store and analyze volumes of information depending on the various features supported. This information can be accessed by enterprise personnel across different groups, e.g., marketing, sales, technical support, and in some cases, by customers and external business partners. Accordingly, the CRM system can support and encourage collaboration between enterprise groups, and can help an enterprise to understand and to identify its customer needs, and effectively to build relationships between the enterprise, its customer base, and external partners.
While CRM systems are very powerful and have the potential to provide enormous benefits for an enterprise, using such a system can be challenging, if not prohibitive. In some cases, the CRM system's user interface can be counter intuitive to a user and/or far too complex to allow easy navigation to records the user is seeking. Moreover, the user may not be aware of the full capabilities of the CRM system and therefore, may not take full advantage of the features offered by the system. Accordingly, unless a user is adequately trained and/or possesses a familiarity with CRM or similar systems, it is unlikely that the CRM system will be used to its full potential, if at all.
In the following drawings like reference numbers are used to refer to like elements. Although the following figures depict various examples, the one or more implementations are not limited to the examples depicted in the figures.
Systems and methods are provided for providing and presenting recommended information from a CRM system in a cloud computing environment. According to exemplary embodiments, a CRM recommendation service is configured to search for and retrieve records from a CRM system that are timely and personally relevant to a user, and to provide those recommended records to a user system of the user so that they can be presented in real time to the user. In an embodiment, when the CRM recommendation service receives a request for recommended information from a requesting user system of the user, the CRM recommendation service is configured to also receive real-time user-specific information stored on the requesting user system. For example, the user-specific information can include information relating to the user's contacts and historical and real-time information relating to the user's business and/or personal interactions with those and other contacts. Additionally or alternatively, the user-specific information can include calendaring information that indicates the user's past, pending and future events, appointments, and/or meetings.
According to an embodiment, when the request and the user-specific information are received, the CRM recommendation service can be configured to identify accessible records that are related to the user-specific information, and managed by the CRM system. Once related accessible records have been identified, the CRM recommendation service can be configured to determine a relevance score for one or more of the identified accessible records based on one or more relevancy factors. In an embodiment, the relevance score of a record can reflect the importance or relevance of the record to the user. Accordingly, the relevance factors can be directed to how often and when the user interacts with a record, a relationship between a record and the user, when an event is taking place, and/or who is attending an event. Once relevance scores have been determined for at least some of the identified accessible records, the CRM recommendation service can be configured to identify one or more recommended records based on their respective relevance scores and to transmit information identifying the recommended records in a response message to the requesting user system.
Referring now to
According to an embodiment, each user system node 202, 400 can represent a virtual or physical computer device through which a user, e.g., user 203, can communicate, via the network 230, with contacts 201a, 201b, and with application servers, such as a social networking server 204 and the CRM server 220. In an embodiment illustrated in
In an embodiment, the CRM system 300 includes a data store 321 for storing a plurality of data objects including a plurality of contact records 322, a plurality of event records 324, and/or other records 320 (collectively CRM records 320). As used herein, a CRM record 320 can include, but is not limited to, a tuple corresponding to a user, a file, a folder, an opportunity, an account, an event, and/or any data object. The CRM system 300 can include a data manager component 308 that can be configured to insert, delete, and/or update the records 320, 322, 324 stored in the data store 321. In addition, the CRM system 300 can include a monitoring agent 330 that is configured to monitor activities related to the CRM records 320. For example, the monitoring agent 330 can be configured to track a user's post via a public or private social networking service 205, and/or a user's email client on the user's enterprise desktop computer, and to monitor updates to the contact records 322, event records 324, and/or any other CRM record(s) 320 stored in the data store 321.
In an embodiment, the data store 321 can be a database system located in a cloud computing environment, and may be implemented as a multi-tenant database system. As used herein, the term multi-tenant database system refers to those systems in which various elements of hardware and software of the database system may be shared by one or more customers. For example, a given application server 220 may simultaneously process requests for a great number of customers, and a given database table may store rows for multiple customers.
According to an embodiment, the execution environment 301, or an analog, provided by the CRM server node 220 can also include a CRM recommendation service 310. Alternatively, as is shown in
The network 230 can be a local area network (LAN) or a wide area network (WAN), such as the Internet. Each user system node 202, 400 may include an application that allows network communication between the user system 202, 400 and the CRM service 310 hosted by the application server 220. Such an application can be, in an embodiment, a web portal (not shown) provided by a network browser (e.g., Chrome, Internet Explorer, Safari, etc.) or the like that is capable of sending and receiving information to and from the application servers 204, 220.
In an embodiment, the real-time user-specific information 471 can comprise information collected and/or used by various client applications hosted by the requesting user system 400 and stored locally on the requesting user system 400. For example, real-time user-specific information 471 can include interaction information gathered from an email client, a telephone application, a social networking application, a web browser, and/or any number of messaging applications that allow the user 203 to interact with his contacts 201a, 201b or other entities, e.g., the social networking service 205. Accordingly, in an embodiment, the interaction information can include contact information associated with at least some of the user's contacts 201a, 201b, historical information relating to the user's business and personal interactions with the user's contacts 201a, 201b, messages posted to, sent to and received from the user's contacts 201a, 201b; telephone calls made to and received from the user's contacts 201a, 201b; and notifications associated with the user's contacts 201a, 201b received from one or more social networking services 205. In addition, the interaction information can also include information relating to the user's web browsing history, searches and/or downloads.
Alternatively or in addition, the real-time user-specific information 471 can include, in an embodiment, calendaring information gathered from one or more calendaring applications on the requesting user system 400. The calendaring information can include information relating to the user's past, pending, and future events, appointments, and meetings. In addition, the calendaring information can include reminders, task lists, and other information typically managed by a calendaring client on the requesting user system 400.
In another embodiment, the real-time user-specific information 471 can also include information collected from word processing and/or file system processing applications on the requesting user system 400. For example, such information 471 can include information relating to documents, files and/or objects recently opened, viewed, and/or modified by the user 203 on the requesting user system 400.
In addition or alternatively, the real-time user-specific information 471 can also include, in an embodiment, geo-location information associated with the requesting user system 400 gathered from a Global Positioning System (“GPS”) unit in the requesting user system 400. For example, the requesting user system 400 can be a handheld mobile device that includes a GPS unit that is configured to calculate the requesting user system's 400 location based on received satellite signals. The geo-location information can include, in an embodiment, latitude and longitude information associated with a location at a particular time. The geo-location information can also include correlated information related to the latitude and longitude information. For example, the correlated information can comprise an address, a business name and/or contact name associated with the address, and an identifier identifying the location. In an embodiment, the GPS unit in the requesting user system 400 can track and record the system's location periodically, e.g., every 10 minutes, and the geo-location information can include the current location of the system 400 when the message is sent, and previous recorded location(s) of the requesting user system 400.
According to an embodiment, the record handler component 312 in the CRM recommendation service 310 is configured to receive the message from the requesting user system 400 over the network 230 via a network subsystem 302 and an application protocol layer, or other higher protocol layer, as illustrated by an exemplary HTTP protocol layer 303, among many possible standard and proprietary protocol layers. These higher protocol layers can encode, package, and/or reformat data for sending and receiving messages over a network layer, such as Internet Protocol (IP), and/or a transport layer, such as Transmission Control Protocol (TCP) and/or User Datagram Protocol (UDP). A request handler component 306 in the CRM system 300 can be configured to receive the message via the incoming data handler 304 and to route the message to the CRM recommendation service 310 for further processing.
Referring again to
In an embodiment, when the message from the requesting user system 400 is received, the record handler component 312 can be configured to extract the user-specific information 471 from the message and to generate at least one search query for CRM records 320, 322, 324 relating to the user-specific information 471. In an embodiment, the record handler component 312 can include a query manager 313 configured to generate and to submit the one or more search queries to the data manager component 308 in the CRM system 300, which can be configured to retrieve and return CRM records 320, 322, 324 satisfying the one or more search queries.
For example, when the user-specific information 471 includes interaction information comprising contact information associated with a user's contact, e.g., 201a, the query manager 313 can be configured to generate a search query based on the contact information, e.g., name, email address, company name, etc., and to submit the query to the data manager component 308. In response, the data manager component 308 can retrieve from the data store 321 and return to the record handler component 312 a contact record 322 and/or other records 320, 324 satisfying the query. For instance, when the query is broad, e.g., “retrieve all records containing the contact's name,” the data manager 308 can retrieve a contact record 322 corresponding to contact information of the user's contact 201a, an event record 324 corresponding to a meeting to which the user's contact 201a is invited, another contact record 322 corresponding to messages posted to social networking websites by the user's contact 201a, and a record 320 corresponding to a document authored by the user's contact 201a.
In another example, when the user-specific information 471 includes calendaring information comprising information relating to a past, ongoing, or upcoming event, the query manager 313 can be configured to generate a search query based on the calendaring information, e.g., date and time, names of participants, subject of meeting, etc., and to submit the query to the data manager component 308. In an embodiment, the data manager 308 can retrieve CRM records 320 related to the calendaring information including an event record 324 corresponding to a meeting with a matching meeting subject and scheduled on a matching date and time, contact records 322 corresponding to the meeting participants, and records 320 corresponding to an account and/or an opportunity associated with the meeting, and files and/or documents presented during the meeting.
In another example, when the user-specific information 471 includes current and/or historic geo-location information associated with the requesting user system 400, the query manager 313 can be configured to generate a search query based on the geo-location information, e.g., date and time, geo-location coordinates, etc., and to submit the query to the data manager component 308. In an embodiment, the data manager 308 can retrieve CRM records 320 related to the geo-location information including contact records 322 corresponding to the user's contacts 201a, 201b located nearby, an event record 324 corresponding to an event occurring nearby, and records 320 corresponding to customers, vendors or services in the vicinity.
In an embodiment, when the plurality of CRM records 320 related to the real-time user-specific information are received, the record handler component 312 can be configured to determine which of the CRM records 320 the user 203 is authorized to access. For instance, in an embodiment, the record handler component 312 can apply a record access control policy 314 that defines a user's 203 access rights to each record 320 based on several control factors, such as record type, security level associated with the record 320, the user's 203 title, role, and/or department, and/or any other control factor. A record 320 that the user 203 is authorized to access is an accessible record 315. In an embodiment, when the record handler component 312 determines that the user 203 is unauthorized to access an identified CRM record 320, that record 320 is filtered out, i.e., eliminated from consideration, and can be discarded or returned to the data manager component 308.
According to an embodiment, when the record handler component 312 determines that the user 203 is authorized to access an accessible record 315, the record handler component 312 can be configured to determine, for each of the accessible records 315, a record identifier 331 identifying the accessible record 315. For example, the CRM system 300 typically provides and stores a record identifier 331 for and with each CRM record 320, and the record handler component 312 can be configured to extract the record identifier 331 from the CRM record 320 corresponding to the accessible record 315. In another embodiment, the record handler component 312 can be configured to generate a record identifier 331 and to associate the record identifier 331 with the accessible record 315.
In an embodiment, the record handler component 312 can be configured to transmit the extracted and/or generated record identifier(s) 331 of the accessible record(s) 315 to the requesting user system 400 of the user 203, so that the requesting user system 400 can easily track the accessible record(s) 315. For example, in an embodiment, the record handler component 312 can be configured to provide the record identifier(s) 331 of the accessible record(s) 315 to the outgoing data handler component 309 in the CRM system 300. The outgoing data handler 309 can be configured to build a message that includes at least one record identifier 331 of at least one accessible record 315, and to interoperate directly with the protocol layer of the network subsystem 302 or with an application protocol layer 303. The message including the record identifier(s) 331 can be transmitted as a whole or in parts via the network subsystem 302 over the network 230 to the requesting user system 400 associated with the user 203.
Alternatively or in addition, the record handler component 312 can be configured to associate the accessible record 315 with the user 203 so that, from that point forward, the record handler component 312 can be aware that the user 203 is interested in the accessible record 315. In an embodiment, for example, the record handler component 312 can be configured to store the record identifier(s) 331 of the accessible record(s) 315 as user information 330 associated with the user 203. According to an embodiment, the real-time user-specific information 471 can also be stored as user information 330.
Referring again to
According to an embodiment, the plurality of relevance factors 317 can be used to determine how, whether and to what extent an accessible record 315 is likely to be relevant to the user 203. For example, when the record 315 under consideration is a contact record 322 corresponding to a user's contact 201a, a relevance factor 317 can be directed to a frequency with which the user 203 has interactions with the contact 201a associated with the contact record 322, i.e., how many times has the user 203 called, emailed, and/or texted the contact 201a. Another relevance factor 317 can be directed to a temporal proximity of an interaction with the contact 201a, i.e., how recent was the last interaction between the user 203 and the contact 201a, and/or whether the user 203 subscribes to, i.e., follows, the contact's 201a posts to social networking entities 205.
In another example, when the accessible record 315 under consideration is an event record 324 corresponding to an upcoming meeting, a relevance factor 317 can be directed to a temporal proximity of the meeting, i.e., how many minutes until a start time of the meeting. In addition, when the record 315 under consideration is one corresponding to a document or file, a relevance factor 317 can be directed to whether the user 203 owns, created and/or follows the document. Alternatively, when the document or file is associated with a meeting, a relevance factor 317 can be directed to when the meeting is scheduled to begin. In some or all of the examples, a relevance factor 317 can be directed to a location proximity of the record under consideration, i.e., how close in distance the requesting user system 400 is to the location of the record 315.
Other relevance factors 317 can be defined and directed to a variety of subjects. For example, a non-exhaustive list of relevance factors 317 can be directed to:
whether the user has communicated recently with a record corresponding to a contact via the user's corporate social network
whether the user is discussing an object represented by the record in the user's corporate social network
whether a file or document represented by a record has been edited recently
a number of social interactions between the user and a contact associated with the record
how recently the user has viewed an object associated with a record
how recently the requesting user system has been near an object associated with a record
whether an object represented by a record is of a type with which the user typically interacts
In an embodiment, each relevance factor 317 can be weighted by a weighting factor to reflect its importance relative to the other relevance factors 317. For example, a relevance factor 317 directed to how recently the user 203 printed a document can be weighted heavier than a relevance factor 317 directed to how recently the user 203 opened the document on a presumption that a printed document is more important to the user 203 than one that is merely opened by the user 203. The weighting factor of a relevance factor 317 can be at least equal to one (1) and can be determined by an administrator or by default in an embodiment. Alternatively or in addition, the user 203 can provide the weighting factor of the relevance factor 317 to reflect the user's personal preferences.
In an embodiment, the relevancy score handler 316 can be configured to identify a subset of relevance factors 317 of the plurality of relevance factors 317 based on an attribute of an accessible record 315. For example, when the accessible record 315 corresponds to a file or document, a relevance factor 317 directed to whether the user 203 opened the document recently can be identified and included in the subset, while a relevance factor 317 directed to the frequency with which the user 203 emails the record can be excluded from the subset. When the subset is identified, the relevancy score handler 316 can be configured to disregard relevance factors 317 excluded from the subset, and to determine a raw score for the each of the relevance factors 317 in the subset.
Alternatively or in addition, the relevancy score handler 316 can be configured to identify another subset of relevance factors 317 of the plurality of relevance factors 317 based on a relevance type, such as socio-relevance and/or geo-relevance. As discussed above, relevance factors 317 can be used, in an embodiment, to determine how an accessible record 315 is relevant to the user 203. Accordingly, a first subset of relevance factors 317 directed to the geo-location of the user system 400 and/or of an accessible record 315 can be considered to determine a first raw score for the each of the relevance factors 317 in the first subset, and a second subset of relevance factors 317 directed to user interactions can be considered to determine a second raw score for each of the relevance factors 317 in the second subset. In an embodiment, the first raw scores can be used to determine the geo-relevance of the accessible record 315 to the user 203, and the second raw scores can be used to determine the socio-relevance of the accessible record 315 to the user 203.
In an embodiment, the relevancy score handler component 316 can be configured to analyze each accessible record 315 in light of at least one of the plurality of relevance factors 317, e.g., the relevance factors 317 in the subset. In an embodiment, a relevance factor 317 can be treated as a question relating to the accessible record 315, and a raw score for the relevance factor 317 can be determined based on an answer to the question. In an embodiment, the answer can be derived at least in part from the real-time user-specific information 471. For instance, a relevance factor 317 that is directed to a location proximity of a contact 201a associated with an accessible record 315 can be treated as the question, “How close is this contact 201a to me?” The relevancy score handler component 316 can be configured to answer this question based at least in part on the real-time user-specific information 471 that indicates the current geo-location of the requesting user system 400 and the location information associated with the contact 201a included in the accessible record 315.
As stated above, the raw score for the relevance factor 317 can be determined based on the answer to the question. In an embodiment, the raw score for a relevance factor 317 can be a value between a minimum value, e.g., zero (0), and a maximum value, e.g., ten (10). The minimum value can indicate a low level of relevancy and the maximum value can indicate a high level of relevancy between the user 203 and the record 315 according to this particular relevance factor 317. Accordingly, referring to previous example, when the number of interactions between the user 203 and the contact 201a during the preceding seven (7) days is zero, the determined raw score can be the minimum value, indicating that the contact 201a is not relevant to the user 203 based on the frequency with which the user 203 interacts with the contact 201a. Alternatively, when the number of interactions is high, e.g., above a threshold set by the user 203 or by default, the determined raw score can be the maximum value, indicating that the contact 201a is relevant to the user 203 based on this relevance factor 317. In an embodiment when the relevance factor 317 is weighted by a weighting factor, e.g., defined by an administrator and/or by the user 203, the determined raw score can be multiplied by the weighting factor to generate a weighted raw score for the relevance factor 317
According to an embodiment, once the raw score and/or the weighted raw score for each relevance factor 317 considered is determined, the relevancy score handler 316 can be configured to determine the relevance score 332 for the accessible record 315 by accumulating the raw and/or weighted raw scores to generate a sum of the raw and/or weighted raw scores. In an embodiment, the sum of the raw and/or weighted raw scores is the relevance score 332 for the accessible record 315 and indicates the relevance of the accessible record 315 to the user 203.
According to an embodiment, the relevancy score handler 316 can be configured to determine more than one relevance score 332 for the accessible record 315. For example, in an embodiment, an overall relevance score 332 can be determined based on the sum of the raw and/or weighted raw scores for each of the plurality of relevance factors 317. Alternatively or in addition, a specialized relevance score 332 can be determined based the sum of the raw scores for a subset of relevance factors 317. For example, as described above, a first subset of relevance factors 317 can be directed to the geo-location of the user system 400 and/or of an accessible record 315. In this case, a geo-relevance score 332 can be determined based on the sum of the raw and/or weighted scores for the relevance factors 317 in the first subset. Alternatively, a second subset of relevant factors 317 can be directed to user interactions, and a socio-relevance score 332 can be determined based on the sum of the raw and/or weighted raw scores for the relevance factors 317 in the second subset. In an embodiment, the geo-relevance score 332 and the socio-relevance score 332 indicate the geo-relevance and the socio-relevance, respectively, of the accessible record 315 to the user 203. The relevance score handler component 316 can be configured, in an embodiment, to store the relevance scores 332, e.g., the overall relevance score and/or the specialized relevance scores, for the accessible records 315 as user information 330.
Referring again to
According to an embodiment, the relevancy score handler component 316 can be configured, in an embodiment, to select a recommended record 318 by identifying an accessible record 315 having a relevance score 332 greater than a predetermined relevancy threshold value. The relevancy threshold value can be a default value set by an administrator in an embodiment. Alternatively or in addition, the relevancy threshold value can be a value defined by the user 203 and stored as a user preference 333 with the user information 330 in another embodiment. In an embodiment, more than one relevancy threshold value can be applied. For example, the relevancy score handler component 316 can be configured to apply the default threshold value on a first pass over the accessible records 315 and depending on how many accessible records 315 are identified, can apply the user defined threshold value to filter accessible records 315 from or add accessible records 315 to the group of identified records 318.
In another embodiment, the relevancy score handler component 316 can be configured to select at least one recommended record 318 from the accessible records 315 by generating a sorted list comprising the accessible records 315 sorted by their respective relevance scores 332. In an embodiment, the accessible records 315 can be sorted in an order from highest score 332 to lowest score 332, i.e., most relevant to least relevant. Once the sorted list is generated, the relevancy score handler component 316 can be configured to select a predetermined number of accessible records 315 from the sorted list, e.g., the top five (5) records, to be the at least one recommended record 318. In an embodiment, the predetermined number can be a default value set by the administrator or a value defined by the user 203 and stored as a user preference 333 with the user information 330.
In another embodiment, the relevancy score handler component 316 can be configured to select at least one recommended record 318 from the accessible records 315 based on both the predetermined number and the relevancy threshold value. For example, the relevancy score handler component 316 can generate the list of accessible records 315 sorted by relevance score 332 and can identify the top ten (10) accessible records 315 from the list. The relevancy score handler component 316 can then select the recommended records 318 by selecting from the identified top ten (10) records 315 accessible records that have relevance scores 332 exceeding the relevance threshold value.
According to an embodiment, the relevancy score handler component 316 can also generate a list of accessible records 315 sorted by their geo-relevance score 332 and/or a list of accessible records 315 sorted by their socio-relevance score 332. From either or both of these lists, the relevancy score handler component 316 can select recommended records 318 based on their geo-relevance or socio-relevance to the user 203, as well as based on their overall relevance to the user 203.
Referring again to
As stated above, in an embodiment, when the accessible records 315 are determined from the plurality of identified records 320, the record identifiers 331 identifying the accessible records 315 can be stored as user information 330 in the CRM recommendation service 310. According to an embodiment, when a recommended record(s) 318 is selected, the list handler component 319 can be configured to receive the recommended record(s) 318 from the relevancy score handler component 316 and to retrieve the record identifier(s) 331 identifying the recommended record(s) 318.
According to an embodiment, the list handler component 319 can be configured to generate a ranked list 335 comprising the record identifiers 331 identifying the recommended records 318. In an embodiment, the ranked list 335 can rank the record identifiers 331 by the relevancy scores 332 of the recommended records 318 in an order from highest score 332 to lowest score 332, i.e., most relevant to least relevant. Additionally, the ranked list 335 can include the relevance scores 332 along with the associated record identifiers 331 identifying the recommended records 318.
As described above, the recommended records 318 can be selected based on their particular relevancy, e.g., geo-relevance or socio-relevance, to the user 203. In an embodiment, the list handler component 319 can be configured to generate at least one specialized ranked list 335 based on a relevance type. For example, the list handler component 319 can be configured to generate a geo-relevance ranked list 335 and/or a socio-relevance ranked list 335 comprising records identifier 331 identifying the geo-relevant and/or socio-relevant recommended records 318, respectively.
The list handler component 319 can be configured, in an embodiment, to build the response message 334 and to include the information identifying the recommended records 318, e.g., the identifiers 331 and/or the ranked list(s) 335, and to provide the response message 334 to the outgoing data handler 309 in the CRM system 300. In an embodiment, the outgoing data handler 309 can be configured to interoperate directly with the protocol layer of the network subsystem 302 or with the application protocol layer 303. The message 334 including the identifying information, e.g., the ranked list(s) 335, can be transmitted as a whole or in parts via the network subsystem 302 over the network 230 to the requesting user system 400 associated with the user 203.
In an embodiment illustrated in
In an embodiment, each component 410a-410c or application 412a-412d can be configured to track user-specific information associated with the component 410a-410c or application 412a-412d, and to store the information in a storage block (not shown) associated with the component 410a-410c or application 412a-412d. For example, a typical telephone client application 412a can track calls made and received by the user system 400, and information identifying callers, i.e., contacts 201a, 201b. This user-specific information can be stored in a call log (not shown) associated with the telephone client 412a. A typical email client application 412b can track messages sent and received by the user system 400, and information identifying recipients and senders, and can store this user-specific information in at least one folder or message log (not shown) associated with the email client 412b. Similarly, the social networking client application 412c can track the social networking activity of contacts 201a, 201b the user 203 is following, and can store the activity in an social networking activity log (not shown) associated with the social networking client 412c. Similarly, the calendaring component 410b can track scheduled events 422 and event details, and the geo-location component 410c can track the location of the user system 400 over time and location searches received, and each component can store this user-specific information in one or more storage blocks associated with the calendaring component 410b and/or the geo-location component 410c.
In an embodiment, the user system 400 can also include a display component 430 configured for displaying content to the user 203 on a user interface 432. In addition, the user system 400 can include incoming 409 and outgoing 408 data handler components for receiving and transmitting information from and to other user system nodes 202, servers 204, and the CRM server 220 via the network 230.
According to an embodiment, the execution environment 402 provided by the user system 400 includes a recommendation component 450.
Referring to
The indication can be received in a number of ways. For example, it can be received via explicit input by the user 203 using an input device such as a keyboard or touch screen, via audio input, and/or via a scanning or imaging device. In another embodiment, the recommendation component 450 can receive the indication to request recommended records from a trigger (not shown) in the user system 400 that is configured to invoke the recommendation component 450 when certain triggering events are detected. For example, in an embodiment, a triggering event can be the activation of the user system 400, and/or opening or closing an application 412. Alternatively or in addition, the triggering event can be based on a specified time and/or a specified time period.
According to an embodiment, when the indication to request recommended records is received by the recommendation component 450 for a first time, the recommendation component 450 can execute a configuration routine to request and receive user preferences 478 from the user 203. In an embodiment, the configuration routine can include requesting and receiving user preferences 478 identifying from which components 410a-410c or applications 412a-412d the recommendation component 450 has permission to collect user-specific information. The recommendation component 450 can, in an embodiment, scan the user system 400 to identify the components 410a-410c or applications 412a-412d supporting user-specific functions. For each identified component, e.g., the calendaring component 410b, and application, e.g., the telephone client application 412a, the recommendation component 450 can request permission from the user 203 to collect user-specific information 471 associated with the identified component 410b and/or application 412a. In an embodiment, the recommendation component 450 can be configured to display to the user 203 via the user interface 432 the identified component 410b and/or application 412a, and can be configured to receive an indication from the user 203 granting or denying permission to collect user-specific information 471 from the component 410b and/or application 412a.
Accordingly, for example, the user 203 can grant permission to the recommendation component 450 to collect user-specific information 471 from the telephone client 412a, the email client 412b, and the calendaring component 410b, and can prevent the recommendation component 450 from collecting user-specific information from the social networking client 412c, the web browser 412d, and the geo-location component 410c. In another embodiment, the permission control feature can be disabled and the recommendation component 450 can be permitted to collect information from all identified components 410a-410c or applications 412a-412d supporting user-specific functions without exception.
According to another embodiment, the configuration routine can include receiving user preferences 478 relating to transmission parameters 478a for the user-specific information associated with the components 410a-410c or applications 412a-412d. In an embodiment, the transmission parameters 478a can define how much and/or what types of user-specific information 471 is transmitted to the CRM server 220. For example, in an embodiment, the transmission parameters 478a can define how many recent emails, telephone calls, posts, and web pages collected from the interaction components 410a to transmit to the CRM server 220. In addition, the transmission parameters 478a can indicate a time period from which calendaring information, e.g., scheduled events 422 and event details, are transmitted to the CRM server 220.
Moreover, in an embodiment, the transmission parameters 478a can indicate which types of interaction information 472, calendaring information 474, and/or geo-location information 476 to transmit to the CRM server 220. For example, the user 203 can indicate that interaction information 472 relating only to professional or business contacts, calendaring information 474 relating only to business and/or work events, and/or geo-location information 476 relating to locations in a certain region, can be transmitted to the CRM server 220.
In addition or alternatively, the configuration routine can include receiving user preferences 478 relating to display parameters 478b for displaying information relating to recommended CRM records. In an embodiment, the display parameters 478b can define how much and/or what type of information to display on the user interface 432 of the user system 400. In an embodiment, when the user preferences 478, e.g., the transmission parameters 478a and the display parameters 478b, are received, the recommendation component 450 can be configured to store the user preferences 478 in a local data store 470 associated with the recommendation component 450.
In addition, in an embodiment, the configuration routine can include receiving CRM user preferences 333 from the user 203 that can determine how many and which types of recommended records 318 to retrieve from the CRM system 300. For example, the user 203 can define weighting factors of relevance factors 317 to reflect the relative importance of some relevance factors 317 to others, can define a threshold value, e.g., the relevancy threshold value, for selecting recommended records 318 from the accessible records 315, and/or can define the number of records selected from the sorted list of accessible records 315. In an embodiment, the CRM user preferences 333 can be transmitted to the CRM server 220, where they are stored as user information 330 associated with the user 203 by the CRM recommendation service 310.
Referring again to
According to an embodiment, when the indication to request recommended records is received and transmitted to the recommendation component 450, the recommendation component 450 can be configured to invoke the information collection handler component 460. Once invoked, the information collection handler component 460 can be configured to access the storage blocks associated with the components 410a-410c or applications 412a-412d supporting user-specific functions, assuming it is permitted to, and to collect real-time user-specific information associated with the components 410a-410c or applications 412a-412d. As stated above, the real-time user-specific information 471 collected can include interaction information 472 from the interaction components 410a, calendaring information 474 from the calendaring component 410b, and/or geo-location information 476 from the geo-location component 410c. The user-specific information 471 can also include other types of information from other components 410 or applications 412, such as word processing and/or file system processing applications (not shown), and is not limited to that described above.
In an embodiment, when the information collection handler component 460 is invoked for the first time, the information collection handler component 460 can be configured to collect the user-specific information, e.g., interaction information 472, from a component, e.g., the interaction components 410a, and to store a copy of the information 472 in the local data store 470. Thereafter, when the information collection handler component 460 is invoked and collects the user-specific information from the components 410 and applications 412, the information collection handler component 460 can be configured to compare the existing user-specific information 471 stored in the data store 470 to the newly collected user-specific information to determine new user-specific information, e.g., new messages and new contacts, collected for a first time. In an embodiment, the new user-specific information can be added to the existing user-specific information 471 stored in the data store 470.
Referring again to
According to an embodiment, the information handler component 460 can be configured to build the message 462 and to determine at least a portion of the real-time user-specific information 471 collected from the user system's components 410 and applications 412 to include in the message 462. In an embodiment when new user-specific information, e.g., new messages and new contacts, is collected, the information handler component 460 can be configured to include at least a portion of the new real-time user-specific information 471 in the message 462. In addition or alternatively, in an embodiment, the information handler component 460 can be configured to determine what user-specific information 471 is included based on the user preferences 478 submitted by the user 203 during the configuration routine.
For example, the information handler component 460 can, in an embodiment, apply the transmission parameters 478a to filter the real-time user-specific information 471 in order to determine what user-specific information 471 is included in the message 462. As stated above, the transmission parameters 478a can define how much and/or what types of user-specific information 471 is transmitted to the CRM server 220. For example, in an embodiment, the transmission parameters 478a can define how many recent emails, telephone calls, posts, and web pages collected from the interaction components 410a to transmit to the CRM server 220. In addition, the transmission parameters 478a can indicate which types of interaction information 472, calendaring information 474, and/or geo-location information 476 to transmit to the CRM server 220. The information handler component 460 can be configured to apply the transmission parameters 478a to the newly collected and/or existing stored user-specific information 471 to identify information satisfying at least one of the transmission parameters 478a, and to include that information in the message 462.
Once the message 462 is built, the information handler component 460 can be configured, in an embodiment, to provide the message 462 to the outgoing data handler 408 in the user system 400. In an embodiment, the outgoing data handler 408 can be configured to interoperate directly with a protocol layer of a network subsystem 404 or with an application protocol layer 406. The message 462 including the request and user-specific information 471 can be transmitted as a whole or in parts via the network subsystem 404 over the network 230 to the CRM server 220 hosting CRM system 300.
As described above, when the message 462 is transmitted to the CRM server 220, the record handler component 312 in the CRM recommendation service 310 can be configured to receive the message 462, and to identify accessible CRM records 315 related to the real-time user-specific information 471 in the message 462. For example, when the user-specific information 471 includes interaction information 472, the accessible record 315 related to the interaction information 472 can be a contact record 322 corresponding to a contact 201a of the user 203. In addition, when the user-specific information 471 includes calendaring information 474, the accessible record 315 related to the calendaring information 474 can be an event record 324 corresponding to an event 422. As described above, when an accessible record 315 is determined, the record handler component 312 can retrieve a record identifier 331 identifying the contact record 322 or the event record 324, and transmit it to the user system 400 in a message.
According to an embodiment, the information collection handler component 460 in the recommendation component 450 hosted by user system 400 can receive the message including the record identifier 331 identifying the contact record 322 or the event record 324 via the incoming data handler component 409. In an embodiment, the information collection handler component 460 can be configured to associate the record identifier 331 with the corresponding contact 201a in the interaction information 472 or the corresponding event 422 in the calendaring information 474. By associating the record identifier 331 with the corresponding contact 201a or event 422, the recommendation component 450 can determine which contacts e.g., 201a, or events 422 are managed by the CRM system 300 and which contacts, e.g., 201b, or events 422 are not. Accordingly, for future requests, the user-specific information 471 associated with a record identifier 331 can be included in the message 462 and user-specific information not associated with a record identifier 331 can be excluded because the CRM system 300 is not managing CRM records 320 corresponding to that information.
According to an embodiment, when the CRM recommendation service 310 identifies at least one recommended record 318 in a manner described earlier, a response message 334 including information identifying the recommended records 318 is transmitted to the requesting user system 400. Referring again to
According to an embodiment, the response message 334 can include one or more ranked lists 335 comprising record identifiers 331 identifying the recommended records 318 and optionally their respective relevance scores 332. When the response message 334 is received, the display handler component 480 can be configured to extract the list(s) 335 and the information identifying the recommended records 318 and to determine, in an embodiment, what portion of the information to display to the user 203 on the user interface 432.
For example, according to an embodiment, the display handler component 480 can apply the display parameters 478b to filter the information included in the response message 334 in order to determine what information is displayed to the user 203. As stated above, the display parameters 478b can define how much and/or what type of information to display on the user interface 432 of the user system 400. For example, in an embodiment, the display parameters 478b can define how many recommended records 318 to display depending on the ranked list 335 on which the recommended records 318 are listed. In addition, the display parameters 478b can indicate which types of interaction information 472, calendaring information 474, and/or geo-location information 476 relating to the recommended records 318 to display. The display handler component 480 can be configured to apply the display parameters 478b to the information included in the response message 334 to identify information satisfying at least one of the display parameters 478b. Once identified, the information can be provided to the display component 430, which can be configured to render the information for display on the user interface 432.
According to an embodiment, the display component 430 can be configured to render the information in a number of formats suiting the information. For example, in
In another embodiment, illustrated in
According to an embodiment, the user 203 can toggle between the list view 500b shown in
Environment 610 is an environment in which an on-demand database service exists. User system 612 may be any machine or system that is used by a user to access a database user system. For example, any of user systems 612 can be a handheld computing device, a mobile phone, a laptop computer, a work station, and/or a network of computing devices. As illustrated in
An on-demand database service, such as system 616, is a database system that is made available to outside users that do not need to necessarily be concerned with building and/or maintaining the database system, but instead may be available for their use when the users need the database system (e.g., on the demand of the users). Some on-demand database services may store information from one or more tenants stored into tables of a common database image to form a multi-tenant database system (MTS). Accordingly, “on-demand database service 616” and “system 616” will be used interchangeably herein. A database image may include one or more database objects. A relational database management system (RDMS) or the equivalent may execute storage and retrieval of information against the database object(s). Application platform 618 may be a framework that allows the applications of system 616 to run, such as the hardware and/or software, e.g., the operating system. In an embodiment, on-demand database service 616 may include an application platform 618 that enables creation, managing and executing one or more applications developed by the provider of the on-demand database service, users accessing the on-demand database service via user systems 612, or third party application developers accessing the on-demand database service via user systems 612.
The users of user systems 612 may differ in their respective capacities, and the capacity of a particular user system 612 might be entirely determined by permissions (permission levels) for the current user. For example, where a salesperson is using a particular user system 612 to interact with system 616, that user system has the capacities allotted to that salesperson. However, while an administrator is using that user system to interact with system 616, that user system has the capacities allotted to that administrator. In systems with a hierarchical role model, users at one permission level may have access to applications, data, and database information accessible by a lower permission level user, but may not have access to certain applications, database information, and data accessible by a user at a higher permission level. Thus, different users will have different capabilities with regard to accessing and modifying application and database information, depending on a user's security or permission level.
Network 614 is any network or combination of networks of devices that communicate with one another. For example, network 614 can be any one or any combination of a LAN (local area network), WAN (wide area network), telephone network, wireless network, point-to-point network, star network, token ring network, hub network, or other appropriate configuration. As the most common type of computer network in current use is a TCP/IP (Transfer Control Protocol and Internet Protocol) network, such as the global internetwork of networks often referred to as the “Internet” with a capital “I,” that network will be used in many of the examples herein. However, it should be understood that the networks that the one or more implementations might use are not so limited, although TCP/IP is a frequently implemented protocol.
User systems 612 might communicate with system 616 using TCP/IP and, at a higher network level, use other common Internet protocols to communicate, such as HTTP, FTP, AFS, WAP, etc. In an example where HTTP is used, user system 612 might include an HTTP client commonly referred to as a “browser” for sending and receiving HTTP messages to and from an HTTP server at system 616. Such an HTTP server might be implemented as the sole network interface between system 616 and network 614, but other techniques might be used as well or instead. In some implementations, the interface between system 616 and network 614 includes load sharing functionality, such as round-robin HTTP request distributors to balance loads and distribute incoming HTTP requests evenly over a plurality of servers. At least as for the users that are accessing that server, each of the plurality of servers has access to the MTS' data; however, other alternative configurations may be used instead.
In one embodiment, system 616, shown in
One arrangement for elements of system 616 is shown in
Several elements in the system shown in
According to one embodiment, each user system 612 and all of its components are operator configurable using applications, such as a browser, including computer code run using a central processing unit such as an Intel Pentium® processor or the like. Similarly, system 616 (and additional instances of an MTS, where more than one is present) and all of their components might be operator configurable using application(s) including computer code to run using a central processing unit such as processor system 617, which may include an Intel Pentium® processor or the like, and/or multiple processor units. A computer program product embodiment includes a machine-readable storage medium (media) having instructions stored thereon/in which can be used to program a computer to perform any of the processes of the embodiments described herein. Computer code for operating and configuring system 616 to intercommunicate and to process webpages, applications and other data and media content as described herein are preferably downloaded and stored on a hard disk, but the entire program code, or portions thereof, may also be stored in any other volatile or non-volatile memory medium or device as is well known, such as a ROM or RAM, or provided on any media capable of storing program code, such as any type of rotating media including floppy disks, optical discs, digital versatile disk (DVD), compact disk (CD), microdrive, and magneto-optical disks, and magnetic or optical cards, nanosystems (including molecular memory ICs), or any type of media or device suitable for storing instructions and/or data. Additionally, the entire program code, or portions thereof, may be transmitted and downloaded from a software source over a transmission medium, e.g., over the Internet, or from another server, as is well known, or transmitted over any other conventional network connection as is well known (e.g., extranet, VPN, LAN, etc.) using any communication medium and protocols (e.g., TCP/IP, HTTP, HTTPS, Ethernet, etc.) as are well known. It will also be appreciated that computer code for implementing embodiments can be implemented in any programming language that can be executed on a client system and/or server or server system such as, for example, C, C++, HTML, any other markup language, Java™, JavaScript, ActiveX, any other scripting language, such as VBScript, and many other programming languages as are well known may be used. (Java™ is a trademark of Sun Microsystems, Inc.).
According to one embodiment, each system 616 is configured to provide webpages, forms, applications, data and media content to user (client) systems 612 to support the access by user systems 612 as tenants of system 616. As such, system 616 provides security mechanisms to keep each tenant's data separate unless the data is shared. If more than one MTS is used, they may be located in close proximity to one another (e.g., in a server farm located in a single building or campus), or they may be distributed at locations remote from one another (e.g., one or more servers located in city A and one or more servers located in city B). As used herein, each MTS could include one or more logically and/or physically connected servers distributed locally or across one or more geographic locations. Additionally, the term “server” is meant to include a computer system, including processing hardware and process space(s), and an associated storage system and database application (e.g., OODBMS or RDBMS) as is well known in the art. It should also be understood that “server system” and “server” are often used interchangeably herein. Similarly, the database object described herein can be implemented as single databases, a distributed database, a collection of distributed databases, a database with redundant online or offline backups or other redundancies, etc., and might include a distributed database or storage network and associated processing intelligence.
User system 612, network 614, system 616, tenant data storage 622, and system data storage 624 were discussed above in
Application platform 618 includes an application setup mechanism 738 that supports application developers' creation and management of applications, which may be saved as metadata into tenant data storage 622 by save routines 736 for execution by subscribers as one or more tenant process spaces 704 managed by tenant management process 710 for example. Invocations to such applications may be coded using PL/SOQL 734 that provides a programming language style interface extension to API 732. A detailed description of some PL/SOQL language implementations is discussed in commonly assigned U.S. Pat. No. 7,730,478, titled METHOD AND SYSTEM FOR ALLOWING ACCESS TO DEVELOPED APPLICATIONS VIA A MULTI-TENANT ON-DEMAND DATABASE SERVICE, by Craig Weissman, filed Sep. 21, 2007, which is hereby incorporated by reference in its entirety and for all purposes. Invocations to applications may be detected by one or more system processes, which manages retrieving application metadata 716 for the subscriber making the invocation and executing the metadata as an application in a virtual machine.
Each application server 7001-700N may be communicably coupled to database systems, e.g., having access to system data 625 and tenant data 623, via a different network connection. For example, one application server 7001 might be coupled via the network 614 (e.g., the Internet), another application server 700N-1 might be coupled via a direct network link, and another application server 700N might be coupled by yet a different network connection. Transfer Control Protocol and Internet Protocol (TCP/IP) are typical protocols for communicating between application servers 7001-700N and the database system. However, it will be apparent to one skilled in the art that other transport protocols may be used to optimize the system depending on the network interconnect used.
In certain embodiments, each application server 7001-700N is configured to handle requests for any user associated with any organization that is a tenant. Because it is desirable to be able to add and remove application servers from the server pool at any time for any reason, there is preferably no server affinity for a user and/or organization to a specific application server 7001-700N. In one embodiment, therefore, an interface system implementing a load balancing function (e.g., an F5 Big-IP load balancer) is communicably coupled between the application servers 7001-700N and the user systems 612 to distribute requests to the application servers 7001-700N. In one embodiment, the load balancer uses a least connections algorithm to route user requests to the application servers 7001-700N. Other examples of load balancing algorithms, such as round robin and observed response time, also can be used. For example, in certain embodiments, three consecutive requests from the same user could hit three different application servers 7001-700N, and three requests from different users could hit the same application server 7001-700N. In this manner, system 616 is multi-tenant, wherein system 616 handles storage of, and access to, different objects, data and applications across disparate users and organizations.
As an example of storage, one tenant might be a company that employs a sales force where each salesperson uses system 616 to manage their sales process. Thus, a user might maintain contact data, leads data, customer follow-up data, performance data, goals and progress data, etc., all applicable to that user's personal sales process (e.g., in tenant data storage 622). In an example of a MTS arrangement, since all of the data and the applications to access, view, modify, report, transmit, calculate, etc., can be maintained and accessed by a user system having nothing more than network access, the user can manage his or her sales efforts and cycles from any of many different user systems. For example, if a salesperson is visiting a customer and the customer has Internet access in their lobby, the salesperson can obtain critical updates as to that customer while waiting for the customer to arrive in the lobby.
While each user's data might be separate from other users' data regardless of the employers of each user, some data might be organization-wide data shared or accessible by a plurality of users or all of the users for a given organization that is a tenant. Thus, there might be some data structures managed by system 616 that are allocated at the tenant level while other data structures might be managed at the user level. Because an MTS might support multiple tenants including possible competitors, the MTS should have security protocols that keep data, applications, and application use separate. Also, because many tenants may opt for access to an MTS rather than maintain their own system, redundancy, up-time, and backup are additional functions that may be implemented in the MTS. In addition to user-specific data and tenant specific data, system 616 might also maintain system level data usable by multiple tenants or other data. Such system level data might include industry reports, news, postings, and the like that are sharable among tenants.
In certain embodiments, user systems 612 (which may be client systems) communicate with application servers 7001-700N to request and update system-level and tenant-level data from system 616 that may require sending one or more queries to tenant data storage 622 and/or system data storage 624. System 616 (e.g., an application server 7001 in system 616) automatically generates one or more SQL statements (e.g., one or more SQL queries) that are designed to access the desired information. System data storage 624 may generate query plans to access the requested data from the database.
Each database can generally be viewed as a collection of objects, such as a set of logical tables, containing data fitted into predefined categories. A “table” is one representation of a data object, and may be used herein to simplify the conceptual description of objects and custom objects. It should be understood that “table” and “object” may be used interchangeably herein. Each table generally contains one or more data categories logically arranged as columns or fields in a viewable schema. Each row or record of a table contains an instance of data for each category defined by the fields. For example, a CRM database may include a table that describes a customer with fields for basic contact information such as name, address, phone number, fax number, etc. Another table might describe a purchase order, including fields for information such as customer, product, sale price, date, etc. In some multi-tenant database systems, standard entity tables might be provided for use by all tenants. For CRM database applications, such standard entities might include tables for Account, Contact, Lead, and Opportunity data, each containing pre-defined fields. It should be understood that the word “entity” may also be used interchangeably herein with “object” and “table”.
In some multi-tenant database systems, tenants may be allowed to create and store custom objects, or they may be allowed to customize standard entities or objects, for example by creating custom fields for standard objects, including custom index fields. U.S. Pat. No. 7,779,039, titled CUSTOM ENTITIES AND FIELDS IN A MULTI-TENANT DATABASE SYSTEM, by Weissman, et al., and which is hereby incorporated by reference in its entirety and for all purposes, teaches systems and methods for creating custom objects as well as customizing standard objects in a multi-tenant database system. In certain embodiments, for example, all custom entity data rows are stored in a single multi-tenant physical table, which may contain multiple logical tables per organization. It is transparent to customers that their multiple “tables” are in fact stored in one large table or that their data may be stored in the same table as the data of other customers.
While one or more implementations and techniques have been described with reference to an embodiment in which techniques for providing machine status information in a system having an application server providing a front end for an on-demand database service capable of supporting multiple tenants, the one or more implementations and techniques are not limited to multi-tenant databases nor deployment on application servers. Embodiments may be practiced using other database architectures, i.e., ORACLE®, DB2® by IBM and the like without departing from the scope of the embodiments claimed.
Any of the above embodiments may be used alone or together with one another in any combination. The one or more implementations encompassed within this specification may also include embodiments that are only partially mentioned or alluded to or are not mentioned or alluded to at all. Although various embodiments may have been motivated by various deficiencies with the prior art, which may be discussed or alluded to in one or more places in the specification, the embodiments do not necessarily address any of these deficiencies. In other words, different embodiments may address different deficiencies that may be discussed in the specification. Some embodiments may only partially address some deficiencies or just one deficiency that may be discussed in the specification, and some embodiments may not address any of these deficiencies.
While one or more implementations have been described by way of example and in terms of the specific embodiments, it is to be understood that one or more implementations are not limited to the disclosed embodiments. To the contrary, it is intended to cover various modifications and similar arrangements as would be apparent to those skilled in the art. Therefore, the scope of the appended claims should be accorded the broadest interpretation so as to encompass all such modifications and similar arrangements.
This application claims the benefit of U.S. Provisional Patent Application 61/506,987, entitled CRM on a Mobile Platform, filed Jul. 12, 2011 (Attorney Docket No. 681PROV), the entire contents of which are incorporated herein by reference.
| Number | Date | Country | |
|---|---|---|---|
| 61506987 | Jul 2011 | US |
