[169867] in North American Network Operators' Group
Re: Customer Support Ticketing
daemon@ATHENA.MIT.EDU (Faisal Imtiaz)
Wed Mar 19 10:57:07 2014
Date: Wed, 19 Mar 2014 14:56:43 +0000 (GMT)
From: Faisal Imtiaz <faisal@snappytelecom.net>
To: Paul Stewart <paul@paulstewart.org>
In-Reply-To: <CF4F1B67.5B23A%paul@paulstewart.org>
Cc: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
The advice I will share with you is as follows:-
Take your wish list and divide it into Core Functions (need to have), Func=
tions (want to have) and Functions (nice to have).
Be prepared to compromise, the most troublesome area is going to be the Fun=
ctions (want to have).. Many of us want to fit new software to existing pro=
cesses, while forgetting that the existing processes were designed to deal =
with current systems/limitations. Most of this can be resolved by some othe=
r form of external process or procedure change , be it manual or some sort =
of external reference...
I am not a big fan of software customization, creates challenge with update=
s & upgrades, ( don't confuse software customization with software integrat=
ion).
Having said that, for us (we are an entity that is very much similar to wha=
t you have described in your email), we have been using Kayako. We found it=
to be very flexible for handling support tickets, email inquires and also =
a central repository for Alerts etc.
We are now in the process of implementing a new Customer Billing package, (=
Freeside), which has RT integration, so we are most likely going to move a =
few of the mail queues to Freeside/RT, while leaving kayako to handle the o=
ther email queues.
My point is, while it is nice to have a 'fully integrated' system, such a s=
ystem starts to have it's shortcomings from day one... (e.g. if you tie it =
to your billing system, then what do you do with sales inquires ? you don't=
want to overload the system with junk.. or even system alert trouble ticke=
ts)....
Over the years we have found it more practical to develop some process to t=
ie the info together in billing and ticketing system (we record ticket # in=
the billing system, as a ref. for related tickets), than try to do some so=
rt of automation / customization.
Of Course your mileage may vary.
Faisal Imtiaz
Snappy Internet & Telecom
7266 SW 48 Street
Miami, FL 33155
Tel: 305 663 5518 x 232
Help-desk: (305)663-5518 Option 2 or Email: Support@Snappytelecom.net=20
----- Original Message -----
> From: "Paul Stewart" <paul@paulstewart.org>
> To: nanog@nanog.org
> Sent: Wednesday, March 19, 2014 10:01:11 AM
> Subject: Customer Support Ticketing
>=20
> Hey folks=E2=80=A6.
>=20
> We need a new customer ticketing system and I=E2=80=99m looking for input=
. I am
> still working on a scope document on everything we want to do with the ne=
w
> system.
>=20
> The most common problem I run across is that a system is either built for
> enterprise internal IT helpdesk or it is built like a CRM sales tracking
> system. We are an ISP among other things and are looking for a powerful =
and
> yet reasonable cost system to answer email inquiries, allow customers to
> open tickets via portal, mobile support, escalation/SLA support, and seve=
ral
> other things. Solarwinds NPM integration would be a huge bonus but not a
> deal breaker. If anyone has a system that they have integrated with Ivue
> from NISC (our billing platform) I would be really interested in hearing
> more as well.
>=20
> So my question is meant high level. For those folks that are ISP=E2=80=
=99s
> supporting business customers (including managed customers) along with
> residential eyeball traffic what system(s) do you use and what do you
> like/dislike?
>=20
> I=E2=80=99ve looked so far at WHD (Solarwinds product), OTRS, RT, RemedyF=
orce,
> ZenDesk, HappyFox, Kayako and several others. All of them so far would
> require a fair amount of configuration or modifications based on our stil=
l
> developing wish list. Also worth noting is that we have no full time
> development staff so hoping to find something that has a lot of promise a=
nd
> then work with the vendor to evolve it into what we feel we need.
>=20
> **This is not an invitation for sales folks to call on me**
>=20
> Thanks,
>=20
> Paul
>=20
>=20
>=20
>=20
>
