Does it really matter?! Does anybody care?! Well, yes and yes! The distinction between each isn’t huge, but it does have an impact on what you can expect from each, how we talk about each element, plus the time and effort associated with implementing them.

The differences (a beginners guide)

Website

In basic terms, the “website” is usually referencing the outward-facing site for the organisation – the lovely widgets, content and interactivity (if you’re lucky) falls under this banner.

CMS

In contrast the “CMS” (Content Management System) is the framework on which the website is built – the back-end tools that allow for the adding of the widgets, content and security options. Drupal, SiteCore, Umbraco, Preside etc. are examples of CMS platforms.

This isn’t dissimilar to the concept of a CRM’s front-end and back-end, but the front-end is often a lot prettier on the website as its focus is on providing an eye-catching and engaging experience for the visitor.

Portal

The “portal” is a little more complicated a term to define because it can often relates to one of two approaches – something that lives within the website, or something which is embedded into the website using another system. To the outside world it’s one entity, but it’s essentially two websites with one sitting inside the other.

The classic Member Portal which offers secure login and access to documents, renewal options and other member-restricted content could be provided using either approach.

Previously, portals would need to be created either on the CRM or CMS-side from scratch, but a number of CRM technology providers are now building those alongside their core CRM solutions in order to make it quicker and easier to offer these features without having to either build from the ground up, or get caught in an integration to-and-fro with a website provider.

When talking about the pros and cons of an embedded CRM portal, you can view them against these broad points:

Pros 

  • Largely pre-built, defined features
  • Little integration work required (or only small tweaks) with the CMS provider
  • Little collaboration required from the website provider for functions to work
  • Cheaper than building core functionality from scratch

Cons

  • Can look a little (or a lot) out of place in relation to the main website
  • May not be able to be extended easily in terms of what it does, and how it does it

Beyond a pre-built portal

Beyond using a pre-built portal, the next option is to then look at a more considerable website integration. This requires teamwork on the part of your tech partners to expose bits of their technology to one another in order to pass data backwards and forwards – membership renewal payments, categories that allows certain access etc.

That approach can often result in the most seamless outcome, but it does rely on more leg-work on all sides, including from you to dictate what you want and how you want it to work. The benefit though is a finished article that just looks like it’s all part of the bigger website journey, and that there’s nothing to take you away from the main site you’ve visited.

Pros

  • More control over how it works for a user, and what it provides
  • Should appear seamless within the website

Cons

  • Requires more coordination/collaboration between CRM and CMS providers
  • Can cost more in time and money, particularly if either party causes delays for the other
  • Relies on a clear vision and direction of what functions should be provided, which requires clear direction

Go onto many smaller charity websites and you’ll often see examples of the CRM partner-style portal approach when it comes to signing up to Direct Debits – you’ll go from nicely-branded, consistent pages to something that looks at odds with the main site when you try to sign up.

This is the worst-case scenario obviously – the best is when you really can’t tell the difference and it does nothing to affect the visitor’s journey through the content.

The above are broad categorisations, but do show that there’s a distinct difference between each term, and most importantly a need to nail down what you want and expect when you’re talking about your requirements and using those terms.