Customer support VPs may have to manage a range of customer-facing functions such as order-taking, shipment expediting, installation and field service appointments, as well as technical or warranty support. Each of these functions should have direct access to the CRM system, but the specific information needed (and transactions performed) are quite different across these CS roles.
If you're using SFDC, what decisions will you have to make? How should you measure success? Here are some customer support executive guidelines for the first few months of system usage. While much of this article applies to any modern CRM system, we've focused here on the specifics of salesforce.com.
Integration is a key success factor
Unlike traditional call center packages that "grew out of" advanced telephony gear (PBXs, ACDs, etc.), salesforce.com was not designed to center on telephone conversations. Indeed, many of their customers use web, e-mail, and IM extensively for customer support interactions. So if your CS operation is highly dependent on the phone, job one will be obtaining an App Exchange CTI plug-in for your telephony system. Fortunately, there are several of these available (and some are free). Evaluate the plug-ins for their depth of integration and the amount of data they automatically insert into SFDC records with each call. The larger and more distributed your call center, the more you'll appreciate the automation provided by the better CTI plug-ins.
Depending on the function of your customer support reps (CSRs), they'll need access to information that's outside the purview of SFDC. You will need to access the Force.com platform APIs to facilitate integration with external systems such as:
o Information integrated from your order management system: current orders, pending fulfillments, etc.
o Information integrated from eCommerce: "shopping cart" status, order details, and credit-card payment status
o Information integrated from the accounting system: order history, invoices, and payments
o Information integrated from the manufacturing/ERP system: shipments, serial numbers, inventory, backlog, parts availability, return merchandise authorization (RMA) numbers, reverse-logistics information, and warranty information
o Information integrated from engineering: defect reporting/tracking, resolutions, technical bulletins, patches, licenses, and repair/rework status
As most of these data elements don't change very often, you can probably get away with a periodic batch update in most cases. However, probably 10 percent of the data changes frequently, so some real-time integration will be required. While SFDC's APIs and 3rd-party integration connectors fully support closed-loop integration, there are implementation and maintenance costs involved. The depth of integration you use (including, for example, providing a login frame to external systems within an SFDC tab) is really a business decision, and most of our clients choose their integration approach on a screen-by-screen basis.
Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.