When an off-the-shelf CRM doesn't fit your business

Off-the-shelf CRMs are excellent at what they were designed for: tracking leads, contacts, accounts and deals through a sales process. Many businesses, though, don’t revolve around a sales pipeline. A landscaping company revolves around the properties it services. An equipment rental business revolves around its fleet. A consultancy revolves around engagements and deliverables.

When the CRM’s model and the business’s model disagree, the result is familiar: custom fields bolted onto the wrong objects, naming conventions everyone has to remember, and a spreadsheet on the side for everything the CRM can’t hold.

The mismatch, in practice

Here’s how the mismatch usually shows up:

• The core thing you track isn’t a first-class object. Properties get stored as “accounts” or crammed into notes on a contact.
• Relationships are flattened. A customer with five properties, each with its own service history, becomes a contact with a long notes field.
• Forms live elsewhere. Intake and request forms come from a separate tool, and someone connects them by hand.
• Permissions follow the CRM’s structure, not yours. You can restrict “deals”, but you can’t restrict “properties in the north region” if properties aren’t a real object.

Atlas starts from what you track

On the Enterprise tier, Atlas lets you define your own classifications. A classification is a blueprint for a kind of thing your business keeps track of — customers, properties, equipment, jobs — and it’s named the way your team talks.

Each classification holds:

• Record schemas that say what you keep on file for each thing, built from reusable data schemas.
• Topics, the individual things themselves — one topic for each property, customer or piece of equipment.
• Resources, classifications nested inside it, when something belongs to one particular topic, like a site survey that belongs to one property.
• A security policy that decides who can reach all of it.

Together, classifications form a connected network of data that mirrors how the business actually works. A customer connects to their properties, and each property connects to its service history.

Good habits for modeling

The Atlas video series recommends a few habits that make classifications work well:

1. Name the things, not the tasks. Properties and Customers, rather than Inspecting or Billing.
2. Make one classification for each kind of thing you keep track of.
3. Decide what stands alone. A data module sits at the top and its topics stand on their own. A resource sits inside a data module, and each of its topics belongs to one topic of the module. Resources go one level deep, so decide early.

Modeling your business in Atlas works through an example from start to finish.

Your interface, if you want one

Some businesses want more than a better data model — they want their own interface on top of it. Enterprise subscribers can integrate their own custom user interfaces directly with Atlas. Those interfaces use Atlas’s APIs to manage classifications, schemas and records, so you keep full control over presentation and workflow while Atlas provides the secure, scalable backend.

That’s what the Atlas features page means by a “highly customizable CRM powered by Atlas’s microservices architecture”: not a fixed CRM with your data squeezed into it, but a CRM shaped like your business. See Atlas as the backend for your own applications.

Should you replace your CRM?

Not necessarily. If a sales pipeline is genuinely the center of your business, a sales CRM may be the right tool for that job. Atlas is a strong fit when:

• the thing you track most isn’t a lead or a deal,
• your records have real structure and relationships,
• the same information is collected through several forms, and
• you want forms, records and permissions to follow your own model.

A worked comparison

Here’s how the same business — a property maintenance company — might be represented in a sales-oriented CRM and in Atlas.

The difference isn’t that one tool has more features. It’s that in Atlas the core thing the business tracks — the property — is a first-class part of the model, with its own records, its own resources and its own access rules.

Questions to ask before you switch

Changing systems is a real commitment. These questions help you decide whether the mismatch is worth fixing:

1. What’s the one thing we track most? If it isn’t a lead, contact or deal, a sales CRM will always need workarounds.
2. How many side spreadsheets do we keep? Each one is a place the CRM couldn’t hold something.
3. How many forms feed the CRM, and how are they connected? Manual connections are a sign the data model is split.
4. Who needs to see what? If access needs to follow your own structure — region, site, team — you need a model that has that structure.
5. Will we build our own interfaces? If so, a backend that follows your model will save a great deal of work.

A phased approach

You don’t have to replace a CRM in one move. Many businesses start by modeling the part the CRM handles worst — often locations, assets or service history — in Atlas, keeping the CRM for what it does well. Topics in Atlas can carry an External ID that holds the matching record’s identifier from the CRM, so the two systems can always be cross-referenced. As more of the business moves into Atlas, the CRM’s role naturally narrows.

What stays the same

Whichever way you go, the fundamentals of good data don’t change: define information once, give each record an owner, and control access by need. Atlas simply builds those fundamentals into the product. For the underlying ideas, see What is business modeling? and Entities, attributes and relationships.

Next steps

Watch the Enterprise classifications episode to see a classification created from start to finish, then read Create your first data classification.