CRM DB fundamentals

Plenty of articles exist on choosing your CRM, but let’s be honest – most startups only implement a CRM when required by their VC’s, and most will go with the market standard, as advised by said VC – usually Hubspot, SalesForce or Zoho (for the budget aware, and after working with their UI, I would also add masochists – but that’s a different post) 

When discussing CRM options and architecture with entrepreneurs one of the main issues I find is that most don’t fully grasp the value a CRM can bring them. The immediate and initial value of visibility into processes can be provided by a spreadsheet when starting, but even if you’re opting for the spreadsheet solution – at some point in the future – you’re probably going to want to add some capabilities to it,  like communications or deal tracking, so it’s especially important to understand the CRM database fundamentals in order to design your process.

Since I couldn’t find a post like this anywhere online, I decided to write one.

So without further adieu, here are CRM fundamentals:

The Entities / Components

Every CRM has 3 main entities / components:

• Users / Contacts / Customers – This represents a person.
• Company / Account – This represents a group of people working together, a business.
• Deal / Opportunity – This represents a transaction, or potential transaction.

Salesforce, Zoho, and some other CRMs will also have an Entity called “Lead”, which is a bit of a strange entity as it represents the person, business and transaction in one. The logic behind that is that in the initial stage of interaction with a potential buyer of your product (when it’s just someone who has shown interest or you are interested in targeting) there isn’t really a need for a company and an opportunity as you don’t really have a potential transaction in the pipeline. Once a lead reaches a certain threshold they are converted to a contact, account and opportunity.

Let’s look at an example of how to use these to structure your business’s pipeline, if you have a PLG B2B SaaS:

1. 1. With the Lead Entity:

      1. Lead would be a website visitor who downloaded a document, signed up to a webinar or met you at a conference.
      2. Contact would be anyone who signed up for a trial
      3. Each contact would have an account or company that will not only represent the contact details for the business entity, but could also represent the account details – if your product is collaborative.
      4. And once someone performs a registration to the trial – a deal or opportunity will be created, which will represent the stage of membership – Tier, how far along they are in the pipeline of your product, etc.

   2. With no Lead Entity:

      1. 1. Contact is created upon any sign up – marketing OR product. Lifecycle / stage property is what tells you where each person is in the pipeline.
         2. Each contact would have an account or company that will not only represent the contact details for the business entity, but could also represent the account details – if your product is collaborative.
         3. And once someone performs a registration to the trial – a deal or opportunity will be created, which will represent the stage of membership – Tier, how far 

This is obviously a highly simplified version, and I’m not getting into the micro-resolution of properties on the entities. I’d like to keep the rest of this post simple – because in order for your business operations software to be usable and actually become an integral part of your day to day work the best thing to do is keep it simple.

Also, to be honest, most tech startups don’t need much more than this when they start and they usually like to be able to make changes to the process as they move. 

So build your ops like you eat a sandwich – one bite at a time. 

Understanding this structure will not only help you move from your spreadsheet to a CRM in the near or far future, but will also help you understand where you actually have complexity – as most things can be built around these basic capabilities – like adding more built-in entities such as Products (to manage your offering), tickets (to manage support tickets) and campaigns (to manage marketing activities and more easily attribute leads, contacts and deals to your activities and spend).

Relying on these 3 basic components when you start will help you keep your properties focused. When gathering a piece of data, like, say, address – you want to first decide on which of the 3 entities to save this information – is it a company address? A personal address? Does it affect your pipeline? (like an address would be for, say – Ecommerce platform, where you need a user address)

You then want to decide what the relationship between these entities and their properties are – what are the stages a user, account or deal go through in your pipeline? There are default stages in all the major CRMs, and they are usually customizable. Each entity can also have several of these – there could be sales stages, product lifecycle stages, and subscription stages – which can all affect each other but not necessarily be identical.

To summarize – the setup of your CRM is a reflection of your company’s operations: an ever evolving mesh of processes, inputs and goals. Like everything else in your startup, it should be a learning process, and should be optimized as one. If you expect your initial setup to take 3 months and be done with for years, you’re going to be disappointed. 

If you’re currently setting up your CRM, you might also want to check out my post on important things that are NOT built in to most CRMs, and you should probably add on set up.