By Sandor Schellenberg, Owner and Founder, friendlyITsolutions

I have worked on many Microsoft Dynamics CRM implementations and over time I have served in a versatile set of roles. I have been part of the team responsible for designing, building and testing a CRM application, i.e., the implementing party side. I have reviewed implementations for customers that needed a fresh view on their new CRM application.  I have also been involved in taking the CRM application into support as member of the IT department.

The road to your CRM application's go-live is not always smooth, and all parties involved face different challenges. In my experience there are usually two topics related to support that are easily overlooked or neglected. In my earlier ‘musings' I addressed the first topic - data migration. The second, which I know from my own experience, is preparing for and managing post-go-live support. In most project management methodologies, the phase after go-live is typically planned for a week or, if you are lucky, even two. After this period the project team is dismantled and CRM is officially in support mode.

Who writes it down? Why? And for whom?

The first question that comes to mind when talking about support is the infamous "D" word. I know from my own experience that this is the least favorite task of every consultant, and yes, it is documentation. Of course, we all know that documentation is important to an enterprise software project because it can be used to instruct new colleagues, to guide new development, to give insight into a solution's architecture, testing, and so on.

Most CRM documentation has one thing in common - it is written from inside the project where the authors have good insight into the in's and out's of project like important decisions, design choices, and requirements. Documentation written from this perspective often causes issues for those who receive it from the project team as part of the process of taking responsibility for the application in support. The support team usually does not have the insight into the project that adds context to this type of documentation - things like knowledge about choices, functionality details, dependencies of code, integrations, etc.

The support organization

The requirements of documentation also depend on the role of the support team. For supporting your CRM application you will typically have two roles: functional and the technical support.

To support your CRM application from a functional point of view, you would need to know what kind of functionality was required by the business.  The functional support engineer needs insight in the CRM project team's functional design, workflows and a basic understanding of integrations. For example the engineer would need to know the process for setting or maintaining a customer address that is outdated.

The technical support engineer needs to have insight into general functionality of your CRM application as well as detailed information about areas including workflows, data integrations techniques used, location of log files, and other customizations and configurations. In general, if something is not functioning well, then the engineer needs to know where to gather the information to start debugging.

Beyond the specific functional and technical roles, there is the question of how support fits into an organization. In small organizations it could be a combination of power users from the business and your system administrator. In larger organizations the support team's structure is often more sophisticated, organized into knowledge areas for systems like Active Directory, Exchange, Firewalls, Desktops, and other legacy software. Your CRM application requires expertise from various knowledge areas, and you will face the challenge of setting up a support structure that works closely with other internal departments or third parties. In daily life, CRM support is like the spider in the web, working and coordinating with several other teams.

Of course in a small organization the red tape for such a team is not too bad. But in midsize to large companies it is not unusual to see several departments or even external parties involved in providing and receiving support. It can get even more challenging if every department uses its own standards and service level agreements(SLA).

The support process

When an incident is reported, the engineer for the CRM solution needs to rely on documentation, as well as functional and technical understanding of the system, to determine whether the issue originates with CRM or one of the related systems.  The bottom line for supporting your CRM application is that it requires both the focus on the application itself and the ability to take advantage of the expertise of the larger support organization. This sounds like a major challenge, and it is. But setting up optimal CRM support requires the cooperation of people with different knowledge areas and expertise.