In Planhat, each email object is always assigned to one (1) company object. This presents assignment challenges when there are either a) end users from different company objects in the same email thread, or b) there is one end user associated with multiple company objects (e.g., Felicia at Coca Cola Norway and Coca Cola Sweden). Where does the email synced into Planhat exist? Historically, the assignment has been arbitrary which is likely not what you want.


To solve this, we have built a new setting under Settings > Emails > General settings > Email matching mode where users can choose logic for email assignment using a newly built “relevance score”.

Scenario: An email is synced into Planhat between a user and either a) one end user at multiple companies, or b) multiple end users at different companies.

Calculation logic: Planhat calculates a “company relevance score” for each end user:

  • If end user is related to the company (primary email): +10

  • If end user is related to the company (other email): +5

  • If user is the owner of the company: +10

  • If user is the co-owner of the company: +5

  • If multiple end users and some of them uniquely link to a single company object: +20 (for each end user where the statement is true)

  • Archived end users are excluded from the calculation

Settings (i.e., the feature): users can choose between three different options for the setting:

  • Safe: only assign the email to company A if company A has a “relevance score” => 20, and all other companies have a “relevance score” <=10; otherwise put the email as “unassigned”

  • Default: only assign the email to company A if company A has a “relevance score” => 20, and the difference in relevance scores between A and all other companies is =>10; otherwise put the email as “unassigned” for both companies and/or end users

  • Risky: always assign email to the company with the highest “relevance score”, unless there are 2 or more companies with equal scores, then put email as “unassigned”

Permissions: only modifiable by users with admin access.

Limitations: Planhat still only assigns each email to 1 company.

Outcomes and use cases: Planhat will now automatically assign emails based on the selected settings. The “unassigned” list of emails can be found in Conversations > Conversations > Unassigned.

📌 Important to note!

The overall objective of the feature is to make sure emails end up at the right place. With that in mind, this feature has made significant improvements towards that target, but there are still some limitations due to (A) Planhat still only assigning each email to 1 company, and (B) edge cases with these new settings.

  • (A) For inter-customer conversations: for example, hosting roundtables (e.g., Planhat hosting a “CS in SaaS roundtable” with the CEOs of 5 customers) or introducing customers to each other (e.g., Planhat connecting two marketplace customers for them to share learnings). In these cases, the email in question is truly relevant for two or more company-objects - but will be assigned to one (which one is primarily driven by the number of people per company in the email, and whether the sender is co-/owner of any company)

  • (A) For companies that have subsidiaries listed as company-objects and the topic of the email refers to company-level topics (e.g., Felicia is Head of Nordics at Coca Cola and is emailed regarding “Nordics”). The new feature improves these use cases, but there might still be cases where emails are relevant to multiple companies.

  • (B) For emails where there is a disconnect between context and how the rules are set-up: for example, if emailing four end users at Coca Cola Sweden and one at Coca Cola Norway with the headline “How we can increase Coca Cola Norway’s retention” and then starting the message with “Swedish colleagues included for reference”. The email will end up at Coca Cola Sweden with the “risky” setting, even though the user might think it’s super clear that this email refers to Norway. In other words, the setting does not consider any other data than participants which might not be intuitive to (or remembered by) the user

Did this answer your question?