Synchronizing Accounts Across Your Systems

Introduction

The Natero Success Engine harnesses your data to predict, analyze and drive customer behavior.

If you are using third party systems for managing CRM, Support or Billing, it is essential that all entities be cross reference-able from your own product customer ID's towards each of these systems. Basic entity mapping needs to be in place, so that a complete picture of a customer found in your product can be represented within Natero, including product usage data, CRM, support tickets and invoices for example.

Natero entities

The central entities within Natero are:

  • Accounts: your customers, typically companies
  • Account Users: your users, typically people that work for your customers and use your product

Natero Accounts have the following ID fields

fields description
account_id customer id in your own product, this is the account ID Natero expects in product usage data
crm_account_id account id from CRM system, eg Salesforce Account.Id
billing_account_id account id from billing system, eg Chargify customer.id
support_account_id account id from support system, eg Zendesk organization.id

Natero Account Users have the following ID fields

fields description
user_id user id in your own product, this is the user ID Natero will be expecting in product usage data
account_id maps user to account based on product usage data
crm_account_user_id account user id within CRM, eg Salesforce Contact.Id
crm_account_id maps user to account based on CRM system, eg Salesforce Contact.AccountId

All roads must lead to account_id

As depicted above, account_id is Natero’s alias for your unique customer id’s within your product. It is the ID that Natero expects to see in all product usage data (as well as user_id).

In order for Natero to perform its magic, all roads (all data) needs to lead to account_id. This enables aggregation and account-based metrics to be calculated correctly.

Here is what a typical schema looks like:

Overcoming obstacles 

While the mapping described above may seem trivial, the typical problem lies in cross resolving account_id for all third party systems, consider this example:

You have a customer named ‘ACME Services’, and this is what can be found in your product’s database:

{
  name: ‘ACME Services’,
  id: 34
  users: [ … ],
  ...
}

You use a third party CRM system, and this customer can be found as follows in the Account table:

{
  Name: ‘ACME’,
  Id: 110
  ...
}

Finally, you use a third party support ticket system and a similar record can be found in the organizations table:

{
  name: ‘Acme Inc.’,
  id: 2101
  ...
}

In a world where data has been normalized to total cleanliness, it would be trivial to cross reference these records based just on name, website, domain, main contact email, phone number or some other attribute. The problem is that we live in the real world, and in the real world, data is not totally clean… it is common for company names to be misspelled, duplicate records to exist, etc

Unless an id-level mapping is provided for these records, it will be difficult to link them.

There are several options to resolve this situation:

Solution #1: add external ID’s everywhere

Most third party systems allow you to add an external id either as a custom or canned field, it would be natural to use your own product account ID’s for those fields.

In our example, we added a custom field named ‘MyId’ to the CRM’s Account table:

{
  Name: ‘ACME’,
  Id: 110,
  MyId: 34
  ...
}

And we populated the support system’s canned external_id field:

{
  name: ‘Acme Inc.’,
  id: 2101,
  external_id: 34
  ...
}

Solution #2: place links in one or more 3rd party system

After having established the required mapping to your own product account_id for at least one of your third party systems, it is possible to take an indirect route for the other systems by using custom fields or plug-ins.

Some CRM systems, including salesforce, provide plug-ins for other third party systems, such as Zendesk for example.

These plug-ins will create the mapping we need in the CRM’s Account table, we now have in the CRM:

{
  Name: ‘ACME’,
  Id: 110,
  MyId: 34,
  Support__Id: 2101
  ...
}

Note the new Support__Id field.

Support System is unchanged:

{
  name: ‘Acme Inc.’,
  id: 2101
  ...
}

Solution #3: map it with Natero’s API

Another option is to use Natero’s customer facing Account API to provide the mapping as follows:

{
  account_id: 34
  crm_account_id: 110,
  support_account_Id: 2101
  ...

We have now learned how to cross resolve account_id for all third party systems!

Mapping users to accounts

Once you have established a path to account_id for all systems, please check that users are also mapped to their respective organizations within each system, for example:

In CRM Systems: The correct association of Contacts with Accounts is crucial to avoid having incomplete Account User meta data, ie missing contact info such as email or phone number. This leads to being unable to take action on alerts within Natero. 

For example, if you are using Saleforce, you can identify this problem by looking for missing or null AccountId within the Contact table.

In Support Ticketing Systems: It is quite common for users to register within your support system to submit tickets, without ever being associated with an organization. This situation leads to these tickets not being attributed to any organization, and could potentially mean the loss of customers which could have been detected much earlier as “at risk” by Natero. 

For example, if you are using Zendesk, you can identify this issue by looking for Users with missing or null organization id. This link provides instruction on how to create and manage organizations within Zendesk.

Have more questions? Submit a request

Comments