CRM vs CMS: what each one is for

The short answer

They meet in exactly one place: the contact form. The CMS renders it, the CRM receives what it captures.

Where the confusion starts

Three reasons, all understandable.

• WordPress plugins are sold as CRMs. Some genuinely store contacts, but they store them inside the website's database, which is the wrong place for the record your sales team lives in.
• Marketing platforms blur the line deliberately. A tool that hosts landing pages, sends email and stores contacts looks like both, and is usually weaker than either at the parts that matter.
• Agencies quote a website build and mention a CRM, meaning the contact form will email someone. That is not a CRM, and clients find out six months later when nobody can say where last quarter's leads went.

Why a website plugin is rarely the right home for customers

It is not about quality. It is about where the data lives and who touches it.

1. Website databases get restored from backups when a theme update breaks something. Restoring last Tuesday's pages is fine. Restoring last Tuesday's customer list is not.
2. Website hosting is tuned for reading pages fast, not for reporting across thirty thousand records.
3. Access control is inverted. The people who need the customer data rarely need to edit the website, and the people editing the website should not see every customer's phone number.
4. Migration later is painful, because plugin data models are shaped for the plugin, not for your business.

How the two should work together

The connection is simple and worth doing properly.

1. Every form on the site posts to the CRM, with the page and campaign recorded, so you can report which pages produce enquiries that turn into revenue.
2. The CRM replies to the enquirer within seconds, automatically, in your words. Response time is the single largest predictor of whether a web enquiry converts.
3. The CRM assigns an owner and creates a task. An enquiry with no owner is an enquiry nobody calls.
4. Where useful, the CRM writes back: a customer portal, a members only area, or listings and products rendered into pages by the site.

We build this into every project, and the pattern is described on the CRM integration page.

If you are buying both at once

Buy them as two decisions. Choose the CMS on how easily your team can edit pages without breaking the design. Choose the CRM on whether it models your records and stages. A vendor that sells you one because you need the other is optimising for their invoice, not your operations.

On the client sites we build, the site itself is static HTML with a visual editor installed, and the CRM is separate and connected by the form. Two systems, each doing one job well, neither able to break the other.

The four things people mean by CRM on a website

When a business says we want CRM on the website, they mean one of four things, and each one has a different answer. Sorting out which is meant takes five minutes and saves a bad purchase.

Capture. Forms that reach a human reliably, with the source recorded. This belongs on the website, and it is the one thing the website must do well.

Follow up. Something that chases the enquiry until it is answered. This is CRM work, or in some businesses marketing automation work, and it does not belong in a page builder plugin.

A customer area. Logged in customers seeing their own jobs, invoices, documents or bookings. This is a portal that reads from the CRM and renders on the website. Two systems, one screen, and the data stays where it belongs.

Personalisation. Showing different content to different people. Real, and almost always the last thing a business needs rather than the first. It also requires the customer record to be trustworthy, which is the work people skip.

What belongs where

The split is not arbitrary. Website software is optimised for publishing to anonymous visitors at speed, and customer software is optimised for reading and writing records under permissions. Put a job in the wrong one and you fight the tool for years.

One consequence catches people out: the website should be replaceable. If a redesign next year means rebuilding your customer database, the customer database was in the wrong place. We install a CMS and CRM pairing where the site can be rebuilt from scratch without touching a single customer record.

The form is the seam, and the seam is where things break

Almost every failure we are called in to fix happens in the same six inches of the system: between a form submit and a record existing.

The single most common defect is a form that sends an email and stores nothing. It works for years, then a mail rule changes or a filter gets stricter, and enquiries vanish with no error anywhere. Nobody notices for weeks, because a missing enquiry looks identical to a quiet week. Store the submission first, in your own database, then notify. Notification is a convenience; the record is the asset.

The second is ownership. A record with no owner and no due task is a record nobody replies to. Every form we build assigns an owner by rule and creates a task with a deadline, and the report we ship first is enquiries without a first response inside one hour.

The third is attribution. Source, campaign, landing page and referrer have to be captured at the moment of submit, because nobody can reconstruct them afterwards. Without that you cannot answer which marketing works, and you will end up defending spend with anecdotes.

Connecting a nonprofit website to the CRM

Charities and member organisations feel the CRM and CMS split more than anyone, because their website does four jobs at once: donations, event bookings, membership renewals and volunteer sign ups. Each one creates or updates a person, and each one usually starts life in a different plugin.

The integration that works treats the CRM as the only place a supporter exists. Every form posts to it, matches on email, and adds an event to the supporter's history rather than creating a new record. Gift Aid declarations, consent choices and membership expiry dates are written to the CRM and never stored only in the website database. The website shows what the CRM knows, for example a member's renewal date, but it does not own it.

Get that right and the annual question of how many supporters you actually have has one answer. The nonprofit CRM page shows the full record.

CRM website examples worth copying

The best examples of a website and CRM working together are dull to look at and very effective. Four we build often:

• A quote request that creates a lead, assigns it by postcode and sends the visitor a confirmation naming the person who will reply.
• A booking page that reads real availability from the CRM schedule instead of a separate calendar plugin.
• A customer portal where clients see their open jobs, documents and invoices, served from CRM records.
• A renewal page that loads the member's details, so renewing takes one click instead of a new form.

In each case the website is a window onto the CRM, not a second database. That is the design principle behind our integration work.

WordPress CRM plugins, and what happens at scale

We are not against them. For a business with a few hundred contacts and one person following up, a well maintained plugin is genuinely the right answer, and paying us would be silly. It is worth knowing where the ceiling is before you cross it.

The database is shared with your website. Contacts, notes and deals sit in the same tables as posts and page builder metadata, usually in the options and postmeta tables. At twenty thousand contacts with activity history, queries that were instant become slow, and the thing that gets slow is the public site, because it shares the database.

Your customer data inherits the website's risk profile. A WordPress install is a public target with a plugin surface that changes weekly. Putting your entire customer history behind that surface means every plugin update is a data risk, and an abandoned plugin becomes your problem on a schedule you do not control.

Permissions are page permissions. WordPress roles were designed to decide who may publish. Asking them to decide who may see a salary, a medical note or a client's financial position is asking the wrong question of the wrong system.

Reporting stops at the plugin's imagination. When you need revenue by source by month by salesperson, you are either exporting to a spreadsheet forever or writing SQL against tables you do not control.

The practical line, from the migrations we have run: under roughly five thousand contacts with simple follow up, stay. Past that, or the day the data becomes regulated or the reporting becomes a board pack, move it out. The detail is in using WordPress as a CRM.

Moving customers out of WordPress without a bad weekend

The migration is routine if it is done in this order. We have done it enough times to have stopped improvising.

1. Export everything, including the tables the plugin uses for notes and custom fields. Count the rows and write the number down, because that number is the only thing that proves the migration worked.
2. Decide the identity rule before importing. Usually email, then phone, with a documented policy for merging duplicates and a record of what was merged into what.
3. Import into the new system with the original identifiers kept in a legacy field. This makes every future question answerable and costs nothing.
4. Point new form submissions at the new endpoint while the plugin still exists. For a week both receive, and you compare counts daily.
5. Cut the plugin's ability to receive, leave it read only for a month, then remove it. The month is cheap insurance.
6. Rebuild the reports on the new system and compare last quarter's numbers against the old ones. If revenue by source does not reconcile, something did not come across.

Nothing here requires downtime and no email address needs to change. Data migration is the one service we quote lowest, because the process is standardised: see CRM data migration.

Cost and risk, side by side

A twelve person service business with about eight thousand contacts, comparing the three realistic routes over three years, in US dollars.

Read the table as a sequence rather than a choice. Most businesses should start in the first column, and most should never leave it. The move to the third column is worth making when your process stops fitting anybody's template, or when the per seat line has grown past what a build costs once.

The customer portal, where the two finally meet

Once a business has both systems working, the next request is nearly always the same: can customers log in and see their own information. It is a good request, and it is where the boundary between CMS and CRM has to be drawn deliberately rather than accidentally.

The right architecture is dull. The CRM holds the data and exposes a narrow, authenticated read for exactly the fields a customer may see. The website renders it. The portal holds nothing of its own, caches almost nothing, and can be deleted and rebuilt without any consequence for the records behind it.

What customers actually use, in order of how often they ask for it: outstanding invoices and a way to pay them, the status of a current job or matter with the next date on it, documents they have signed or need to sign, and a history of past work with the ability to reorder or rebook. Almost nobody uses a message centre, and we now talk clients out of building one, because an email that lands in the CRM works better and nobody has to remember a password to use it.

Three rules we apply without exception. Authenticate against the CRM, never against the CMS user table, because website accounts and customer records are different things and conflating them creates a permissions problem you cannot reason about. Expose fields by whitelist, never by hiding them in the template, since anything the page can fetch is public in practice. And log every read, because the first serious question a regulated client asks is who looked at what.

Done this way, a portal is a two to three week addition to an existing CRM rather than a new system. Done the other way, by growing it inside the website until it holds the only copy of something important, it becomes the thing that makes the next redesign impossible.