Most e-CRM systems are built around e-mail. However, e-mail still requires a human response in most instances and therefore does not scale well. Even if e-mail is a big part of your system, you should be aware of the other pieces of the puzzle.
At the heart of all e-CRM systems lives a knowledge base with a knowledge-management application. A knowledge base is an electronic collection of information that can be queried for answers to various questions.
The knowledge base should be stored in an RDBMS (relational database management system). Associated knowledge-base documents, such as PDF files and schematics, would be cataloged and stored in the file system and indexed in the database. The knowledge base also should have a Web interface with multilevel security access. This lets you give your clients read-only access to parts (or all) of the knowledge base. In addition, it should have a mechanism for bulk updates, batch updates or both, so you can do updates in one step, not one entry at a time. Finally, there should be a mechanism to report on the most requested articles. By knowing your most requested material, you can beef up the knowledge base and improve the skill level of your helpdesk personnel.
While your support staff and experienced users will interact directly with the knowledge base, your typical end user should have a different, simpler method to get help. This is established by creating a service or Web portal. The service portal could have transparent access to knowledge-base articles but should also include items such as FAQ lists. In addition to giving access to documentation, the portal will let the user submit trouble tickets, ask for RMA (return merchandise authorization) numbers, track shipping information, access accounts, run end-user reports, download software patches and participate in discussion servers.
While recently building such a portal for one of my clients, I made sure everything and anything displayed on the Web pages came out of a database--the titles, the order in which items are displayed, and the fonts and colors used in my CSS (Cascading Style Sheets). This approach shifted the burden of updates from the programmers to customer support personnel. It is critical that your portal is data-driven; this will be more costly up-front but will save you a lot of money in the long run. Performing data entry against the database is much less expensive than coding HTML, Java, ASPs (Active Server Pages) and so on whenever you need to significantly change the information you're presenting.
You should have one or more of the following e-CRM services accessible from the service portal: a live Web collaboration tool, a live customer-services tool, a discussion server and an e-CRM e-mail system (see "Elements of e-CRM Services," above).
Let's take a closer look at those pieces. A live Web collaboration tool will allow your internal workgroups to work better together, or you can use it to interact with your customers. You can give tutorials, seminars, demos and similar presentations using such a tool.
When evaluating this service, make sure you have voice capabilities. Ideally, your moderator (or presenter) should be able to mute everybody but himself or herself; otherwise, large presentations can get messy fast. If voice is not integrated with the system, you can set up a voice conference with companies like WorldCom or Global Crossings to achieve the same effect. Make sure you have the simple--yet important--supporting features, such as the ability to send feedback from the attendees and to perform real-time polling. Several providers, including the popular WebEx Communications, offer these services.
A discussion server is essential for any e-CRM system. It empowers customers, which reflects positively on your organization. It also allows for a quick response to any problem without your having to make an immediate commitment. The information is accessible by all end users, thus relieving you of the responsibility of pushing it to customers.
While discussion servers abound, there are still some special considerations when deploying one as part of an e-CRM solution. You will want to secure the site so only authorized users access it. And you will want to be able to provide an e-mail notification so participants can get e-mail messages when follow-ups to their postings are put on the server. The ability to attach documents is also crucial: Customers will want to attach screenshots or similar documents to detail their problems. You will also want to enable HTML content in the posting to add to the visual effects. But be careful: Malicious HTML and JavaScript content can cause you problems.
If your e-CRM system does not include a discussion server, you can find some fine open-source solutions at www.phorum.org (PHP-based software), www.cpan. org (The PERL Archive) and other sites. Some commercial examples include WWWThreads and aspSmart.
The option for live customer service is the closest you can get to speaking to a customer-support person. With this option, you place an icon on your Web site (the service portal) that establishes a chat session with your customer-services staff when a customer clicks on it. For example, let's say a customer needs to talk to AT&T about its cable TV service. He or she tries calling, but after a chain of options and a long wait, the customer is likely just to give up. But if that person uses the "Chat With Us" link on the company's Web site, within about 10 seconds, he or she can have a representative on the other side to offer help.
Very little tweaking is needed with the live-customer-service option. Make sure your users can copy the complete text of the conversations to their clipboards for future reference. In addition, just as it is with e-mail, judging a person's mood while reading his or her messages is difficult. Be sure to allow the ability to place mood-revealing icons in the body of the message, such as the well-known smiley face. Although it's not too common, you may want to find a system that lets you log those sessions. Unlike e-mail and phone conversations, most chat sessions are not saved, but if you use them heavily, they should be.
On the e-mail side of the equation, things are not as simple as they seem initially. Exchanging e-mail messages between your customers and your customer-support staff is not enough. You need a mechanism to send mass e-mail announcements without distributing to the entire group everyone's e-mail address in the "To:" field. Customers trust that you won't spread their e-mail addresses around, and you must pay attention to this or risk losing their trust. Also, if you do not plan well, people responding with "out of office" notifications could create endless loops of messages. If you have a large client base, you could clog up your servers with large volumes of message.
You'll want a system that delivers messages securely and privately. The delivery should be staged to balance the load on your servers, and the system should correctly handle undeliverable e-mail messages and vacation replies. It should be integrated with your knowledge base so your messages are archived there. This is a two-way street: There should be an automatic mechanism to send new knowledge-base entries to interested clients via e-mail without any human intervention. Also, you must allow authorized clients to subscribe and unsubscribe from these e-mail lists on their own without having to contact your systems administrator.
Gluing It All Together
Regardless of how you decide to tackle an e-CRM project, remember that the system is not simply the collection of the different software packages. You will want to design your architecture with extreme care.
Scalability is the first issue to consider. Making your knowledge base scalable may involve splitting it across multiple servers. Multiple replicated copies of the knowledge base should not be a problem to implement, but splitting the data across servers will require lots of effort to get it to work.
Security is another issue. Your data should always be stored behind your firewalls, and your application servers that interface to the outside world would sit in the demilitarized zone. Make sure outsiders cannot break into your data servers. Because you will need firewalls and proxy servers to make the system work, you may run into issues with the client browsers' configurations. Keep in mind that your clients will probably be coming in through firewalls and proxy servers. Do not have anything in your user-interface code that may be blocked by a firewall or a proxy. (You would not believe how many corporations block Java applets and ActiveX controls at their proxy servers.)
Remember that Internet access is not uniform across geographical areas. If you are based on one of the coasts, you may want to invest in a duplicate setup on the other coast. If you are using a hosting service, such as that offered by Exodus Communications, the provider will be able to help you with the setup.
Think Big
Keep international users in mind. Do not hard-code any text, such as error messages and dialogs, unless you absolutely must. Your database tables holding the textual information should be designed with international users in mind. Your user interface should be customizable through CSS, with the CSS parameters stored in the database. This will bode well for going international and will allow you to develop portable code across multiple devices: different browsers, WAP (Wireless Access Protocol) devices and devices that support users with disabilities.
Ahmad Abualsamid is the founder of Apical Consulting, a Chicago-based software consulting and contract programming firm. Send your comments on this article to him at ahmad@apicalconsulting.com.
