DSC Tech Library
This section of our technical library presents information and documentation relating to CRM Applications and Customer relationship management software and products. Providing customer service is vital to maintaining successful business relationships. Accurate and timely information provided in a professional manner is the key to any business and service operation.
Our CRM software application TELEMATION, was developed with this in mind. But the ability to change is just as important in this ever changing business environment.
Telemation call center software was designed from the very beginning for this environment.
Many call center managers, with unique and changing requirements, have chosen and continue to use our CRM software as their solution of choice.
Our contact center CRM solution is ideally suited for call center service bureaus.
Will Vendors ever be able to understand user requirements?
By: Enigma Business Consultants
Recognise any of these? "If we go vanilla we can implement it sooner", or "We can deliver anything you want (at a price)", or worse still "These entity diagrams are your processes."
These, and many similar examples, can be found in the murky world of 'CRM Requirements Capture'. Even with the best programme management capabilities this side of an ant colony, if your documented requirements are wrong then no amount of Prince2 is going to deliver a system that meets the users .
So, can Vendors effectively understand and detail your CRM requirements? On the face of it the answer is.... well lets wait until the end of this article.
Being operations specialists inevitably mean we get involved in major IT projects. This enables us to watch vendor/client interaction at close range providing microscopic views of the requirements capture process and how it can cripple a project if performed incorrectly.
The first thing that becomes apparent is the gap between the vendor’s technology-driven view of the CRM problem and the client’s organisational/commercial perspective. The very language used gives it away. One speaks in technologese the other clearly doesn’t. Thus, it materialises that one side doesn’t understand IT functionality and capability and the other has no idea how operations really work.
This lack of common understanding enables the pursuit of all sorts of risky approaches to CRM requirements capture. Take the ‘going pure vanilla’ approach, often used with the best intentions of speeding up the CRM rollout. Here we end up with a CRM system that goes in quickly but then comes to a grinding halt because users dismiss it as useless.
Take another example where the IT department writes the user spec, usually as part of the draft functional spec for the Tender process. This is invariably rushed, poorly written and results in a bid that completely misses the real business need but is a fine match with systems architecture.
But let us not be too hard on the Vendors or over-worked IT Departments. Given half a chance, users will want the earth and change their minds constantly. Managing this varying complexity, along with balancing costs and timescales can test anyone’s staying power. So, getting the user community, at all levels, to quickly detail what they want in a concise unambiguous format is no trivial task.
But before moving onto what approaches to requirements capture may work we have to do some sanity checking. Buyers of IT systems must understand that you cannot computerise a mess and expect things to get better. If you have an operationally broken business then sticking in a CRM solution is not going to fix it. IT driven change is inherently risky unless the broken or inefficient processes are correctly redeveloped first.
After spending £12m on a brand spanking new CRM solution, one client found that it took 200 keystrokes to load an order and a visit to 5 separate screens, whereas on the previous system the same task could be done in 90 keystrokes on 2 screens. Order load speed goes down, data entry errors go up.
What is needed is a structured approach that can bridge the technology and business divide. Getting the user community to imagine what the system could look like, and documenting the requirements as though it already exists, is a powerful starting point. This ‘vision’ of the new way of working can be later refined in light of technological capability. Building the CRM requirements downwards from a high-level operational strategy, through more detailed business processes, and finally down to procedures and work instructions ensures that there is a logical traceable link between your strategic aims and what key you press to get things done.
So, who can sit in both camps to develop the lingua franca that enables client and vendors to effectively communicate? Is it the vendor? For me, the jury is still out. But why take the risk? There is too many examples of where it has gone wildly awry.
Enigma Business Consultants have established themselves as experts in developing and improving customer service delivery operations. Enigma’s innovative integrated business operations solutions can be applied to multi-channel contact centres, sales operations, service provision activities, customer support departments, field workforce management and billing systems. In order to help managers through the myriad of vendors and applications in the marketplace Enigma have recently launched SST – Systems Selection Toolkit. SST provides managers with a structured approach to the specification and selection of customer facing IT solutions.