Hello,
Currently we're using a different web-based support portal, but we've run into a limitation we can't seem to get around: we can't originate tickets that pertain to a given customer.
I will present a couple of scenarios. It may help to know that we are a networking and colo services provider, and we do a lot of system monitoring on behalf of our customers (we stay up 24x7 so they don't have to, sort of thing), so it's quite routine for us to know about customers' issues before they do.
In the first scenario, something goes wrong and we find out about it. We want to let the customer know. So we open a ticket that says "We noticed there is a problem and we are looking into it and will let you know what we find out." The customer gets the ticket and maybe they respond or maybe not. Whatever the problem is gets resolved, the ticket is updated as needed by whoever, and forever after the customer can see it in their view of the portal and be reminded of that time we saved their bacon.
In the second scenario, I notice that a customer needs some work done on their service, so I open a ticket asking one of our techs to do the work. The ticket is assigned to the tech and the customer, so the customer can provide whatever info the tech needs, the work can get done, and forever after the customer can see it in their view of the portal and be reminded of that time we were looking out for needs they didn't even know they had yet.
The system that we're working with now is entirely reactive... if you do anything but wait for the customer to report the problem, it pretty much breaks down; it winds up saying the customer opened the ticket and the customer experience becomes a negative "What? I never requested that? What are you trying to pull?!"
I talked to their support and the statement that convinced me it was hopeless was, "In our system, only the agents and the requestors are able to view active tickets." In other words, if the customer isn't the requestor, forget them ever being able to see the ticket. And if we "forge" the customer as the requestor, then the system forever pretends that the customer opened the ticket, even to the point of telling the customer they did.
Is our "proactive" approach something that Tender can be configured to do? (Without confusing them by telling them they opened tickets they didn't open?)
Thanks!
Jeff
#1 Posted by rick on 31 Dec, 2009 06:47 PM
First, thanks for the detailed description. We've had requests to add this, but I really didn't want to add the ability to forge requests. As you mentioned, it does seem like it would be confusing to the user.
Yes, Tender can do this for the most part. Tender integrates very well with email. You can send a message to your support address, the technician, and the customer(s). The issue will be created showing you as the originator. Any extra email addresses in the To or Cc fields will be added as watchers of the issue, and will receive any future notifications.
I'm planning on adding a To field in the web interface to work the same.
#2 Posted by Jeff on 31 Dec, 2009 09:09 PM
Thanks Rick.
I do think there are scenarios where the ability to "forge" requests is useful, but ours certainly isn't one of them.
It's great that we should be able to get started by hand, and we're definitely looking for everybody to do most stuff with email.
I do want to make sure that if we do this, the customer will still be able to easily view their entire issue history via the web, including whatever issues they report themselves as well as whatever we open for them.
In the long run, what I think we'd like to do is set up some automation. The monitoring tool we use, Nagios, sends out email messages with subject lines like this:
[Nagios] <P:1> PROBLEM: example/CPU Load CRITICAL
Where "example" is the name of a customer's server. However, Nagios is not smart enough to know one customer from another so it emails all notifications to the same place(s). Can we set up some sort of rule/pattern matching in Tender to auto-assign an incoming email like that to both our support group and the relevant customer based on the server name "example" and then notify both parties? That way, everybody knows that there's a problem, and that we're already on it.
We'd absolutely be willing to set up manual rules/patterns for each customer/machine mapping.
If this is possible, I might just swoon.
Thanks!
Jeff
#3 Posted by rick on 31 Dec, 2009 09:30 PM
You can forge requests with the API. I'd have to see really good
justification for adding this natively in the web app.
Hmm not quite. Customers can easily see issues that they respond to,
but not just ones that they 'watch'. We'll be adding a view for this
in the near future though. Basically, you'll have an inbox of unread
watched discussions.
We're working on filtering right now. But I don't think it'll be
quite smart enough to sniff out email addresses from subject lines.
We're testing out webhook support right now though, so you can have it
call some service on your end that does the pattern matching. I think
I need to add some API actions for adding/removing watchers from a
discussion (this is a relatively new feature, so the API actions don't
exist yet). But I can add them pretty quickly.
-- Rick Olson
http://entp.com
http://lighthouseapp.com
http://tenderapp.com
Nicole closed this discussion on 05 Feb, 2010 08:55 PM.