ISPs often wonder "How can I cut my support costs". This article offers some ideas.

The Core of Cutting Support Costs

The key to cutting ISP support costs lies in reducing the need for support staff to spend time with customers. The key to doing this lies in a little-known and little-used protocol called ACAP [1]. ACAP allows a customer's settings to be stored on an ISPs servers. If it is set up, this means that your support staff will be able to access the customer's settings, and even change them. The advantages of the approach are:

• General support time savings: this will reduce the amount of information needed from customers. As many customers speak slowly and have a poor grasp of technology, actually solving their problems is often a much smaller task than getting the information required to solve their problems

• New deployment time savings: if new technology is deployed that requires changing the settings on all customer's computers, it is often either a monumental task, or other significant advantages are given up because it's all too difficult

Deploying ACAP

Herein lies the difficulty -- ACAP is not widely supported at the moment. Institutions that control their clients' computers (such as Universities and Government departments) are not as interested in ACAP, because they have another tool (called LDAP) that they can use for this. The first deployment of ACAP is going to require the resources of at least one programmer to be dedicated to it. This means either a large ISP, or a smaller one supported by a volunteer programmer.

On the other hand, at least some work has been done on ACAP. So it's not as large a task as it might otherwise have been.

Deployment of ACAP for e-mail

I focus on e-mail first, because ACAP is unfortunately unable to help with connectivity problems, as the user can't connect to the ACAP server either, and e-mail is the next largest source of support problems.

My suggestions as to what to do to deploy ACAP for e-mail are:

• Ensure that the Squirrelmail ACAP module works with the version of Squirrelmail that you are using, or write an ACAP module for your current webmail. Note that ACAP is specifically designed so that, while the servers are somewhat difficult to implement, the clients are easy to implement. See ACAP Projects [2] for details.
• Set up an ACAP server. A list of possible servers is also maintained at ACAP Projects [3].
• Implement ACAP in the Mozilla core. Again, information can be found at ACAP Projects [4]. Then deploy Mozilla Seamonkey (as the only Mozilla e-mail client that supports Roaming Profiles) to your clients

As an aside, this means that customers can also share their addressbook between their webmail and their other e-mail client (ie. Mozilla Seamonkey in the example above).

Deployment of ACAP for connectivity

Although I specifically stated that connectivity issues could not be solved with ACAP, that doesn't mean that it's entirely useless for connectivity purposes. An application could be written that would read settings from an ACAP server, and alter the settings on a client's computer. That would mean that should the dial-up number, or the Broadband login domain ever need to be changed, it could be sent to all customers at once.

Likewise, if a customer signs up to your ISP, they could simply point this application at your ACAP server, and churn across.

If this were widely used, support would eventually be built into operating systems and Broadband connectivity devices.