While functionality (the features) is not the one and only piece of the requirements list, it's clear that no CRM system will ever be successful without the appropriate functionality. Sure, you could love the vendor, the technical architecture, the services offered, and the price, but in the end the functionality is the impetus for the project.

Who Determines the Functionality Requirements?

The business owners and the super-users are the team members who have the best expertise to design the functionality requirements. I'm not saying that the business owners can do it single-handedly. While the business owners can see the strategic goals for the organization and how the CRM tool can meet these goals, they are removed from the day-to-day tasks of the average individual contributor, especially in a large organization, and they may miss critical functionality. I remember a Support VP who focused obsessively on how well the support-tracking tool could help him manage escalations, which was the customer-related task that filled the most hours in his days, but somehow neglected to bring the same level of attention to how support cases were created in the tool, a task which clearly was the most-frequently performed task in the support group as a whole. The tool ended up with a complex and slow case creation process (which was the out-of-the-box process, to be honest) when it should have been clear that this common task needed to be optimized in priority. No super-user would have neglected the case entry screen!

Techniques for Specifying Functionality Requirements

It's often difficult for super-users and business owners alike to get to the functionality requirements because they find it difficult to translate business processes into tool requirements. Here are some suggestions for how to proceed, from basic ideas useful when processes are already well-defined and working well to more exotic strategies that may be required if the processes are in need of formalizing or changing. revisits these ideas from the perspective of the detailed implementation requirements definition. A simple and very effective way for the super-users and the business owners to organize their requirements definition is to diagram the business processes. Pictures are worth many words and a simple diagram of the sales process, with the various stages and owners, should make quite clear what routing is required, what level of collaboration is required amongst the sales team, and how the tool should handle generating proposals, to name but a few examples. There are many formal methods for diagramming processes and you should feel free to use the ones you like. My experience is that business users respond better to a simple and informal approach to diagramming as opposed to funny-looking boxes and spaghetti-like multi-page diagrams, so let them doodle and encourage them to stay with a relatively high-level diagram (say, one page). Such a casual approach may not suffice with larger, more complex organizations, or organizations that have never used formal processes but now need them. If that's the case, you may want to proceed to a formal task analysis, where roles and tasks within the organization are explicitly defined. Task analysis can be combined with diagramming techniques, of course. You may encounter a deeper issue. Sometimes both business owners and super-users share a certain lack of imagination about what the tool could do as opposed to what the current tool does do. Worse, they get hung up on how the current tool does things. Often the best way to do something (track a sale, manage the knowledge base, hand off a case) is not to reproduce the current process, especially if the process is manual, but rather to approach the task in a new, more efficient way. You don't want to write your functionality requirements to read, "do what the current tool does", especially if the current tool is not working well! What you need is a touch of re-engineering, a fancy and somewhat fad-sounding concept for creating new processes. While a full discussion of re-engineering techniques is beyond our scope here, you can use the following easy techniques to get the business users going on a more inventive road.

  • Include on the team some individuals that have used other tools in other jobs, preferably the types of tools that are likely to be considered during the selection process as opposed to older or homegrown tools. Such individuals should be able to contribute fresh ideas, that are implemented in an existing CRM tool so they have a good dose of reality in them.
  • Ask the IT owner or other knowledgeable technical resource to work with the business team. It's useful to choose someone who has experience with other CRM tools, but a good facilitator who can ask "how else?" and "why?" questions can do very well with minimal knowledge.

The business owners may have trouble thinking in the abstract terms of functionality and features and they may want to draw screens at this point. Now is not the time for screens (we'll get there in the implementation phase), so the project manager or the IT owner may need to lend a hand to elevate the debate as required. It's fine to specify uncluttered screens or one-click functionality for specific tasks as long as you stay away from screen layouts.

Functionality Requirements

The discussion of functional requirements below is formidably long because CRM systems are formidably rich. Remember that this is an inventory and you do not need each and every requirement listed. For starters, entire sections may not apply: don't bother with marketing automation if you don't need that, and don't bother with wireless communications if you don't need them. Even for sections that do apply to you, take only what you need: most functional requirement lists are way too long! Focusing on the essentials not only accelerates the selection process, it also increases significantly the quality of the fit of the tool that's chosen. It's best to spend more time exploring fewer requirements in more depth than lightly touching hundreds of requirements and running the risk of missing some important points in the process, when some of the requirements are just wishful thinking or perhaps won't ever be implemented. Another key point to keep in mind when defining functionality requirements and when evaluating potential candidates against the requirements is that simplicity wins. Fancy, convoluted solutions are usually not the best because they can be too complicated for users. Whenever possible, strive for solutions that require as little effort as possible. The first section is about those areas that pertain to all functional groups (marketing, sales, support) and is followed by sections for each functional group.

Cross-Functional Requirements

This section includes requirements that may apply to any business function. We start with communication channels since a basic requirement for CRM systems is to handle the channels you currently use when communicating with customers such as email and phone, and perhaps some additional ones that you want to add as part of the CRM project (and some CRM projects focus solely on adding channels, such as chat).

Phone Integration

If you have call centers, whether for marketing, sales, or support, you may want to integrate the CRM tool with the phone switch through computer-telephony integration (CTI) software. This would allow you to validate and route customers based on information gathered by the phone system; to do screen pops, that is, to have screens painted with appropriate customer information a split second before the call is presented on their phone; and to automatically dial phone numbers, either for a specific customer or as part of a list.

  • Specify exactly what kinds of interactions you are looking for, as you will want to check at that level of detail during the evaluation phase. Do you wish to do entitlement checking? Screen pops? Outbound dialing?
  • If you already have a switch or CTI software, check whether the tool supports them unless you are open to changing them.
E-mail Support
  • E-mail integration. Do you want users to send e-mails from within the CRM tool? Should the messages be logged into the system? Are you open to using the CRM's native e-mail system or do you need to link to the existing e-mail system? Should outgoing e-mails be tagged in particular ways (typically so they can be recognized from a response)? Do you wish to send bulk e-mails from within the tool?

    Should incoming e-mails be automatically loaded into the system? What processing, if any, needs to be done on those messages (such as creating a new prospect or a new support case, or adding e-mails to an existing record)? Since you are probably behind a firewall, what kind of firewall compatibility do you require?

  • E-mail processing. Do you need automatic acknowledgements on e-mails? Do you want the tool to route e-mail requests? Based on what? This item is directly related to whether you want to encourage customers to place requests via e-mail or via a portal. Portal communication is much more structured than e-mail so I would de-emphasize e-mail routing in favor of a more powerful portal. You may feel differently, especially if your customers are used to communicating via e-mail and would balk at switching to a portal.

    Are you looking for a tool that supports canned response templates from which the users can select the appropriate one manually? Or do you want the tool to suggest the proper answer? Or do you want the system to dispense entirely with humans when it "knows" the answer and to send automatic responses?

  • E-mail utilities. Is spell checking available for outgoing e-mails? What formats are supported? (This is moot if you require integration to your e-mail system, of course). Do you need e-mail templates? Should attachments be allowed?
Customer Portal

Customer portal functionality is a very special channel because it's so rich.

  • Authentication and security. Although the knowledge base is often accessible without barriers, you may want to protect even that part of the portal with an authentication scheme if you feel it would provide too much information about your products to your competitors. Would you like to use an existing authentication scheme from another part of your web site? What kind of signup functionality would you like? (Self-registration? Manual registration?) What type of authentication scheme is required to maintain security? More stringent schemes are required if you must protect sensitive personal information.

    Once customers have access to the portal, do you need a flexible permission scheme, for instance granting more privileges to your partners (to see more documents, or to see their customers' records for instance)?

  • Personalization. Do you want to deliver a different portal experience based on customer characteristics? What would the characteristics be? How deep should the personalization go?
  • Knowledge base. Can the customer access the knowledge base from the portal? What types of search functionalities are required (FAQs, text search, natural language processing, tree search, advanced search)? We'll talk about the knowledge base more in an upcoming section.
  • E-commerce. Should the CRM tool allow customers to shop and place orders? What integrations, if any, are required there? Note that few CRM tools offer fully featured online shopping environments, although some may be adequate for simple stores.
  • Order tracking. Should customers be able to track their orders online? What integrations are required to make that happen if the order records are not in the CRM database? Should customers be able to modify their orders online?
  • Service/support case entry. Do you want to allow customers to place requests for customer service or technical support from the portal? Probably yes: this creates significant cost savings in service and support operations. If you decide to go this route, you may want to de-emphasize e-mail issue logging.
  • Online case management. Should customers be able to view the progress of their cases online? If so, you will want to require some facility to hide sensitive (or boring!) bits of the case records from customers. Pay close attention to how flexibly this can be done. Can customers add comments to cases, or is it a read-only facility? Can they close cases online? Reopen them?
  • Customer forums. Would you like customers to collaborate to discuss or resolve issues? What kind of control do you wish to have on the forums? Do you wish to name special users as moderators?
Wireless Support

Wireless communication may be required for either customers or internal users. Full support of wireless devices is not a common feature for all tools, so carefully weigh what you must have versus what would be nice to have so you don't find yourself having to discard otherwise suitable candidates.

  • Supported devices and protocols. If you already have wireless devices in place, inventory what they are. If you will be purchasing wireless devices as a part of the CRM project, define your preferences.
  • Wireless messaging. Many CRM tools allow simple outbound communications such as signaling a wireless device as the result of an alert within the system. Do you also need treatment of inbound messages?
  • Wireless real-time access. Can users interact with (usually a significantly reduced subset of) the system through a wireless device? Is this a fully formed app or can it be accomplished solely through a customization effort using a tool kit?
  • Data synchronization. Unlike the point above, this one focuses on disconnected users. That is, do your users need to download information from the system to their wireless devices? If they do that, should they be able to make updates on the wireless devices? And can the updates be uploaded at some later time back into the main database?
Chat Support

Chat (instant messaging) is a potentially costly, but very powerful way to communicate with online customers, often used for collaborative selling and sometimes for customer service and support. While chat is a wonderful tool, you may not need it. If you have no plans to use it soon, it would be a mistake to exclude from consideration tools that do not provide a chat environment. If you plan to introduce chat after the initial rollout, include it in the requirements so that you don't have to go out and get yet another tool to be integrated with the CRM system later on.

  • Integrated chat support. Do you have an existing chat environment that you need to link to the CRM tool or are you looking for the tool to provide a chat environment?
  • Chat environment. What kinds of user experience are you looking for? Do you want to be able to define response templates? Adjust windows? Route and queue chat requests in any particular ways? Do you want to provide chat support from designated locations on your web site or throughout? Does the tool have restrictions on what kinds of pages chat can be activated from? Does the tool work properly across firewalls and what kinds of arrangements do you need to make to install it (this is a potential security issue)? Do you need records of all chat communications?
  • Advanced features. Do you want your internal users (employees) to be able to push pages to customers? To take control of their browser entirely (this is useful for technical support situations, for instance)? Many CRM tools provide only basic messaging features, which may or may not be sufficient for you.
Voice over IP (VoIP)

Voice over IP is a technique that allows transporting voice over the computer network, eliminating the need for a telephone. It's a tempting option if your customers are consumers who may only have one phone line when they are using the web. For all others, it's an interesting idea but still a technical challenge so it is not widely used. Here again, do not unnecessarily disqualify candidates that don't offer VoIP just because you think it's cool. The main issue for VoIP is to check that the tool can use existing protocols that you use in-house. This is a good example of an issue that requires input from a technical specialist—here the telephony specialist—who may not be needed more than a few hours during the selection phase.

Multichannel Support

Above and beyond supporting a variety of channels, you probably want the tool to deliver a consistent experience to the users regardless of what communication channels they use. This section explores those issues.

  • Consistent experience. A fancy phrase to mean that users, both internal and external, can initiate conversations in any medium and pursue them in other media, as needed, while being able to access all the information gathered in previous conversations. In other words, the customer can e-mail asking for some information, receive a response by phone (perhaps because a more precise description is needed), and then later open a chat to ask for further details. At each step in the process the internal user (and, ideally, the customer) would have full access to the entire request history without having to jump from one system to the next to get it.
  • Universal queuing and logic. This means that, once in the system, issues coming from any communication channel can all be handled in the same way. For instance, if you define routing logic based on keywords for e-mail, the same logic should be usable for routing chat. This makes for a much more productive organization of labor.
Customer Database

Keeping track of your customers is a key function of the CRM tool, and it can be more challenging than you think.

  • Comprehensive records. What information would you like to record about customers and prospects? Is there anything unusual you need to track? In particular, are your customers corporate entities or consumers? For corporate customers, do you need to track multiple contacts with different roles for a single customer? Do the roles change over the life cycle of a customer? Do you need to keep track of special relationships among your customers such as households or reseller/end-user entities?
  • Custom fields. Even if you are lucky enough to find a CRM tool that has a customer database that actually includes all the fields you want to track, you will probably want to add some in the future, modify existing ones, and delete or hide others. It's very useful if the tool can allow that. Specifically investigate how such changes can be done. Do they require programming? What restrictions exist on the type of fields that can be added (such restrictions always exist, although they can be mild) or deleted (you can be sure you won't be able to remove the customer number)?
  • Link between databases. Where should your customer data reside? There are many good answers to this question, including making the CRM system the master customer database, using the accounting system as the master database and linking the two in some way, and using a so-called federated model where customer data is held in several systems with appropriate links and synchronization. While the only really bad answer to where the customer data reside is "we don't know," it's very important to define a strategy for the data repository early in the project and, if required, processes to keep everything and everyone in sync. No need for details at this point, but you can't make much progress without a strategy.

    If you are using the CRM tool for marketing campaigns, you may want to load prospect lists into it and maybe do some processing and cleansing of the lists. Specify what's needed.

  • Customer history. It's very useful to have immediate access to the products a customer has downloaded, whether you are trying to build a marketing campaign, do follow-up sales, or support the customer. Determine whether that type of information should be kept in the CRM system, whether that should be the master record within the company, and if multiple repositories exist what kinds of synchronization mechanisms are required. Don't go overboard with the synchronization: if your sales volume is low a simple manual entry into the CRM system after the purchase is recorded in the accounting system may be just fine.
Employee Database

Similar issues apply to the repository of employee information. In particular, the employee information is likely to be stored elsewhere, perhaps in an HR system or in the corporate e-mail system, so there's the question of integrating and synchronizing information from another master database. In addition, CRM-specific items such as the permission scheme need to match your needs. Are permissions based on roles? Does the tool need to have a concept of the reporting hierarchy for routing and escalating issues and for reporting purposes?

Knowledge Management

The knowledge base is the set of documents that help your employees answer customers' requests and help your customers help themselves. The knowledge base used by sales reps is often called the marketing encyclopedia and is mentioned in the sales section, but the same concepts are applicable to it.

  • Document creation. Do you need a way to create new documents? Who will do this? How easy does it need to be? If some documents will be created using existing objects (such as support cases), do you want to be able to migrate the objects into the knowledge creation process? Is a spellchecker important? Do you need templates? Can documents have customized attributes, such as the author's name or product category, that may be essential for searches or document maintenance? What document formats are supported (some tools only support simple text, which is insufficient for most apps)? It's best to find a tool that allows newly created documents to be visible immediately without requiring special processing (beyond going through the review process).
  • Heterogeneous knowledge bases. If you are using documents created outside the CRM tool, must they be brought into the system or can they be searched anyway? If the documents must be brought into the tool, does it require manual processing or are automated loading facilities available? What document formats do you need to support? Are they restricted in the tool? What do you need in terms of support for attachments?
  • Knowledge creation workflow. Beyond creating new documents, you will need a process to review the documents and eventually post them for the users. What kind of workflow do you need? Some CRM tools provide limited support for creation workflows. If you need multiple review steps, or you want to have full support for queues, status changes, and alerts during the document creation process, you will need to state that. Make sure that you can control who can do reviews and post documents through the permission scheme.

    Keep in mind that your knowledge creation workflow may change over time. Will the tool be able to accommodate adding steps to the review, for instance?

  • Document maintenance. This is often a weak area in CRM tools, so be sure to specify what you need. If you are planning for a pretty small knowledge base (say a few hundred documents) robust document maintenance tools are probably not that important since one person can easily wade through all the documents and decide whether they are still valid. As your knowledge base increases in size, so do the maintenance requirements.

    Do you need a planned obsolescence model, through which a review date is included at document creation date? Do you intend to create buckets of documents within the knowledge base, so that each bucket can remain of reasonable size and be maintained by one individual? If so, make sure that the requirements say so.

  • History trail. Do you want to capture everything that went on with a particular document? It's very useful for the knowledge base manager to have a full history trail available for documents so that it's possible to figure out who reviewed a particular document, or who the original author was.

    Many tools offer very limited history trails, sometimes limited to the author, the creation date, and the last update date. Other tools provide a history of events on each document that shows who took what action on what date. Very few tools provide more than that, and in particular very few tools provide a full version control environment. If you need such a level of control, you probably will have to purchase a tool focused on document management and integrate it to a CRM tool. Carefully define the level of sophistication that you need.

  • Self-learning features. Some tools leverage the use of the knowledge base to improve the quality of the documents. For instance, the tool may display documents in order of their popularity, either how often they were accessed or how often users rated them as useful. The tool may allow you to run reports on failed searches, information that's useful to a knowledge base manager when deciding where to add content. Self-learning features are very important since they allow you to use "free" resources to improve the knowledge base and also because they allow you to capture information you would not be able to obtain easily otherwise.

    When deciding on self-learning requirements, be sure to consider the needs of both internal and external users. For example, internal users (employees) may need and actually use functionality that allows them to flag questionable documents to the knowledge base owner, while that would make no sense to external users (customers) who, after all, should be able to benefit from a fully vetted set of documents and may find it confusing to be offered the ability to set error flags.

  • Search capabilities. The proof is in the pudding, and for knowledge bases the truth is in successful searches. There are many ways to go about searching, so you should think about both your users' level of sophistication and the volume of your knowledge base. Small knowledge bases, those that contain up to a few hundred documents, can be explored quite successfully with relatively basic tools. As the volume of documents grows, simplistic techniques become insufficient. User queries may fail to retrieve existing documents (perhaps because users are not aware of the magic keywords they should be using). Perversely, queries may also return too many documents, creating an overwhelming set of potential solutions that users are unable or unwilling to explore.

    Start with a brutally honest evaluation of the likely size of the knowledge base on the one hand, and the sophistication of your users on the other. With a very small knowledge base, a simple FAQ strategy would work. Even with a few hundred documents, offering a tree-based search (by topic and sub-topic) and a search engine should cover most user requirements. The more sophisticated users would benefit from an advanced search mechanism, for instance one that allows searching on document attributes (the author of the document, or its topic category) in addition to a text search.

    If you anticipate a large knowledge base or unsophisticated users, you may want to go further. For instance, having the knowledge base automatically present documents in order of popularity, as discussed under self-learning features, would be critical. With unsophisticated users, the ability of the search system to interpret natural language and synonyms would remove frustrations. With huge knowledge bases, the ability to refine searches when the result set is large would be a great asset.

    My warning here is not to fall in love with any particular feature that vendors show you without analyzing it in the context of your business needs. The ability to manually enter synonyms into the search system so that naïve users are accommodated sounds wonderful, but if you don't have the resources to maintain the list of synonyms, you just bought yourself a very expensive paperweight. If your users are all internal employees with plenty of relevant training, they will know the specific terminology to use in searches and may not need guided searches.

  • Leveraged searches. Many times the knowledge base will be used as part of working on a customer issue. The knowledge base can be leveraged for productivity to handle such tasks as automatic suggestions (suggesting potential solutions to the user based on the description of the issue), auto-response (sending an automated response to a known query), and linking documents with other objects such as deals or support cases. You may also want to use specialized tools such as case-based reasoning or CBR, through which resolution is achieved by reusing or adapting solutions that were used to resolve similar issues in the past.
  • Permissions and authorizations. Whether on the knowledge creation or knowledge search side, you need to manage access to the documents in the knowledge base. This is definitely required if you make the documents available to customers through a portal. Here are some points to think about around permissions and authorizations.

    Can permissions be defined as group profiles that regulate creation, modification, review, posting, and access, with the profiles then being applicable to individuals? Group profiles are handy since you can just say that John Doe has a "sales rep" profile, and therefore can read all the documents in the knowledge base but cannot review or post, rather than having to define John's profile individually.

    Since some individuals will undoubtedly have special roles, it's helpful to be able to apply multiple profiles to a single individual (for the multi-taskers), and also to create truly custom profiles as needed. Otherwise, you would be stuck creating profiles that apply to just one person, a big waste of time.

    Moving to permissions, you probably want to be able to assign permissions to individual documents rather than to buckets of information. Otherwise you would need to move documents from bucket to bucket as they get reviewed, which is a pain. You should be able to define permissions separately for internal and external users. If you have partners or other "special" customers, having an intermediate level between internal user and customer would be extremely handy.

  • Subscriptions and alerts. The knowledge base may be used in push mode to send alerts to users, either to all users or to some subset understood by the system (say, all users of a particular product, or all sales reps in the West). This can be leveraged to automatically send updates or newsletters to customers. Alerts are usually sent via e-mail, although a potential use for this technology is to post news on the customer portal.

    Users may also want to subscribe to particular documents or categories, so they automatically get updated when the document is changed or documents are added to the categories they are interested in. This feature is useful for both internal and external users. The nice thing about subscriptions is that they are completely automatic and can deliver timely information without requiring any overhead from the document creation function.


Measuring and displaying results is a huge undertaking, to the point that there are now vendors that focus exclusively on CRM metrics tools (analytics). This is a delicate area of the requirements since metrics tend to be very customized, so you will rarely find exactly what you want in the out-of-the-box products. If you already know what you want in terms of metrics, great! Otherwise, don't bother creating exact requirements yet (you should do it at the start of the implementation phase, as will be discussed in ), but instead focus on the following four areas.

  • Data availability. If you want to measure how quickly leads are acted upon, you'd better look for a system that stores timestamps on lead creation and activity. The same is true for tracking closure times for support reps. Make a list of items you want to report against and beware of add-on (custom) fields, as reporting against them can be a lot more difficult.
  • Customizable templates. CRM vendors will proudly state they support 72 different canned reports (or 372!). The reality is that 72 reports won't help you if they don't include the ones you use every day. As much as possible, take time to define the key reports you will be using ahead of time. Are they available as templates? (Don't worry about the pretty stuff; do the templates extract the data you need in a way that's useful to you?) Customizable templates are ideal so you can easily change a few details rather than having to start over. They should also allow you to do the slicing and dicing required for larger organizations.

    Look for templates for graphs and time-based reports.

  • Report creation tools. Unless your needs are very simple and you are very lucky with your tool choice, you will have to customize reports. Look for GUI tools that can be manipulated by business users. On the other end, if you will have complex reporting needs, being able to integrate a full-featured reporting tool is required.
  • Report distribution system. Can the system push reports to users? It's ideal to have a self-service environment where users can subscribe to the reports they need within the limits of their authorization level. What formats do you require for output?

    Do you need a way to populate spreadsheets? (I think you do!) To feed into a data warehousing system? If so, do you need periodic updates to that system? Will updates be made though an existing interface or through a separate customized piece?

    How will the production of reports impact the normal use of the system?


You may have internationalization needs in your near future even if they are not a concern today. If your needs are in the distant future, be flexible here since a true localized system is very complex and few systems support the facilities you would need to build one, let alone offer an out-of-the-box solution.

  • Language support. Do internal or external users need to use non-English languages, and which ones? Double-byte languages such as Japanese are supported more rarely than single-byte languages such as German. If you need support for double-byte languages check it out early during the evaluation phase. Data entry is one thing; data manipulation is another. In other words, it's pretty common for tools to accept entries in, say Spanish, but not so common for tools to properly sort Spanish words, handling non-English sort order and accents.
  • Foreign currency support. Do you need to keep forecast, quotes, and other financial information in multiple currencies? If you also need to report on mixed currencies, specify that.
  • Interface localization. Do you need to localize some screens of the app? Usually it's pretty easy to do that for the customer portal but not so easy or even impossible for the internal user interface. (Most tools offer English-only interfaces out of the box.)
  • Time zones. Even something as seemingly simple as correctly displaying and manipulating time zones can be difficult. Many tools work with and display only "server time," which may be confusing to workers around the country and around the world.

Marketing-Automation Requirements

These requirements are specific to the marketing function.

  • Campaign design. Is it easy for a non-technical user to create a campaign? Can the tool support promotion codes? Does the tool support dynamic campaigns?
  • Customer targeting. Can campaigns be targeted to customers based on all aspects of the customer relationship? Does the tool support permission-based marketing and handle automatic opt-in/opt-out mechanisms?
  • Campaign delivery. Does the tool support recurring, multi-step, or event-triggered campaigns? Can the campaign be adapted to several environments, in particular e-mail and phone-based campaigns?
  • Campaign analysis. Does the tool allow you to determine who got the messages and distinguish between different types of responses?
  • Lead distribution. How are leads distributed to the sales force?

Sales-Tracking Requirements

These requirements are specific to the sale function and cover both field sales force and telesales functions.

  • Opportunity management. The tool should track each potential deal from beginning to end including products, key contacts, milestones, competitors, and other information relevant to your environment. The tool should support routing deals as needed for your environment (by geography, product, industry, for example). Complex routing rules dictate a more robust rules engine. It's likely that you will change the rules over time so the tool used to define rules should be as easy to use as possible.
  • Contact management. You want to look for a tool that can track all interactions with the customer, regardless of the media (phone calls and face-to-face meetings will be logged manually by the sales rep). Additional features may include the ability to schedule appointments and to manage to-do items. This may require integration with existing tools.

    You may be looking for full workflow management, perhaps to match your particular sales methodology. You may need to add alerts for specific events within the sales cycle, whether or not you implement full workflow support.

    Another useful ingredient of contact management is the ability to manage collaboration with multiple actors. This functionality is not that common, however.

    In addition to contact tracking, the tool may also provide a number of job aids. This may include assistance in creating tailored presentations or proposals from existing templates in the knowledge base. Expense report management is another possibility.

  • Marketing encyclopedia. This is very similar to the knowledge base functionality mentioned earlier. The marketing encyclopedia provides a comprehensive set of marketing tools that sales reps can use for presentations, RFPs, and other sales actives.
  • Quoting. Sales reps probably need assistance to create quotes, get approval on them, and deliver them to the customers. If your product set is complex, you may need a significantly robust pricing and configuration tool as well. Such tools may need to be accessible to customers from the portal, either in self-service mode or while working with a sales rep.
  • Account management. This set of functionality addresses post-sales activities, from product delivery to follow-up sales to existing accounts. Account management can be a rather neglected aspect of CRM functionality so take time to define how you would use this feature.
  • Forecasting tools. Many SFA efforts are directly connected to a need for faster, more accurate forecasts. What kind of forecasting do you like to do? What kind of reports do you require? While most tools let you build any report you want, it's even better if you can find canned reports to address your specific needs.
  • Disconnected usage. Field sales reps may require the ability to download relevant information from the CRM tool into a portable device (typically a laptop, but sometimes a wireless device). They need to be able to work on that disconnected device (ideally with an interface that's reasonably similar to the connected mode) and to upload changed data back to the database (the dreaded "synchronization").

    If you need good synchronization functionality, make sure you check references in great detail, as it's an area that's very difficult to do properly. One of the common issues is that synchronization takes too long, hence doesn't get done, so you lose valuable information. Clever ways to download only the information that's required and to handle data transfers make the difference between an unusable solution and a good solution.

    Similar functionality may be needed for field service reps.

Support-Tracking Requirements

This section describes requirements for support and service organizations.

  • Flexible case attributes. All tools will track the basics including case categories, priorities, and statuses. If you need specific values for these fields, typically to match the ones in use today, make sure the tool can support them. Many support organizations have specific case attributes they need to run the business such as internal and external priorities, case closure codes, and the like. It's a good time to determine which ones are critical for the business.
  • Case creation and entitlement. Case creation is a very common task, so it's worth checking that it's really easy. If the support center checks entitlement (for instance, registered customers), specify what kind of entitlement data and scheme are required. Do you sell case packs? Do you work with annual contracts? Do you have different levels of support with different entitlement policies? Many tools are weak in this area so be sure to check the entitlement item early on.
  • Routing, rules, and alerts. Unless the support center is very small, there is some kind of routing algorithm in place. What is it? Make sure the tool can handle it. Routings based on any one item, be it geography or product line, are usually easy to implement with any tool. Multi-criteria routing is more problematic. Tools may or may not support automatic (or forced) assignments of cases to individuals.

    Do you need some kind of automatic processing on particular events? Most support centers use alerts and escalations based on case aging and most tools support time-based rules. If your criteria are more complex, carefully evaluate both the requirements and how the tool can meet the challenge since many tools are not completely flexible on this point. Also define whether the business owners need to be able to change the rules and therefore need a simple configuration tool.

  • Workflow support. All tools support open and closed statuses, and the idea of case ownership. Most support groups need something a little more sophisticated, from more descriptive case statuses to full workflow support, through which each step in the process opens up a predetermined number of possible next steps. Be warned that workflow engines can be inflexible and hard to use so evaluate the modeling tool even if you are not planning to make workflow changes right away. You will probably have to make some changes in the future and you don't want to be blocked by a difficult modeling tool.
  • Defect and enhancement tracking. Such systems may be considered within or outside the scope of the CRM system. If within, make sure you have the proper level of workflow support (light support is often enough). If outside, what integrations are required?
  • History trail. To do case analysis, run metrics, and other tasks, it's useful to have a full history trail for cases, ideally transaction-based. CRM tools often provide fairly good support for history trails on cases, in contrast to knowledge base documents.
  • Collaboration and escalation. Many times cases require more than one person to work on them. All CRM tools support case ownership changes and almost all support escalations to the next level. Check out how they model your own escalation scheme.

    The next degree of sophistication is true collaboration, whereby the case owner can engage others, either individuals or groups, in the resolution of the case without surrendering ownership. The collaboration threads can be made visible to the customer when appropriate. This is an important feature in high-complexity support centers, but it's rarely supported by traditional CRM tools.

  • Field service. If you have a field service workforce, you need to consider either disconnected usage or wireless usage. All the considerations under disconnected usage by sales and under wireless support apply. Please refer to those sections.
  • Customer satisfaction surveys. Do you survey customers after cases are closed? It could be as simple as an outgoing e-mail on case closure (which most tools can handle with minimal programming) and as complex as a web-based input and reporting mechanism with tunable sampling mechanism. Choose what works for you.