Specifying CRM functional requirements – twelve things that often get missed

March 3, 2015September 16, 2018 Richard Boardman

In the ‘how to document CRM requirements’ series (part one, if you missed it, can be found HERE, part two HERE, part three HERE, part four HERE, part five HERE, and part six HERE, or all of them in an ebook HERE) noted that there were a lot of areas that people tended to miss when setting out their functional requirements for a CRM system. So the following is a list of twelve items that commonly don’t get fully specified, but may just be important:

Customisation capabilities – most systems require at least some tailoring in order to meet an organisation’s specific needs. This is almost certainly going to require the ability to add new fields, or hide existing, ‘out of the box’, fields, but is often likely to require the development of new custom records, beyond the standard system entities.

Workflow management – in the same vein, when you’re adapting a system to tightly support your business processes, workflow functionality, which allows you to automate actions, for example, if the value in a field changes to ‘X’ send an email alert to user ‘Y’, can be a key capability.

Compatibility with existing infrastructure – I’ve seen some businesses forced to make hefty unforeseen investments in areas such as PC’s, servers, operating systems, desktop software, and email, because their new CRM system proved not to be compatible with their existing infrastructure. If there are standards you need a vendor to adhere to, it’s important these are made clear up front.

De-duplication – maintaining data quality is key to a successful system. Being able to identify potential duplicates, both when a record is being entered, as well by scanning the system to find potential matches is important. As is the means to merge identified duplicates.

Offline access – despite the ubiquity of internet access, there are situations where you may need users to be able to operate offline. For example, you may have users in locations where there isn’t reliable internet access, or who are travelling a lot. In these cases an option to work offline can be an important consideration.

Language and currency – for those with international operations, the ability to support local character sets, translate field names and pick lists, manage different date formats, and track and report on transactions in different currencies, may well be key requirements.

Email integration – a lot of key information can end up locked up in the email system, so an easy ability to write incoming and outgoing emails back into the CRM system from your email platform of choice is generally essential.

Calendar integration – ideally you don’t want to have to maintain activity information in two systems, which means that integration between CRM and the organisation’s calendaring application, so that, for example, a meeting scheduled in CRM is automatically visible in the corporate calendar, may well be needed.

Mobile – mobile access is an increasingly important aspect of CRM use, and it’s important to define aspects such as what platforms need to be supported, whether offline access is required, and if customisations made on your main system carry over to the mobile client.

Different views for different users – if you have users accessing your system for a wide range of reasons, then being able create different views of records based on the user, for example, members of the new business sales team might need to see very different fields on an opportunity record, than say the account management team, may be a very desirable capability.

UAT and training versions – when you are testing changes to your CRM or training users, you ideally don’t want to be doing it on your main live system because of the potential to damage data and functionality. Therefore having the right to create separate test/training environments if you are licensing software, or have access to what’s typically known as ‘sandbox’ environments if you are looking at cloud-based systems, can be important.

Security – perhaps one of the most important functional areas that gets missed is security. I’ve seen CRM projects grind to a halt because the client’s security requirements don’t fit with the selected CRM’s out of the box capabilities. It’s therefore critical to think through, and document up front, any requirement to limit access to data or functionality.

While this isn’t, and isn’t meant to be, an encyclopedic list of potential CRM functionality, the highlighted areas are important by virtue of being commonly overlooked, potentially very important to the success of a project, and that there are significant differences between CRM products, and versions of products, for example the feature may be available in the enterprise edition, but not the professional edition. While a lot of CRM software applications may look similar, there are often significant functional differences, so taking the time to specify as fully as possible your functional needs, is generally a wise investment of time.

Footnote – the how to document CRM requirements series is available as an ebook which can be downloaded from HERE.

Footnote 2 – if you would like someone to develop your CRM requirements for you, please feel free to contact us HERE.