Notes about Priority Support

Notes about Priority Support

Based on some e-mail exchanges I am going to try to clear up some misunderstandings about our priority support system.

Why do you have separate support systems?

So we can easily separate subscribed users from non subscribed users. If we have to manually look up each request to see the requestors subsription status, support would be very slow. By using authenticated NNTP, we know that posts are from subsribed users.

My firewall or corporate policy prohibits HTTP. How can I access it?

We also offer an HTTP interface for our NNTP groups. Its not “all it should be”, but it is functional and usable. We hope to eventualy replace it with something more robust.

Why cannot I just e-mail you for support?

In cases where confidentiality is required we do accept e-mail for priority support. However in other cases e-mail will actually provide for a slower response.

First, the e-mail goes to a single individual and not just the team. So then it has to be rerouted to a specific person, or forwarded to many. If forwarded to many a response has to be coordinated. NNTP allows the whole team to see the thread at any time and manage replies.

Secondly, the developers currently do not have access to the billing system where the subsription status information exists. So to determine if the request is from a subscribed user or not, they must ask the administrator.

Both of these take time, and if every user used e-mail instead of NNTP or HTTP it would create qutie a “time suck” for the team. Between HTTP and NNTP, all users should be able to access the system.

E-mail = Slower Response

E-mailing issues will NOT provide a faster response time, and in fact the response will likely be slower. While there are cases where e-mail should be used for technical issues please reserve e-mail for these situations. Some users insist on using e-mail as a way to try to get “above priority support”, when in fact responses are likely to be slower than using NNTP or HTTP.

Is there a guarantee of an answer within a certain period?

No, but we try to respond as soon as possible. However many cases require us to investigate or even debug your code. We have to manage these together as well as work on the main code base. Priority support means that we look at subscribed users issues first, above all other user including bundled users. But we still have a lot of subscribed users and need to prioritize them as well based on urgency, severity, and number of users affected.

Unfortunately our current system does provide tracking of the status of discussion threads and we have to do this “manually”. So if we overlook something, feel free to reply with a “ping” for the thread.

Why not upgrade your system?

We are continually looking for a system that can meet our list of requirements and have never found one that is affordable. The few that we found that meet our needs start at about $20,000 USD + annual fees.

Why not write such a system with IntraWeb?

We would love to, and now that we have CrossTalk we may finally get to do this. But it still takes time, and detracts from resources currently dedicated to IntraWeb itself.

Why tell us YOUR problems?

We are constantly trying to improve our systems but it requires time and money which we have to balance against development and support.

Many of our systems were written 5+ years ago and have been running on “auto pilot”. The last server transfer caused some problems during migration and others are simply dated. Because they have been running successfully so long, simple upgrades are not necessarily an easy proposal as the use versions of IntraWeb that are qutie dated, as well as older IDE’s, older .NET versions, older database libraries etc. Imagine IntraWeb 5 + Delphi 7 + VS.NET 2003 + IntraWeb for VS.NET + .NET 1.1 + Firebird 1 + non Unicode + now deprecated Delphi libraries.

One users commented how “poor of a plan” this was. However at the time these were all leading edge technologies and appropriate choices. In fact, the reason we are “here now” is becuase the systems were very well written and they ran quite maintanance free for many years. These systems have all outlasted their intended deployment times.

Because of this we are working on plan for a new integrated system to replace the aging ones. But again we need to manage it against IntraWeb development so it will not be ready “tomorrow”.