Now you’ve got a handful of processes, owned by a key team, you’re in a good position to start writing the spec. In this blog I’ll cover 9 things you should consider.
A good spec. lets suppliers and colleagues know exactly what the new system will look and feel like. It also helps the testing and roll- out phase of the project. You can use it to create test scripts and identify any issues.
During my first implementation I knew what we needed but didn’t have a clear idea of how I would put this on paper. The key thing here is to work with suppliers and colleagues in the business to come up with a document you all understand. Add as much detail as possible, consider legacy data and other systems so you end up with a great first run at it.
Before you get to the nine items I’ve added a few other things to consider as you walk through the spec. You can tailor each one to your needs, level of integration and what you’d like to achieve. But they should help you get off the ground.
Are you looking to build a new entity or adapt a current one?
See what you can use ‘out of the box’. Bespoke CRM systems are difficult to maintain and can make upgrading slightly more difficult. However, sometimes it needs to be done to get the process, security, or outcome you need.
A new entity
Will this sit in the sales arena or is it more service? Would you go to a person record to access your new entity or is it attached to an organisation?
Amending a current entity
This can make life easier because you’ll know how that entity should react and what it’s capable of doing. Be careful not to be too reliant on a single entity. Overloading them with fields, workflows, views, or scripts can affect system performance. There are several functions available to get the outcome you need without the cost and time of developing.
Here are the 9 things to consider when putting you together the spec:
- The fields users need;
- What type of field (text, numerical, picklist etc.)?
- What information will be held in them?
- Should they be a certain format (e.g. you don’t want users entering 2 numbers into a mobile phone number field)
I prefer to use picklists (option sets); they keep data clean and users can quickly become confident. Use your process maps to choose the fields you’ll need and what information to store in them. I try to avoid free text fields; they can be tricky to report on and the text in them can be open to interpretation. Beware…users love them!
You may also want fields to call functions or act differently depending on the information provided. For example, selecting ‘yes’ on a Boolean field may open another section of the form or display another field (attribute)
Use fields sparingly. They can quickly clutter the form and ruin the user experience. Less is more if the product does what you need it to.
- Information you’ll report on
What reports will you need? Refer to the key aims of your CRM delivery;
- Do you need to add certain fields/functions to get the reporting you need?
- Should fields be populated all the time or only under certain circumstances?
If the information isn’t available, the reports will be weak. This can negatively affect the attitude of senior teams to CRM….and user adoption.
Workflows are great. They can be simple (if I’m involved) or complex. They aren’t essential but can make for a richer user experience. For example, a workflow can be triggered to notify other departs if a customer says they’re going to make a payment on a set date. No need to remember the name of all 15 colleagues who need to receive an email; the workflow can send a task to other users, teams or queues. I’d note all the workflows you need. Some can happen when a record’s created or the value of a field changes, the choice is yours. Just make sure you clearly explain what you expect the flow to do.
- Data from other systems
Some users may feel every piece of information should be pulled from your legacy system into your shinny new CRM system. Sometimes, they’ll be right. Before you jump in and create masses of integration, it’s worth considering if a view or Iframe is more appropriate. When you spec out a view, you need to identify the data required (down to field level) and where it’s stored. Work with users to understand what they need and when they need it. You also need to know the entity the view should be available on. For example, should it be added to the contact entity to answer more queries first time?
- Out of the box vs bespoke
Looking back, I knew I wanted to build a CRM solution which met everyone’s needs and was essentially a reflection of the old way of doing things. There are companies who rip everything out of CRM and build from the ground up. If this suits your business, go for it. However, there are numerous out of the box functions you can use from day one without spending £000’s. This issue is compounded when you try to upgrade and need to test all the bespoke functions, entities and scripts. Take some time to reflect on the product and functions which could deliver the processes you mapped at the start of the project. There are plenty of conferences, demos and companies out there who are willing to help and advise.
- Managing legacy data
This is another enormous and complicated topic. Work with the team to identify the data they need in CRM. You can limit access to the old data and then remove it completely once you’ve adopted CRM. Add this to a more long-term plan so you don’t have old data hanging around waiting to cause trouble.
- Phasing out legacy systems
Identify the impact on any other systems when you change CRM. This may not be an issue day one but, as CRM grows, it will start to integrate with other systems.
Pull everyone in early if you know which systems the project will impact. You won’t know everything (who does?) so invite the teams to offer input and advice as it may affect costs and timescales. Installing CRM may improve other systems but be aware these changes may mean additional users need training.
CRM provides various options when it comes to security. From field level to entity, teams or organisations. This, like most of CRM, will be very specific to the piece of work you’re doing. Although data protection is something you must follow, you don’t want to prevent users from getting access to the information which will make it easy for them to do a great job.
Create a security matrix to understand who should have access to different parts of the system.
The finished specification can look confusing. A simple mock-up of the system can help ‘visual’ learners and encourage the discussion to flow. You don’t need anything complicated; a simple spreadsheet with rough colour schemes and field layouts can help colleagues understand how the product will work.
As the build starts, you’ll understand how the system will be used and the benefits it will bring. Track these and communicate them to all the stakeholders.
If you found this blog useful don’t forget to leave a comment or take a look at the ebook I’ve written to help those non techies about to start their CRM system journey.