

Ask HN: What would make a great customer support tool? - prateekdayal

Hi,<p>I keep seeing posts on HN about customer support (email support) tools. We have been using Fogbugz for a couple of years now and I know that there can be a better solution. I have looked at a few other solutions (for example zendesk and RT) but I am wondering what a great customer support tool for a small team should be like. I have a few ideas<p>* Ability to reply/close/assign and do other stuff through email (RT does some of this but its extremely hard to setup)<p>* A very simple and usable web and mobile interface with a clean API<p>* Pricing based on number of tickets and not number of users (not all developers are support agents but you still want a login for them to see/respond to some tickets)<p>* Hooks to provide more information about the user, making it easier to provide a more personalized response. Basically making it easier to wow people who write to you.<p>I feel a lot of solutions out there are pretty complex (in terms of features, integrations etc) and quite costly for small teams. Do you think there is scope for a new product here? What would you want to see in it? I am going to start working on something very soon and would appreciate any feedback or ideas. Also, would love to find some beta testers :)<p>Thanks!
======
donw
There's definitely room for such a product... which is why I formed a company
with a friend and wrote one. :)

Our product is currently in closed beta as we squash bugs, but we hit every
bullet point on your feature list, plus a few more that we've uncovered as our
customers use the system.

Of course, we use this for all of our bug-tracking and customer support as
well, and it's amazing what having a _good_ support system does for your
workflow.

So, we're competitors, but don't let that stop you. After all, competition is
the crucible in which truly amazing products are formed. :)

~~~
prateekdayal
Thanks for the encouragement. Yep .. healthy competition is always great and
exciting to have :)

------
sstrudeau
I've thought a lot about this and sketched out some ideas myself. I work at
apartmenttherapy.com -- which is primarily a content/advertising oriented
business, though we are building toward some more app & community-oriented
features in the near future. Most of the systems I've evaluated tend to fall
into either a "bug tracker," "help desk" and/or "CRM" bucket, none of which is
a good fit for what we need. What we need is more of a "reader communication"
platform. We get a LOT of incoming email but we don't have very good tools for
really tracking it. Options I've evaluated are generally too rigid and
expensive, or flexible but a lot of work to adapt & maintain , and ugly (e.g.,
RT).

Being able to manage the system solely over email, at least for basic
interactions, I think is really important for my team. I really liked some of
the features of Email Center Pro (<http://www.emailcenterpro.com/features/>)
but found their UI a bit too clunky and the inability to do basic management
directly in the email client was a killer. A streamlined/updated version of
that plus email integration similar to RT would work really well for us, I
think. If you want to chat more, please email me scott AT
apartmenttherapy.com.

~~~
JarekS
One of the ideas was to create something like a local business social network
and use it for connecting employees and customers. You would ask your users to
login with their Facebook account to your system (benefit - a lot of info
about the customer) and then hook them up to the product they have and deal
value they generated. This would give you good info about importance of the
call.

Idea could be summed up as "Quora for support with CRM integration".

~~~
Be_Silly
I think the problem with Facebook, is in a straight B2b job, quite apart from
the fact i think i could never legally clear working with FB apis, is the info
people put on their FB is not relevant to their work. The info i want to plug
in to is such as reporting structure, tenure in a position, line
responsibility, projects, published papers, conferences attended or talks
given. That's very specific stuff which sometimes is publicly available, but
usually not. THis intel comes off the direct sales floor. But it can be super
useful when you need to work with a customer to understand the scope of their
needs, because you have some kind of map based on which you can (if you are
good at this kind of interpersonal) start asking how your bit of code affects
group a in a related department, or if a change to say a account presentation
will go down well with CFO. There are commercial databases which try to keep
up with personnel changes in bigger companies. Thomson does one. "Amadeus" a
Belgian data source does well for company reporting structure. I'm a firm
believer in selling features up the chain in a customer site, not "upselling"
them new products. Dones well, this has sometimes had for me the side -
benefit of locking consultants out of the loop. Nothing worse than aiming a
project or sub - project at needs you've discovered at a custmer, to have a
different management branch bring in a consultant to "evaluate" your work's
worth. So, i try to insist that the primary role of sales is not necessarily
to be closing deals, but to be closing the data we need to work quickly with a
customer. I'm specific too, we never use the word "client" beause it sounds
too open ended, too "maxing out billable hours". I try to teach sales that the
efficacy of their sale is directly related to how easily we can start to work
as closely as is practical or legally appropriate with a customer. Basically,
play the consultants at their own game. You can bet they know who is who in a
attractive potential customer site, because, generalizing,that sems to be the
only leverage they ever have.

It's a nice idea you have there. But it's 20 years since i first experienced
customer receptions declining to give any info as to employees, even for
specific roles / names. I've no idea how legal in a big corp would think,
about even using FB personal data to approach or manage contacts with
employees. That said, the first thing i learned about sales, which is still an
essential component of your job, i'd say particularly so if you're coding to
fix a customer problem or desire, is to verbally map out common contacts with
the first person you speak with. That's not far from what FB actually does,
but you're doing it in person, albeit down a phone call often as not, and so
concerns as to privacy can be finely guaged if you learn to listen.

The kind of data we pull in for any company we'd like to wok with is theses,
lectures, of who we think pays attention to what we do, even if not "decision
maker" then we delve deeper to try to understand the scope of a department
influence - are they a skunkworks, with board support, are they mavericks, are
they hard pressed ops guys? Sometimes just because who you communicate with
might be classified as one of those types, you may be doing a lot of help by
widening your contacts outside, because for big corps it's not a given teams
talk to teams talk to the right management layers all the time.

What i'm on about i think works for any company you work with above 50
employees, and requires a lot of discretion. I don't have any "hard sell"
function in where i work, but it's good to learn off experienced sales guys,
and quite often they've worked "hard sell" before. My definition of "hard
sell" is to just be absolutely direct about what you want to convey, waste the
least time of any party, and haggle price especially if your bit of the
project can give longer term or wider benefits. My own experience is you're
lucky if you an pitch a technical project at a senior manager and get two way
conversation, so the idea is you mix up who you speak with. Learn off a sales
guy how to get past secretaries, also, it is handy in a pinch!

------
JarekS
I was discussing a new kind of support system with my friend the other day. We
have been trying to understand current limitations of the support systems and
if they can be fixed with technology (not always).

I'm looking forward to see some comments from people that are more into this
topic!

~~~
garyrichardson
I feel that a lot of the points made by the original poster are just bolt on
features and not actually evolving support systems. Sure, they are nice
improvements, but I think I've seen them all at one time or another. Like you
said, not all problems can be fixed with technology. At least, not with the
base email support systems we have now.

I'm more interested in seeing some out of the box thinking.

For example, build in some AI to preselect/recommend a base response from a
pool of previous responses. That doesn't mean it'll be perfect (and still
needs to be personalized), but it's better than starting from scratch or
scraping through your wiki looking for a previous response.

Also, I want a view that watches an email support queue, public forums and
possibly chats. That way my support reps can take the next available request
no matter where it comes from.

~~~
JarekS
Yesterday we had a discussion and following point we made: \- nothing that we
can do (simpler UI, faster search for the knowledge base etc.) is good enough
to take it to market. People simply will not convert to our app because it
will not fundamentally change the way they work - and help them fix their
problems. We will still do the same thing, only a little bit better then
competitors.

Also we joked that if a company want to make a user happy we can setup an
engine that will send emails randomly from around 100 different templates
assuring user that people are working on his case ;)

~~~
Be_Silly
You say no-one will convery because your app is not fundamentally changing how
they work.

How about you get really intimate with what they use, how they use it, and
work on simplifying workflow UI, readability, all the human factors stuff
which seems to be overlooked once a project gets rolled out because the
painful bit of codifying processes too all the budget?

I mean, work out what you could overlay as a benefit, in a drop - in app.
Ignore bling, save where used to flag data that needs working on urgently, and
think about that old hullabaloo of the 70's consultant with clipboard: time
and motion. Think how many times a UI context switch is required. Take away
frustrations.

Obviously i've no idea if what yu're working on is the slightest bit suitable
fr this treatment. But if i had a nickel for every time i've seen a support
rep slam down their phone (i was going to say smashed, but we're all
enlightened PC people now!) because of something as dumb as having to hit the
fourth button on their machine to transfer a call, i'd be doing pretty good.

It's not fair of me to keep using phone use analogies, but i don't se enough
info as to what other people ar trying to solve here, hope you get my drift
anyhow.

Can you write "helper app"? Remember multifinder or i forget the name but
whatever it was on early macs which allowed you to copy and paste to a stack?
Id there something functionally simple like that you can offer which doesn't
mess with the underlying interfaces, but which still requires some pretty neat
writing and likely a fairly deep understanding of the existing apps to make
work consistently and without snarling anything?

Whenever i get private project time, increasingly rare sadly, i keep sketching
out UI models for a desk phone which would be complimentary to the tracking /
contact apps i use, not be a awful ugly alterntive. Things like flipping a
contact window from the list on the handset to my main monitor. The hard bit
isn't so much now i have to work out a way to communicate that from phone to
PC, because one way would be to loop the phone data to the PC and use the new
USB screen driver tech. The hard bit is working out what you want to really
happen. Is that, you finger flip a contact towards your main screen, and you
get a fully expanded list of the discussions you've had with them? Can drag
and drop work with this in a kind of wacom tablet way, so then hw does
movement on the obviously smaller touchscreen translate to your main monitor?
If, say, i've a preference for greyscale display on anything which cannot be
usefully colored to convey real information, does the "flipped" window stay
greyscale? Do i want the flipped window to be large, float or be even a normal
window, or do i want it "brought back" / closed by a gesture on the phone
screen? How could i do that from a cell phone?

That's pretty pie in the sky for a solo project, but whilst there remains good
utility from desk bound objects (my favourite gripe is i can dial important
customer numbers from memory faster than i can bring their entry up on my very
latest processor Nokia) and these objects, like everything else, wear out, and
are now nicely converging to voip protocols which are mature enough there's no
reason to go for a proprietary type such as cisco, theres a market for these
things.

Making any of this elegant is no small ambition. But consider this thought,
that i remember new employees getting "phone training" because they needed to
know how to handle the butt ugly interfaces of pbx attached phones which to
this day are not often much better than a bunch of soft keys and if you're
lucky those keys are customisable but still very basic features. Why can't i
drag and drop a call with my finger whilst i'm on another call? The other
thing is with the iphone we really have a lot of people finding new ways to
use a telephone, and hat idiom i think will spread to the desk phone. Suddenly
it may not be necessary to train someone how to put a call on hold, transfer
and pick up the next incoming without muffing it with fat fingers. If i
remember, AT&T research got quite far as to graphical interfaces, i think the
device was called an I-O or something. It ran on an ATM network for the
prototypes.

I can;t quite be apologetic about my phone obsession. Companies still buy an
awful lot of desk phones, and getting those to work with even simple contact
apps is often a total PITA, and not much benefit is derived. Make the right
connector, and you've a very interesting straddle market, selling forklift
hardware upgrades and the back - end to make them play nice. Ouch, i just
remembered that awful word "middleware"!

About the time they ran those Apple ads where some exec thought his staff were
taking office computers home, but instead was told they were bringing their
macs to work, i worked front line call center as a first job, where the
productive people brought in their own phones and headsets, and went to
extremes to patch them in to the corp pbx. That time, the phone of choice was
a AT&T model with a 4 line VFD which we could read even in bright light and at
an acute angle, and which you could "alpha tag" your incoming numbers, basic
caller identity, but which the official office system supposedly didn't
support, but did, and we hacked (nicely) our own caller groups so we could
take decent length breaks and be covered by a buddy across the room. Make that
stuf real simple, and - apart from the up tight "Office the movie" kind of
echoes this gives off, yu have a lot of people in regular jobs wanting your
kit badly.

Idle random thoughts, really. I think this pretty uncool bit of daily work is
simply under cared for. Yet there are an awful lot of very big businesses for
which the phone is their primary income point. Maybe if this ageing tech
actually worked well, we'd not have outsourced call centers because center
staff could actually be more productive. At least in that dimension. I've too
many "account managers" at our telco who're authorized to do diddly squat to
assist me, which is likely the reason senior mgmt don't care for which pbx /
phones they use.

Outside of big "old economy" shops, however, this sort of thing could really
help small dev shops get their customer relations under control. It's not
organization per se - we can all be very controlled as to contact management -
but take away just one bit of meatspace logic burden and i know i'd have
considerably more time to write. Instead of contact management, i call it
"distraction management".

I'm probably candidate for most boring post now, so i'll go curse at my
phone's voicemail access system now!

------
foxtrot
Ive been a fan of www.kayako.com for some time, its got lots of features and
is relatively inexpensive.

For a new product what I would like to see: Easy Template System Simple Back-
end 1 Click Install (simple to wordpress) Live Messaging

1 area that I do not feel has been explored or taken advantage of is desktop
software. I tried a while ago to create a desktop app that would sit in the
system tray, receiving status updates and messages from a central system.

It would allow customers to stay up to date with system status without
visiting a website and it could be used to notify of support replies, which
should then reduce the "I didnt get a reply" issue.

------
vanelsas
We have just set up tenderapp for our new Beta site www.pinkelstar.com (easy
social network integration for iPhone and Android). I like it a lot so far.
However, since we've just gone live I can't yet say anything about daily use.
But the setup as pretty easy and convenient and the price was pretty decent
too.

~~~
jroes
Seconding Tender. Beautiful and simple.

~~~
Be_Silly
Maybe just my mass of plugins but FF3.6 isn't loading tenderapp, while chrome
just fine. s'pose could be google's search redirect playing funny with
requestpolicy, but am confused :~/

Apart from pricing, what's better than FogBugz, in terms of your decision? I
can't find a straight features page, though straight to API faq so that's
good.Seems to be Ruby, whilst Fog has XML and presumably, being .net a few
other interfaces.

What confuses me is that OP wanted or hinted at a desire for a expanded
feature set that Fog doesn't apparently have. Which are they that Tender
gives? (I got the API point, that's good, but Fog being based on the CLR would
give more ways to extend it if you took the site licensed version instead of
the hosted version.

Also nitpicking, but Fog for the site install prices much more nicely than the
on-demand version if you've >5 users.

I'm just utterly confused as to what was the OP's question was - it's so
utterly vague - and led me to ramble off in different directions above. So
what's the comparative benefit?

I'm a fan of Joel Spolsky's writing, and have evaluated Fog online, from POV
of whether it would be useable by non programmer staff as comfortably as i'd
like.

but i'm not yet a customer as you might guess from my above psts i've interest
to do things which aren't standard for a code shop. Basically, i know the
value i get is in much deeper planning and i'd have to write a lot of what's
desired by my company, meanwhile Fog looks robust enough to use it as a way of
pulling together a few things which aren;t totally out of its design intent.
Outlook integration is a useful thing not so much for management but for
syncing nicely with the cell phones we use, e.g.

I mean i'm not shilling for Fog, i just don't know what the criticism is
except price. What is the OP disliking about the Fog APIs e.g.? If i put my
cynical hat on, i'd just say this has been a "Ask /." kind of experience. I'm
interested enough in the subject to engage, but have no way of really
replying. Was the Q really "what's not Fogbugz out there are cheaper?" I
genuinely don't know, nor can i (presently) find any links to older HN
discussion which might be useful.

All this management software, whether for bug tracking or whether you make it
front of house or anywhere in between is so useful to any helf - evolved
business of any size, i seem to remember IBM paying a pretty penny to get
ahold of Lotus who sussed the business pitch in the 90s.

I suppose that what _i'd like_ is a discussion as to what's state of the art,
what companies or systems are really pushing the limits and getting things
good and affordable, not a mere comparison with FogCreek which is very well
written up for a company of any size.

I'll post separately with my confusion points, so please understand i'm
probably just missing the point here.

best to all.

------
Be_Silly
Below is opinionated, but hopefully worth airing:

My view is that the field is over-populated.

Probelm is often definition of what's wanted. You end up with overlap between
issue tracking and CRM, and if you add in a few outlier requirements you've
described half the commercial software i see, from email installs to business
automation, ERP and even EDI.

That's quite an exaggerated generalization of mine there, but the list of
comercial and non-commercial software which can be put to use as you describe
is enormous.

What are you really missing from FogBugz? I'm not clear why you're having to
look elsewhere.

Mobile apps integration is simply not mature, or rather elegant, for any
product i've seen. Zimbra, Lotus Sametime, come to mind as rather half hearted
efforts requiring expensive additional licenses. Developer business sales
groups really should wise up to the idea that a good mobile app is the thing
small companies (mode 100 employees) i know want to have better systems, it's
not a mere extra for new installs, it's the driver.

I forget when i first heard about "unified communications" but it wasn't even
in the last decade. That promise seems to have been eternal. I feel we are
inching closer, though, yet there's nothing breakout good in any category
which i've encountered.

What i want is products with common rules engines, or something which can
overlay that via apis. Smetimes i'd just like a regex to flag a string in an
email as signifying a task is done and update a conversation thread. Sometimes
i'd like a proper transaction written back to a sals DB. Sometimes i'd like to
know my updates are delivered, with a message broker or transaction
manager.It's applying consistency to that which makes me want a common
interface to software as varied as voive, shceduling, management accounting
(e.g. for that last one where there's a showstopper ticket, i want the revenue
forecast to be dropped right away for that customer) Right now even trying for
that flexibility requires some big bloat installs and a lot of work, some of
it pretty low level.

As to scope for a new product, i don't think you can design a product out of
the box for a large proportion of users in your situation. I believe ther
attempt with XML and XSLT to find a common interface for data munging was a
good try, but it turned out the only thing more verbose than the XML was the
acronym dictionary. And a lot of XML i see is serializing ASN or whatever
talks to the outside world of suppliers, basically a patch, not a consistent
code base, so you are doing mapping schema for more than just your primary DB.

Sure, i'm being very opinionated / hand - waving. But maybe the best anser is
to say you should think hard how important your support process is. Is it
something which can really make you stand - out? If so, maybe you should
invest in time and coding effort to get what you want. There really is no
shortage of systems, apps and tools. Just nothing i see which can hook diverse
office systems together. Example of this is getting desk phones to be useful.
The best i've seen so far is the XMPP calls which SipExec and Aastra kit
supports, but still you need some glue, and a lot of thought what you want
delivered and why.

I'm emphasising voice in my post because no atter how i type, there are so
many times a quick call really sorts out a problem in a fraction of the time.
In my integration nirvana, i'd have the phone logs transcribed and appended
automatically to the ticket. I'd have my desk phone call up the subject last
discussed when i dial a number, preferably on the desk phone itself, so my
concurrent work windows can be left alone.

If there's an opportunity to introduce a new product, i think the hurdle is
the mind boggling variety of things any successful product would be wished to
work with, and you'll bloat at the end of the day.

I doubt that what you want couldn't be done fairly simply on the data front.
But UI on mobile devices is a good challenge to put it mildly.

Two favourite related moans of mine is the state of Nokia support, when they
remain 50% of the smartphone game and are if anything still popular in the EU,
for fresh sales, let alone installed base . . and the limits of active sync,
which is often as not the best way to get email up for Nokia and Apple. I
probably need to delve deeper into active sync to discover what really can be
done with it, but i guess i'm looking at a oh so inspiring compatibility
matrix if i use a non MS sync server.

If you want cheap during startup, mind, and don't have serious adversion to MS
product, BizSpark is the best dev programme and you get a comprehensive
license set for three years. Sure, it's no panacea, but i think their
archittecture documentation is pretty intelligable and provided you want to
hook in big name PBXs that would be a serious boon to my view.

Since a lot of what i do with contacts tickets and customer data is grunt
style data monging, at least you can price a .net dev reliably. Check out
LINQ, because it makes for handy glue if that's your environment. Some guys
are doing or protoyping "stream" and "real time" BI with LINQ, certainly in
some banks. It's not complete or fully mature by some views, but the project
i'm looking at this year involved funnelling a lot of context data into
priorities for contact follow ups, both externally and internally stimulated.
I'd have gone hook line and sinker for this route already if MS would only
talk straight as to whether their mobile handset voip integration will ever
come to non MS handsets, which they keep hinting at but not delivering.

I do keep digressing, but i want pbx integration with screen pops available on
a tab. Sybase Anywhere is designed to deal with this. OnRelay, a rare Brit
company doing good things with SipExec has a partial solution. But it looks
like a lot of work from where i'm standing, and my work lives or dies on
customer inquiry handling with a big voice dependancy.To my rather simplified
mind, i should not have to manually pass the context of a contact or
resolution call all the time. This is specific to cell calls. Why does one
have to juggle reading a screen, or finding an email thread, when to
concentrate on actually speaking to someone, i need to defocus visually and
actually pay full attention to what they're saying?

TL;DR version is there probably is a market for new product, but you've not
exactly defined it, and for such a product to be truly useful it'd need to
play nice with a big range of site installs, hardware (phones e.g. land and
cell) and software, and it would be no use to me if the UI wasn't first rate.

final note: this is a very mature market in terms of contituent parts, but
having so many failed products, so far as i see it (never yet seen a install
at any price which approached comprehensive and simple interface or sub year
install times) so you have some pretty big barriers to entry. Kind of project
i'd love to do if i had substantial capital to bootstrap and a really caring
dev / human factors team. Not something i'd like to do in a VC funded
environment, because i am suspicious that product like these are not suitable
for release early release often models, and that there could be a good deal of
customer business domain specific knowlege required to be implemented first to
make such a thing installable in a reasonable time. I'm still surprised how
little use colleagues make of their high end cells, even though they're
congnisant and if not geek, but very savvy, because somehow it never hangs
together well when using under time pressure. Another hurdle is Nokia. You can
cobble together anything Blackberry does with any recent Symbian phone, and
you can write much more interesting things to that stack, but Nokia seem to go
out of their way to hide the possibility. A chat i had with their PR reps in
the UK was fascinating - no-one even knew of the capabilities, or that a big
network operator in the UK thinks it's ok to blame the handset equipment for
problems caused by their proxy servers, in writing no less . . . i figure if i
attempted a well integrated system, i'd sure want it to work on that installed
base as well as Apple.

Guess i feel strongly about this, so hope what i've said, if not actually
helpful, is thought provoking in one way or another. I'd be interested in
anyone whose encountered these problems generally and tried to write
solutions, as there's ambition at my company to get serious about our systems
in this aspect.

kind regards & good luck with your search!

