Automatically manage email communications using indirect reply identity verification

Abstract

To provide methods and systems for automatically managing email communication between a group of users and a group of target prospects.SOLUTION: Based upon a prospect's inbound replies (or lack thereof), a system will perform pre-configured actions, such as stopping automated communications and following a user for manual action.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] The present invention relates to email communications. [Background technology]

[0002] The present disclosure relates to a method and system for automatically managing email communications between a group of users and a group of target prospects. Email is ubiquitous and its applications pertain to many fields, but for purposes of brevity, the specific examples in this document will be limited to the sales industry.

[0003] Managing email relationships with large numbers of people (prospects) is central to a sales professional's role. Often, a single person may be working with hundreds of prospects at the same time. To be effective, each individual thread of communication must be maintained and followed up on. Furthermore, a response (or lack of response) from a prospect requires action by the sales professional. This can include, but is not limited to, updating data in a customer relationship management system or setting up future follow-up activities. Traditionally, these actions are performed manually and require significant effort on the part of the salesperson. If a prospect does not respond, future actions of follow-up can be forgotten or overlooked, resulting in reduced effectiveness and excessive labor costs.

[0004] In the context of a sales organization involving many sales personnel, coordinating communication across the team becomes increasingly important. When a sales professional within an organization is working with an individual, it is desirable to know if anyone else in the organization is working with the same individual to drive the strategy of the sales process. When multiple sales personnel are working with the same individual at the same time, it is important to ensure that their efforts are mutually known and coordinated.

[0005] Standard email servers and clients do not provide the functionality to synchronize multiple inboxes simultaneously, nor do they provide the ability to automate actions or consume information based on data provided by all inboxes within an organization.

[0006] Therefore, what is needed is a system that automates the initial communication, leaves emails belonging to all email mailboxes within an organization, and stores and processes data in a manner that allows for automation and efficient display of the data. Summary of the Invention [Means for solving the problem]

[0007] Included herein is a method and system for automatically managing email communications between a group of users and a group of targeted prospects. The system provides a user interface for managing the complexities of dealing with multiple inboxes and recipients simultaneously, as well as customizable automation based on email content, recipients, and other metadata.

[0008] In one embodiment, an automated system is implemented to allow users to send a series of automated or manual emails (or "sequences") to specific recipients. These sequences are structured as several "steps" consisting of templated email content. The templates contain variables that are automatically filled in from an underlying database containing additional information about the intended recipients.

[0009] The basis for this is a system that maintains connections to email mailboxes on behalf of many users. These mailboxes are continually queried periodically for new email messages. For new messages, the message is checked for its relationship to a particular sequence. The system may include logic to stop delivery of a sequence conditional on certain receiver behavior, such as replying to the message. [Brief explanation of the drawings]

[0010] [Figure 1] 1 is a schematic diagram showing a high level overview of an email communication system in accordance with the present invention; [Figure 1a] FIG. 1 is a schematic diagram showing an overview of an email synchronization subsystem. [Figure 1b] 1 is a schematic diagram showing the internal workings of various subsystems in accordance with the present invention; [Figure 2] 1 is a flowchart illustrating how an embodiment of a system according to the present invention processes email to determine next steps and actions to be taken. [Figure 3] 3 is a table illustrating how an embodiment of a system according to the present invention classifies incoming emails. [Figure 4] FIG. 1 illustrates a shared inbox view of a specific known prospect, pulling email data from multiple mailboxes. [Figure 5] FIG. 1 illustrates a trigger system that performs actions based on email activity events. [Figure 6] 1 is a flowchart illustrating how an embodiment of the system captures data to create a new identity or adjust an existing identity. [Figure 7] 1 is a flowchart illustrating a step-by-step email sequence for a given lead and how a single reply from the lead completes the sequence. [Figure 8] 1 is a flow chart illustrating a templating system that is preferably incorporated into an email sequence. [Figure 9] 10 is a chart illustrating an example of a distribution schedule block. DETAILED DESCRIPTION OF THE INVENTION

[0011] Systems and methods embodying embodiments of various features of the present invention will now be described with reference to the drawings. The drawings and associated description are provided to illustrate some embodiments of the invention and not to limit the scope of the invention. Throughout the drawings, reference numbers are reused to indicate correspondence between referenced elements.

[0012] Referring to FIG. 1 , an email synchronization and workflow system 100 is provided. Multiple users 104a, 104b, 104c, and 104d are shown in FIG. 1 . Any number of users 104a, 104b, 104c, and 104d may be provided in accordance with the present invention; in the illustrated example, only four users are shown for clarity. In the illustrated example, users 104a, 104b, 104c, and 104d may be sales representatives who need to contact potential customers via email to sell products or services. The email synchronization and workflow system 100 operates to establish communication with leads 101a, 101b, 101c, and 101d. Any number of leads 101a, 101b, 101c, and 101d may be provided in accordance with the present invention; in the illustrated example, only four leads are shown for clarity. As described herein, the system 100 automatically manages the delivery of outgoing emails 103a, 103b, 103c, 103d while simultaneously managing incoming emails 102a, 102b, 102c, 102d. The number of incoming emails 103a and outgoing emails 102a that can be processed by a system according to the present invention is not limited. In the illustrated example, only four of each are shown for clarity.

[0013] Referring to FIG. 1a, an email synchronization subsystem 110 is provided. Multiple email inboxes 111a, 111b, 111c, and 111d are shown in FIG. 1a. In the illustrated example, the inboxes 111a, 111b, 111c, and 111d may correspond to user 104a or user 104b shown in FIG. 1 on a many-to-one basis (a user may have one or more configured inboxes). These inboxes 111a, 111b, 111c, and 111d may correspond to corporate email accounts of sales representatives. The email synchronization and processing system 110 operates to provide the necessary capabilities for processing incoming messages 112a, 112b, 112c, and 112d from prospective customers 101a, 101b, 101c, and 101d.

[0014] In the illustrated example, communication with inboxes 111a, 111b, 111c, and 111d is programmatically established and occurs continuously to achieve real-time access to new emails. A separate connection is created for each individual inbox, e.g., inbox 111a, and new emails 112a, 112b, 112c, 112d, and 112e are received by system 100 as they are delivered to the corresponding mailbox 111a. Communication can occur over a variety of protocols, depending on the underlying email server on which inbox 111a is located.

[0015] In practice, many customers have email servers provided by Google Apps, in which case the communication protocol with inbox 111a is configurable and can be via polling-based Internet Message Access Protocol (IMAP) or push-based Google's proprietary GMail API. Other customers have on-premise or cloud-hosted Microsoft Exchange email servers, in which case inbox synchronization is via Exchange Web Services (EWS).

[0016] An important difference between the email synchronization subsystem 110 and typical applications of IMAP, EWS, or the GMail API is the handling of multiple inboxes 111a, 111b, 111c, 111d simultaneously. Generally, neither IMAP, EWS, nor the GMail API provide functionality for synchronizing multiple inboxes; each mailbox must be synchronized independently.

[0017] In a typical application, a user 104a may provide a list of leads 101a, 101b, 101c, 101d, 101e to the synchronization and workflow system 100 in the form of a comma-separated value (CSV) spreadsheet. Referring to Figure 1b, the leads 101a, 101b, 101c, 101d, 101e may be generated automatically based on a query to a database 123 or based on a query to a separate customer relationship management system, such as salesforce.com.

[0018] Figure 2 illustrates a flow chart of one method for processing and storing emails received from the email synchronization subsystem 110. The method shown in Figure 2 includes steps involved in both determining which prospects 101a, 101b, 101c, 101d, 101e (if any) are associated with a given email 112a and storing the email in database 123. More generally, the diagram shown in Figure 2 relates to the email processing subsystem 124 shown in Figure 1b.

[0019] Referring to Figure 2, in step 201, emails 112a, 112b, 112c, 112d, and 112e received from the synchronization subsystem 110 are continuously received and processed. The first step, step 202, is to extract metadata about the email 112a from the RFC2822 email headers associated with the email 112a. The TO, FROM, CC, and BCC headers are used to determine which users 104a, 104b, 104c, and 104d and which prospects 101a, 101b, 101c, and 101d are associated with the email 112a based on email address matches. In step 203, the system checks for the existence of related prospects 101a, 101b, 101c, and 101d. If lead 101a, 101b, 101c, or 101d is not related to email 112a, step 207 checks to see if email 112a is part of a larger email thread. In this method, the IN-REPLY-TO RFC2822 email header is recursively checked to see if this email 112a is part of a larger email thread. If any previous email contains a reference to lead 101a, 101b, 101c, or 101d, this email 112a is considered to be indirectly related to lead 101a, 101b, 101c, or 101d, respectively.

[0020] In this particular method, if neither of the above steps 207 nor 203 result in an associated lead 101a, 101b, 101c or 101d, then the email is stored in the database 123 and no further processing is performed, as shown in step 208.

[0021] In fact, email data is of the most sensitive type with respect to customer privacy. Therefore, it is desirable that emails 112a, 112b, 112c, 112d, and 112e that are not directly related to the sales process (as determined by their association with prospective customers 101a, 101b, 101c, and 101d) not be stored in a manner that preserves their content. One approach would be to simply not store emails 112a, 112b, 112c, 112d, and 112e at all, but this loss of information may be undesirable for other parts of the system. Instead, to achieve this, in step 208, only metadata about such emails 112a, 112b, 112c, 112d, and 112e is stored. This metadata includes the RFC2822 message ID and MD5 hashes of the subject and recipients. In this particular embodiment, an MD5 hash is used, but any other cryptographic hash function can be utilized.

[0022] If lead 101a, 101b, 101c, or 101d is associated with email 112a, 112b, 112c, 112d, or 112e (as determined in steps 203 or 207), the system attempts to derive additional information about email 112a, 112b, 112c, 112d, or 112e, respectively, in the form of a classification. One such embodiment of a classification system is to use a rule-based system in which an ordered set of conditions is directly mapped to a classification. Such an embodiment is depicted in FIG. 3.

[0023] 3, if email 112a contains a subject line prefixed with "Ooto," "Auto:," or "Ooo," the classification of the email is Out of the Office (OOTO). If the subject line of the email contains "automatic reply," "auto response," "out of office," "out of the office," "away from my mail," "on leave," or "sick leave" in any part of its content, email 112a is classified as OOTO. If the first 80 characters of the body of the email contain "out of office," "out of office," "away from mail," "on leave," "sick leave," or "maternity leave," email 112a is classified as OOTO.

[0024] 3, if email 112a has an RFC2822 header named "Auto-submitted" with a value of "no," or if any of the headers named "x-autoreply," "x-autorespond," or "x-mdautoresponse" is present, the email is also classified as out of office. If the sender's email address starts with "Mailer-daemon," "Mailerdaemon," or "postmaster," email 112a is classified as a bounce. If the subject is prefixed with "Undeliverable," "failed mail," "failed delivery," "mail delivery fail," "mail system error," "failure notice," "Nondeliverable," or "delivery status notification (failure)," email 112a is classified as a bounce.

[0025] 3 also shows that in this particular method, if a particular email 112a's RFC2822 IN-REPLY-TO or REFERENCES header contains a message ID stored in database 123, the email 112a is classified as a reply. When email delivery subsystem 122 sends a message, it includes text metadata in the body. If this metadata is present, the email 112a is classified as a reply. If the email 112a contains the same subject and recipients as a previous message delivery, the email 112a is classified as a reply.

[0026] In the embodiment described above as represented by Figure 3, all rules are specific to English, but are equally applicable in other languages. In a preferred method, the rules are expanded to include other language equivalents. For example, "out" also includes a rule to match "ausserhaus" in German.

[0027] Although reference has been made herein to a heuristic rule-based system for email classification in this particular embodiment, other systems are also applicable, such as statistical methods based on machine learning techniques. For example, a logistic regression model or a neural network can be trained on a large number of sample email classifications to create a model that can be used to classify future emails.

[0028] Referring to FIG. 2 , email messages 112a associated with prospective customers 101a, 101b, 101c, 101d, or 101e in the system are stored in database 123, as represented by step 205. Email messages 112a may be multithreaded and include multiple recipients. Thus, each incoming message 112a, 112b, 112c, 112d, or 112e may exist in multiple inboxes 111a, 111b, 111c, or 111d and may be associated with multiple prospective customers 101a, 101b, 101c, 101d, or 101e. In this example, such messages 112a, 112b, 112c, 112d, or 112e all share the same RFC2822 message ID. In this particular embodiment of the system, storage 123 uses a simple deduplication method that ensures that each message ID exists only once in database 123.

[0029] Prior to the present invention, most third-party systems that act on behalf of the inbox and attempt to receive replies to messages utilize RFC2822 REPLY-TO and SENDER headers. In practice, this method has been found to provide very low accuracy. In industry, this can be as low as 30%. This is because spam-catching engines such as SpamAssassin are particularly interested in these headers. Furthermore, these methods can have a significant impact on the sender's email reputation. The present invention provides a significant advantage over such conventional methods, providing high reply detection accuracy as if the user had manually sent the email 112a, while the present invention has only a minor impact on email reputation.

[0030] In practice, when sending an email communication, it is not uncommon for the recipient to respond to the email 112a using a different email address than the one specified as the "to" recipient. This may equally be true for an outgoing email 112b sent to a lead 101b, who responds using a different email address than the one specified as the "to" recipient in the email 112b sent to the lead 101b. In this case, it is desirable for the system to properly establish this new email address as corresponding to the original lead 101b. Figure 6 is a chart depicting an embodiment that provides such functionality.

[0031] The chart represented by FIG. 6 illustrates the steps necessary to determine an indirect relationship between an incoming email 102a and a prospect 101c when there is no exact email address match for an existing prospect 101a, 101b, 101c, or 101d. As shown in step 601, if the prospect 101a replies with the original "to" email 102a and we have a direct match, this logic is not necessary; in that case, the system proceeds to step 602. However, if there is no match for the prospect 101c, the system proceeds to step 603. Steps 604 and 605 illustrate the core logic of this embodiment: if the incoming email 112a has a FROM address that contains a character match with the first or last name of the original prospect 101c, the system associates this new email address with the existing prospect 101c. If neither the first name nor the last name matches an existing lead 101a, 101b, 101c, or 101d, the system proceeds to step 606, at which point the system creates an entirely new lead 101e and associates the new lead 101e with the incoming email 112a.

[0032] While this description of an embodiment of the present invention uses the example of a business selling to potential customers over email, the usefulness of the present invention is not limited to email sales environments. In most business environments, conversing with existing customers, potential partners, and general communication is essential to the success of the business. The present invention may be useful in any environment where email communication is used for any purpose.

[0033] 4 illustrates an example of a shared inbox view for a particular known lead 101a, displaying email data from multiple mailboxes 111a, 111b, and 111c. It is common for multiple users 104a, 104b, 104c, and 104d to communicate with the same lead 101c, and it is beneficial for users 104a, 104b, 104c, and 104d to be aware of this. For example, sender 401a may see that sender 401b has also communicated with lead 101c, and for that reason, in some circumstances, may choose not to engage in a particular email communication with lead 101c. For example, if lead 101c has already received a particular referral offer from sender 401b, sender 401a may not need to send the same offer to lead 101c. In fact, it has been found that greater visibility allows users 104a to make smarter decisions regarding engaging with particular prospects 101c.

[0034] FIG. 4 includes a histogram 403 showing the incoming and outgoing communication history with the prospect 101c over a 12-month period across all user mailboxes 111a, 111b, 111c, and 111d. In histogram 403, each blank bar represents a month, with the rightmost bar 402e being the current month. In histogram 403, bars 402b and 402d, shown entirely or partially in black, show a graphical representation of outgoing communications. In histogram 403, bars 402a and 402c, shown with dashed portions, show a graphical representation of incoming communications. If there was no communication in a given month, that fact is graphically indicated in histogram 403 as a blank bar 402e. This allows the user 104a to see, at a glance, the last time they communicated with the prospect 101c and also the frequency of communication in the past. A prospect who responds frequently will show a relatively balanced collection of black bars 402b, 402d and dashed bars 402a, 402c, while a prospect who rarely responds will show very few (if any) dashed bars 402a, 402c.

[0035] Users often need the ability to perform specific actions based on events triggered from the workflow system 100. To accomplish this, users can create triggers, which are a key component to the system 121. Figure 5 is an example of a trigger 500 that can be created to update lead information when an outgoing email 103a is marked as replied 501 and certain lead conditions 502, 503 are met. In this example, these lead conditions 502, 503 must be met before the system will perform the action 504 shown in Figure 5. Logical operators may be used to combine multiple conditions. In the illustrated example, The first two listed conditions 502 are that the lead's Title contains "Recruit" or the lead's Stage equals "Cold." The first two conditions 502 are logically ORed together, meaning that if either condition occurs, a logical "true" condition exists for the two. The two conditions 502 are then combined with a third condition 503, which in the illustrated example is that the lead's Persona is Unset. In this example, the third condition 503 is logically ANDed with the first two conditions 502. Thus, in this example, if either of the first two conditions 502 is true and the third condition 503 is also true, then the conditions 502, 503 for generating action 504 are met. The fields labeled "Title," "Stage," and "Persona" in FIG. 5 are examples of fields provided in database 123 for data associated with known prospects 101a, 101b, 101c, 101d.

[0036] Assuming these conditions are met as required by the specified logical operators, the following actions 504 shown in the example illustrated in Figure 5 are executed in order: at 504a, set the lead's persona to be "Engaged." at 504b, add a tag of "Replied" to the lead. Then, at 504c, add the lead to the "Tier 3 - East Region" sequence.

[0037] Users 104a, 104b, 104c, 104d can set any combination of conditions and actions, allowing for a very powerful automation layer. The workflow system 100 generates various events that triggers can listen for, including emails delivered, emails replied to (501), emails bounced, emails marked as out of office, leads created, and leads updated.

[0038] Sequences are an important feature of the workflow and automation system 121. FIG. 7 illustrates a sequence, which is a series of outgoing emails 103a, 103b, 103c, and 103d designed to be sent to a lead 101d spaced apart by predetermined time intervals 705a and 705b. Each sequence step can configure its own time interval 705a or 705b. When a lead 101d is added to a sequence, the system begins at step 701a shown in FIG. 7. Step 701a delivers an email 103a to the lead 101d and waits the set interval 705a for a reply. If a reply has not been synchronized from the system 110, the lead 101d proceeds to step 701b, where another email 103b is delivered to the lead 101d. Again, the sequence waits another set interval 705b for a reply. If no reply is received, the lead 101d proceeds to step 701c, and so on until the lead 101d has gone through every step in the predetermined sequence.

[0039] If the lead 101d replies in response to the email 103a sent in step 701a, the system 701 associates the reply with the lead 101d in step 704a. If the lead 101d replies in response to the email 103b sent in step 701b, the system 110 associates the reply with the lead 101d in step 704b. When the system 110 synchronizes a reply from the lead 101d associated with any email 103a, 103b, etc., the lead 101d is marked as completed in the sequence in step 704. When the lead 101d is marked as completed, the lead 101d will no longer receive emails from the sequence.

[0040] Explaining further the sequence step interval, users 104a, 104b, 104c, and 104d can also set their own delivery schedule blocks, as illustrated in Figure 9. The sequence schedule blocks allow users 104a, 104b, 104c, and 104d to deliver emails 103a, 103b, 103c, and 103d at specific dates and times. This prevents emails 103a, 103b, 103c, and 103d from being delivered during unrealistic times, such as 1:00 AM on Saturday.

[0041] For example, users 104a, 104b, 104c, 104d may specify a delivery window of 9:00 AM to 6:00 PM PST (Pacific Standard Time) on Monday using delivery schedule blocks 902a, 901a shown in Figure 9, and choose not to deliver on Saturday by excluding delivery schedule blocks 901c, 902b shown in Figure 9. If a sequence step schedules email 103b to be delivered at invalid schedule block 901b, email 103b will be scheduled for delivery at the next valid time 901a, 902a. For example, if a sequence step schedules email 103b to be delivered on Saturday, but delivery schedule block 901c shown in Figure 9 is excluded as a valid delivery window, email delivery will be postponed until the next valid time, which in this example is 9:00 AM on Monday, corresponding to delivery schedule block 902a shown in Figure 9.

[0042] Referring to Figure 8, every sequence step is mapped to an email template 801 or 802, which includes a template type 801a and 802a, respectively, an email subject 801b or 802b, respectively, and an email body 801c or 802c, respectively. The template type can be either New Thread 801a or Reply 802a. The New Thread template creates a new email thread, while the Reply template replies to a previously delivered email. Because template 802 is marked as a Reply template 802a, when email 103b is delivered according to template 802, it is generally a reply to email 103a according to template 801.

[0043] Both template subject 801b and template body 801c may include template variables shown in FIG. 8 with reference numerals 801d, 801e, and 801f. Template variables 801d, 801e, and 801f point to fields associated with lead 101b. For example, the "{{first_name}}" template variable 801d points to the "First Name" field for the corresponding lead 101b. If lead 101b's first name is "Joe," then the variable "{{first_name}}" is replaced with "Joe" when the template is compiled just prior to delivery time via system 122. The fields labeled "first_name" and "industry" in FIG. 8 are examples of fields provided in database 123 for data associated with known prospects 101a, 101b, 101c, and 101d, and the field labeled "sender.name" in FIG. 8 is an example of a field provided in database 123 for data associated with known users 104a, 104b, 104c, and 104d.

[0044] For a particular lead 101c, if a template variable does not exist or if a template compilation error exists, the associated email 103d will not be delivered. This is a safety setting in place to prevent the delivery of robotic-looking emails with uncompiled template variables. Users 104a, 104b, 104c, 104d will need to manually correct these email drafts to keep the lead 101a through the sequence.

[0045] The benefit of sequences for users 104a, 104b, 104c, 104d is automated email follow-up. In many cases, this can require seven or more follow-up emails 103a, 103b, 103c, 103d to be sent to lead 101a before lead 101a responds. Automating these follow-ups allows users 104a, 104b, 104c, 104d to communicate with more leads 101a, 101b, 101c, 101d and advantageously save time.

[0046] Those skilled in the art, after having the benefit of this disclosure, will appreciate that modifications and variations may be made to the embodiments described herein, different design parameters and materials may be substituted, equivalent features may be used, changes may be made in assembly, and additional elements and steps may be added, all without departing from the scope and spirit of the present invention. This disclosure describes only certain presently preferred embodiments and examples, and no attempt has been made to describe every possible variation and embodiment that falls within the scope of the present invention. Accordingly, the scope of the present invention is defined by the claims appended hereto, and is not limited to the specific examples set forth in the foregoing description.

Claims

1. 1. A non-transitory computer-readable medium having a memory having encoded thereon instructions for automatically managing email communications between a user and known prospects, the instructions comprising: First instructions for detecting an email received in a first user's email inbox; second instructions for extracting a first portion of metadata and a second portion of metadata from a header of the email; third instructions for determining whether a first portion of the metadata matches first information in a first entry of a first database, the first entry corresponding to the known potential customer; and fourth instructions for determining that the email is associated with the known lead in response to determining that a first portion of the metadata matches the first information in the first entry of the first database; fifth instructions for determining whether a second portion of the metadata matches second information in a second entry of a second database, the second entry indicating whether a copy of the email received in a second user's email inbox is already stored in the second database; and sixth instructions for discarding the email in response to determining that a second portion of the metadata matches the second information in the second entry of the second database; seventh instructions for storing the email in the second database associated with the known prospect in response to determining that the second portion of the metadata does not match the second information in the second entry of the second database; 1. A non-transitory computer-readable medium, comprising:

2. The non-transitory computer-readable medium of claim 1 , wherein the first portion of the metadata includes a user identifier.

3. 3. The non-transitory computer-readable medium of claim 2, wherein the third instructions for determining whether a first portion of the metadata matches the first information in the first entry of the first database include further instructions for determining whether the user identifier exactly matches a known user identifier of the known prospect in the first database.

4. The third instructions for determining whether a first portion of the metadata matches the first information in the first entry of the first database include: determining that the user identifier does not exactly match a known user identifier of the known prospect in the first database; determining whether the user identifier has a character match with one or more of the first name and last name of the known prospect; 8. The non-transitory computer-readable medium of claim 2, further comprising: eighth instructions for determining that a first portion of the metadata matches the first information in the first entry of the first database in response to determining that the user identifier has the character match with the one or more of the first name and the last name of the known prospect.

5. 5. The non-transitory computer-readable medium of claim 4, wherein the eighth instructions further include ninth instructions for associating the user identifier with the known prospective customer in response to determining that the user identifier has the character match with the one or more of the first name and the last name of the known prospective customer.

6. The non-transitory computer-readable medium of claim 1 , wherein the second portion of the metadata includes a message identifier.

7. 7. The non-transitory computer-readable medium of claim 6, wherein the fifth instructions for determining that the second portion of metadata matches the second information in the second entry of the second database include eighth instructions for determining that the message identifier matches a distinct message identifier stored in association with the email inbox of the second user.

8. 2. The non-transitory computer-readable medium of claim 1, wherein the fifth instructions further include eighth instructions for associating the copy of the email with the known prospect, further in response to determining that a second portion of the metadata matches the second information in the second entry of the second database.

9. 1. A computer-implemented method for automatically managing email communications between a user and known prospects, comprising: Detecting an email received in a first user's email inbox; extracting a first portion of metadata and a second portion of metadata from a header of the email; determining whether a first portion of the metadata matches first information in a first entry of a first database, the first entry corresponding to the known prospect; determining that the email is associated with the known lead in response to determining that a first portion of the metadata matches the first information in the first entry of the first database; determining whether a second portion of the metadata matches second information in a second entry of a second database, the second entry indicating whether a copy of the email received in a second user's email inbox is already stored in the second database; discarding the email in response to determining that a second portion of the metadata matches the second information in the second entry of the second database; storing the email in the second database in association with the known prospect in response to determining that the second portion of the metadata does not match the second information in the second entry of the second database; A method comprising:

10. The method of claim 9 , wherein the first portion of the metadata includes a user identifier.

11. 11. The method of claim 10, wherein determining whether the first portion of the metadata matches the first information in the first entry of the first database includes determining whether the user identifier exactly matches a known user identifier of the known prospect in the first database.

12. Determining whether a first portion of the metadata matches the first information in the first entry of the first database includes: determining that the user identifier does not exactly match a known user identifier of the known prospect in the first database; determining whether the user identifier has a character match with one or more of the first name and last name of the known prospect; 11. The method of claim 10, comprising: in response to determining that the user identifier has the character match with the one or more of the first name and the last name of the known prospect, determining that a first portion of the metadata matches the first information in the first entry of the first database.

13. 13. The method of claim 12, further comprising: associating the user identifier with the known prospect in response to determining that the user identifier has the character match with the one or more of the first name and the last name of the known prospect.

14. The method of claim 9 , wherein the second portion of the metadata includes a message identifier.

15. 15. The method of claim 14, wherein determining that the second portion of the metadata matches the second information in the second entry of the second database comprises determining that the message identifier matches a separate message identifier stored in association with the email inbox of the second user.

16. 10. The method of claim 9, further comprising associating the copy of the email with the known prospect in response to determining that a second portion of the metadata matches the second information in the second entry of the second database.

17. a memory having encoded instructions; one or more processors that, when executing the instructions, cause operations to be performed; a system comprising: Detecting an email received in a first user's email inbox; extracting a first portion of metadata and a second portion of metadata from a header of the email; determining whether a first portion of the metadata matches first information in a first entry of a first database, the first entry corresponding to a known prospect; determining that the email is associated with the known lead in response to determining that a first portion of the metadata matches the first information in the first entry of the first database; determining whether a second portion of the metadata matches second information in a second entry of a second database, the second entry indicating whether a copy of the email received in a second user's email inbox is already stored in the second database; discarding the email in response to determining that a second portion of the metadata matches the second information in the second entry of the second database; storing the email in the second database in association with the known prospect in response to determining that the second portion of the metadata does not match the second information in the second entry of the second database; Including, the system.

18. The system of claim 17 , wherein the first portion of the metadata includes a user identifier.

19. 20. The system of claim 18, wherein determining whether the first portion of the metadata matches the first information in the first entry of the first database includes determining whether the user identifier exactly matches a known user identifier of the known prospect in the first database.

20. Determining whether a first portion of the metadata matches the first information in the first entry of the first database includes: determining that the user identifier does not exactly match a known user identifier of the known prospect in the first database; determining whether the user identifier has a character match with one or more of the first name and last name of the known prospect; determining that a first portion of the metadata matches the first information in the first entry of the first database in response to determining that the user identifier has the character match with the one or more of the first name and the last name of the known prospect; 20. The system of claim 18, comprising:

21. 21. The system of claim 20, wherein the operations further include associating the user identifier with the known prospect in response to determining that the user identifier has the character match with the one or more of the first name and the last name of the known prospect.

22. The non-transitory computer-readable medium of claim 1 , wherein the first database and the second database are the same database.

23. The method of claim 9 , wherein the first database and the second database are the same database.

24. 20. The system of claim 17, wherein the first database and the second database are the same database.

Images