This chapter is from the book
This chapter is from the book
This chapter is from the book
Technical Support
Users take it for granted when an application runs smoothly, but it's usually the harried activities of the IT department that ensure bulletproof performance. By hiring an ASP, an IT department is often seeking a way of relieving the pressure on its own personnel to support users. In many cases, unlike users who might gripe incessantly about poor technical support (but have little power in improving the situation), IT managers might scream once or twice and then just pull the plug on the hosted application. If your ASP fails to address technical support, it's a serious problem.
Most of the major areas of technical support like upgrades, backup schedules, and SLA monitoring have been discussed to some extent in other chapters, but certain procedures deserve elaboration here.
Monitoring and Reporting
Monitoring and reporting, whether done by the ASP itself or outsourced to an MSP, is, ideally, proactive. The ASP should be so adept at scrutinizing the performance metrics that it can predict, say, network congestion, warn you, and fix it before service is affected. Such foresight comes with increasing experience with each customer, but the ASP should also have developed a "feel" for the application during the earlier "testing" phase. Similarly, the ASP should be able to run test scenarios (say, in off hours or on the testing platform) to determine whether system performance will degrade in the event you need to upgrade the application, for example, to accommodate additional users.
Any ASP should monitor most key components of its infrastructure like network, servers, databases, and applications. However, the ASP should also never overlook any equipment integral to the application's performance—like a SAN in the data center. Routine maintenance will usually also entail activities like managing storage and other assets, as well as administering user access.
Reports submitted to you corroborating SLA performance guarantees must also contain data that's relevant to your typical production work periods. For instance, an ASP submitting a measurement of transactions per minute taken at midnight when four users were on the application is of no use to a company performing production work from 9 am to 5 pm, when the system has to accommodate 500 users without performance degradation. Test results from artificially generated data scenarios are also not accurate enough to be relevant.
Of course, monitoring should also not interrupt the users' work or the application's performance.
The ASP should generate reports analyzing all relevant performance trends. These may vary from customer to customer. An FSP may have to monitor transactions per second for a customer leasing an e-commerce application but may not have to for a customer leasing a messaging application. Monitoring and reporting systems should scale as the application scales and be readily integrated with the appropriate help desk or other departments whose staff will troubleshoot problems.
Call Centers
As mentioned earlier, you should be able to contact the ASP support call center in multiple ways like phone, fax, and e-mail. Most ASPs will offer 24/7 support, sometimes for a premium fee. This said, though, the predominant mode of contact is phone calls to live agents.
Ideally, an ASP call center should enable the agent to access your service history, including all services you are leasing, all bills and payments you've made since services were turned on, and all previous support interactions (from users' questions about billing to actual troubleshooting). Some ASPs provide agents copies of questions that customers commonly ask, and suitable answers and actions for solving common problems. Some call centers also keep logs of how problems were escalated from agents to experts and record the actions taken at each stage of escalation. Such preparations expedite near-term service and refine call center business processes over time.
If the ASP uses multiple call centers or subcontracts some of its support to an outside company, you should be able to call one toll-free number and quickly reach the appropriate personnel at all centers.
Some ASPs will also place FAQs and responses and other information on their Web sites so your users can conduct their own self-service for low-level inquiries. This frees call center agents to deal with more substantive customer support issues. If the ASP lets you add, delete, and change users and otherwise mutually administer the application, then it should also offer some method by which you can do so remotely from your premises.
Billing and Mediation
Two aspects of billing are unique to the ASP model—consolidated, itemized services from multiple providers on one bill and tracking application activity to calculate usage-based fees. Contact center agents with access to your billing/payment history can probably handle general billing inquiries, but for rebates and other areas of negotiation, your ASP should probably assign a representative—either an agent or some other form of account manager—who acts as the primary liaison between you and the ASP. Most customers appreciate it when an ASP "puts a human face" on their virtual relationship. You will probably find that a single rep reinforces the sense of accountability and single-source service that define the ASP model.
Because the model is virtual, you may expect to be billed in the same mode that you lease services—over the network—although all ASPs may not offer this option. If they do, they may institute common e-business billing practices like electronic bill presentment and payment, and electronic funds transfer. If the ASP outsources bill presentment, the final bill should only represent the ASP, not the subcontractor. If the ASP is leasing different applications to different departments and you prefer that each department pay for service out of its own budget, then the ASP should be prepared to bill each department accordingly with separate statements. Of course, these practices hold true for ASPs offering traditional billing methods as well.
Usage-based pricing models require that the ASP track your activity for the relevant equipment such as database, storage, and scanners used to deliver all services. This pertains not only to per-click pricing, but it is necessary also for pricing models like "variable/tiered" ones where you're allowed a certain amount of usage within the price tier and pay a premium if you exceed it. Key service components like average network bandwidth, transactions per second, and response times are captured as a matter of course in the application monitoring process. However, particular usage metrics for billing purposes require actual, not average, data records and monitoring equipment tied to specific pieces of equipment like, for instance, scanners (for recording number of documents scanned), databases (for number of transactions), clients and servers (for number and initiator of retrievals), and so on.
Tracking usage is complicated. The ASP may have to track multiple metrics for multiple pieces of equipment like network, clients, different types of servers, storage devices, and so on. It may also have to identify the user or department that initiated an activity like a document retrieval. When the hosted application is bundled with other hosted applications or integrated with your legacy applications, the ASP may track the interrelated activities of multiple applications where certain actions initiate other actions for which you're billed—for instance, a business transaction in an e-business application might involve a document retrieval in a workflow application.