B2C / B2B with Sugar (Accounts ? Contacts ? Both ?)

We do duplicate the info (for the B2C) and create an Account and a Contact - but make it from the specific point of view

While Account represents a subject of the management (Company-client in b2b and Persona-client in b2c) , we suggest treating "Contact" not as a noun  - a person that belongs to the company - but rather like a verb (to contact).
That helps to benefit from the correct abstracts in both sell and marketing - a Contact record is a set of characteristics/credentials sales team use for contacting the Account, while a Lead is an interest in the particular product or service, expressed by some person via  the particular channel

Hi Dmytro,

I hope you are doing well. This is the option we were thinking about ; but of course, it means that, because the customer (B2B, B2C) are synchronized with an external solution, we have to keep the consistency between two records (contact and account), and the same if the contact is updated (for instance from Sugar Market).

Fred

Hi Fred, i may of missed something but Sugar Market syncs Accounts and Contacts so you can segment on either or both (contacts at accounts). Just use the filter options in the Report Builder to select the right parameters.

Hi Andrew,

I know we can but it's limited ; maybe this post will help understanding why I say that the use of account is limited : https://sugarclub.sugarcrm.com/partner-club/sugar-market-for-resellers/f/forum/4318/account-level-marketing with SugarMarket.

I think the standard naming convention for most CRM systems doesn't help and can be misleading.

Tip; rename Accounts module to Organisations or Companies.

Example; how many 'Accounts' in the CRM are actually customers and therefore have an account with a unique account reference number derived from your Finance/Billing system?
Not all, correct?

Therefore we call this module for what it actually contains, Companies, and adopt the 'Type' field or something similar to identify if they are a Customer, Prospect, Supplier etc.....

Same can be done for Contacts in a B2C or even B2C2B scenarios. In some cases, customer rename this module as well and call it 'People'.
Regardless, you can adopt the same dropdown or similar to identify if they are a Customer. No need to duplicate data and also create the same person as an Account, especially if the module is no longer called 'Accounts' right? ;-)

I do realise that some scenarios may want to use both for individuals, i.e. a Bank. In those cases, the Account name would be the unique Bank Account reference number, which would then allow multiple related Contacts for joint accounts by related people or business bank accounts.

Hope those ideas are helpful?

Most has already been said but I'd be interested in knowing the business area? Some can make use of an "account". I'm thinking about insurance, banking etc. where the account can represent the household and gather contacts that have no direct contractual relationship. 

As a general rule, the account is the one that pays. Companies for B2B, physical persons for B2C. So I tend to prefer "account" to "company/organisation". 

And in the case of Sugar, duplicating the info from the contact to the account (and keeping it synced) is probably the best solution to remain consistent and make it easy to interface with other apps (Connect, Market...). Other CRM systems have that built-in, but this comes with its own set of limitations so Sugar offers nice flexibility :)

Finally, marketing campaigns should address people (=contacts) not companies, although ABM uses company info/score/history to segment/personnalise further. So you're better off with keeping both levels, and syncing your "pseudo account" with the contact details. 

Hope this helps!

Agree with Vincent Amari

When we work with banks, telco, insurance, automotive, some e-commerce, and not only we use "Account" to collect and account data about Subjects of Doing Business ( = Organizations, Households, Individuals) and "Contacts" to collect and account data about People who represent this Subjects of Doing Business. "Lead" we use to collect and account data about an interest of a particular Person to a particular product in a particular channel.

It helps to manage situations when one Person represents many Accounts simultaneously (organizations and/or households, and is a client as an individual) and demonstrates different interests: as company' manager, as a son, as father, as a fisherman :). 
It also helps manage situations when an Account is in several relations to CRM system owner (Customer/Partner/Competitor/...) each one can be in a different status (Prospect, Former, Active, Not relevant)

Anyway, this model works well with any marketing systems since all MA systems operate by Lists of contacts.

Of course, it requires adding many data populations and syncing algorithms, changing the OOTB data structure (at least, Contact has relation to many Accounts and an Account has different blocks of data by type), and efforts to configure smart restriction to data access. E.g., If I have access to the Contact as a Person of a particular Account, what I have to see about this Contact as representative of other Accounts. Such restrictions depend on the industry: for banks, it's obligatory to know about such relations, but for e-commerce, it's not. 

Sugar gives absolutely flexibility with data structure, and Logic Builder gives absolutely flexibility on the level of data processing inside Sugar. If a MA system doesn't provide ABM capabilities, we add custom logic on the Sugar side to manage marketing lists and tune marketing processes.

This approach also helps to solve one more important challenge: providing compatibility with new powered features from SugarCRM. 

There are lots of good input here and I love to see how we all share our experience. There are lots of response on the B2B perspective already so I will just talk about about B2C.

We often suggest our clients to rename the Accounts module to Household or Family depends upon the context. When you deal with individuals there are still value to group them together. This is particularly true for residential buildings and financial services clients. Hope this helps.