17

I am working on building an app for a startup company on the Force.com platform, and I am struggling to find the best way to set up and distinguish between two very distinct customer types.

The customer types:

  1. Standard B2B type customers, which will purchase hardware and software and maintain an ongoing relationship with the company
  2. B2C type customers (generally will be many more of these than of the B2Bs) who purchase a service (similar to a loyalty program) from the company.

The company acts as a middleman between the two customer types, but sells products and services on both sides.

Any thoughts on the best way to set this up without using person-accounts (which I am forced to work with now at another company, and can't stand)?

Thanks!

13

I think this question is focused on how to structure the Account and Contact objects. You could create an enforced one-to-one Account-Contact model by using triggers to query the number of contacts for each B2C account, and to throw an error if more than one contact exists. You'll also want to enforce exactly one contact on every account edit (but not on create). Triggering the creation of a new contact for those accounts after insert would also be a good idea. Essentially, you'll need to use two Account record types, might need two contact record types, efficient triggers, and two Opportunity record types so you can use two sales processes.

  • Thanks, I'll look into these ideas. Another possibility was one 'master account' with all of the B2C customers as contacts on the one 'master account'. Do you think there is a big downside to doing it this way? – jackerman09 Jul 31 '12 at 23:08
  • I like David's suggestion a lot. One advantage to starting with 1 Account per Contact is that it naturally expands into a common B2C construct: the "household", "address", or "family". You don't send 7 pieces of print to one house just because 7 people from one address are your customers. That may not apply to your business, but it's not uncommon at some point to need a slightly-higher-than-individual B2C grouping and Account is a natural fit for that. – jkraybill Jul 31 '12 at 23:50
  • Good point, I'm not sure whether the business case would call for each individual in a household getting their own info, or the household getting just one. I'll have to look into that. Thanks! – jackerman09 Aug 1 '12 at 15:09
  • Why go to all that bother of duplicating the functionality which Person Accounts give you out of the box? – David Gillen Aug 1 '12 at 15:40
  • Mostly because the OP said that he does not want to use them. – DavidSchach May 11 '15 at 21:37
13

I would strongly advocate against going with one master account for many contacts model (B2C). We had a serious record locking issue with this implementation due to the way Salesforce locks the parent for each detail record update. Any update to the contact will lock the account record. So if you had many threads updating different contact records on the same account then will land into locking issues.

Here is an article from Salesforce that talks about the lock issue in detail http://blogs.developerforce.com/engineering/2012/04/avoid-account-data-skew-for-peak-performance.html

  • Wow. I've never heard of this. Good feedback! – pdxjake Aug 3 '12 at 21:59
4

Maybe you could use "Record Types" to route your business process workflow to maintain a distinction between the type types of customers.

  • I've looked into this, and I've used Record Types extensively in the past, but in this case I feel like B2B and B2C customers are almost too different to just use different record types, but creating separate objects seems like overkill. This is where I'm stuck... where to draw the line without reinventing the wheel... – jackerman09 Jul 31 '12 at 20:38
3

It's not a very delicate tool, but you could float the idea of using an "Individual Client" type of master-account (what the actual account TBD). All B2C client/customers can belong to this master account. I've set some orgs up that way.

Benefits: easy to implement, easy to use. Drawbacks: not as elegant when it comes to reporting, metrics, etc.

If the business process warrants, you can also leverage record types and workflow rules to key off of whether the Contact/Account is B2B or B2C.

  • This is one of the three options I'm looking into, along with using an Account/Contact pair for every B2C customer (with a different record type) and the other possibility is creating two custom record types, which creates the downside of having to start some reports (and other things) from scratch, but the upside of total flexibility. Any thoughts? – jackerman09 Jul 31 '12 at 23:13
  • I like the B2C contact/account solution. Visibility and integrity could be enforced with a few well-constructed validation/workflow rules and the record types you mentioned. – pdxjake Aug 3 '12 at 21:58
3

Whenever I start a new design with many implementation options I like to work backwards from what I want the end result to be and figure out the implementation based on that. The best way to set things up usually suggests itself. Here are a few questions to get you started.

  1. Will B2C customers use standard account functionality? (opportunities, contacts underneath them, etc.)
  2. When they search for and report on B2C and B2B customers will they want them to be completely separated (i.e. separate objects) or will they want them on the same reports/dashboards?
  3. Could a B2C customer ever convert to a B2B customer and vice-versa? This is much easier to do if you have them as recordtypes of account.
  4. Will a B2C customer always be related to a B2B account?
  • I'll take those in order... 1. They will use opportunities and will likely start as leads, but will not need separate contacts under them if the account stores the necessary contact info (address, email, phone, etc.) 2. They can be completely separate (which makes me want to lean towards creating custom objects) 3. No, they will never be converted from one to the other. 4. No, a B2C customer can be completely unrelated to a B2B account (and at first, will always be), but may be linked up to one or more at a later time. Thanks! – jackerman09 Jul 31 '12 at 23:14
3

Use standard Account and Contact object for the B2B side of things. And use Person Accounts (you will need to request to have these turned on, typically takes < 24 hours) for the B2C customers. Person accounts are an amalgamation of the Account and Contact records.

You can read more at http://na11.salesforce.com/help/doc/en/account_person.htm

  • 2
    I have used Person Accounts before, and they are horrible. I would highly recommend against anyone using Person Accounts in any org unless there is no other option. They are not well-supported by Salesforce, they get updated last, formulas often don't work with them, and they are a pain to use with APEX. Just my experience though... – jackerman09 Aug 1 '12 at 15:11
  • I disagree. Salesforce continues to improve how they work. I have never had problems with either formula fields or Apex working with them, or indeed the API. – David Gillen Aug 1 '12 at 15:39
2

I too would suggest having record types on the Account object - one for your B2C Accounts and one for the B2B Accounts. In this way, you could have separate page layouts and fields for each type of contact, but avoid having to use Person Accounts.

  • And every B2C customer would get an account and a contact page, or what were you thinking for that? – jackerman09 Jul 31 '12 at 23:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.