We've been using Jira as a support (ticket) and internal development tracking system for about 6 months. Overall I'm very happy but am trying to find best practice ways to improve the support system aspects. We have about 200 external customers and are using a 20 User Jira license. We get around the 1:1 customer/license issue by not creating Jira users based on their email and instead share an internal "customer" user. Here is what we are doing today:
- We have external customers emailing and calling us to generate support "tickets".
- When they call, we have our support team collect information and enter it into the system as they are on the phone with the customer. Once they hang up, they can fill out any details, etc. This is working fine.
- They majority of our incoming tickets come from customers who email us their issues. They email to a common firstname.lastname@example.org email address. We use the Email handler to populate as much of the information as possible. We currently don't create a Jira user for each emailing customer. This means our support team is forced to manually respond to all incoming email tickets. They reply to the customer from the email@example.com email address, and they make sure to include the Jira issue number in the Subject so that any/all email communication from that point is captured in the issue comments.
What I'd like to do is open a 3rd way for the customers to create issues: via Jira itself (and slowly try to reduce the phone calls). That said, I don't want to create "Jira-users" for each customer which would change our licensing. We only have 1 Jira project, and I don't want customers to be able to see other customer issues or browse issues. I only want them to utiize our Jira site to create a new issue to help get better incoming data/details (vs. some emails that say "call me back, I have an issue to tell you about"). I've been reading a lot about different ways to implement this type of "unlimited" external customers that are not mapped to "Jira users" but I'm not sure I've seen anyone describe the exact steps to do it.
I prefer that they use Jira to enter the issues, and then Jira will automatically email them back sharing the "ticket" number they've been assigned (vs. the manual process now by our support team). From that point on, I don't really need to have them in Jira at all. All further communication can be done via email (by including the Jira ticket number in the subject).
What I'd like to do is have them create Jira logins (but internally don't have this create "Jira users"), use basically the same interface as our support team to create a new ticket, get an automated email reply with the assigned ticket number, and then when our support engages them via phone or email.
I "think" this might be possible (without using a plugin) by maybe pre-creating "fake" Jira users for each customer and then share this login information with them. Then put these "fake" Jira users in a special group that has limited permissions that can only create new issues and nothing else. As I said, I only have 1 Project, and I don't want customers to see all their open issues or other customer issues. They only need to create a issue and then leave. Is there a straight forward way to implement this? Am I even on the right path? Has anyone implemented something like this?
Thanks in advance.
I only have 1 Project, and I don't want customers to see all their open issues or other customer issues. They only need to create a issue and then leave.
I think the Issue Collector is what you are looking for:
Hi Conrad. If my understanding is correct, the Issue Collector is just a way to embed a simple Jira issue creation interface into a web site (done via generated Java Script). I've thought about this approach, but feel it isn't a good option as our customer's don't typically go to our web site now (but I guess visiting our Jira site is not that much different). And I'm not sure how easy it will be to add this Java Script code to our existing site. That said, maybe I'll have to revisit this. Part of the issue for me comes down to the fact that I want the system to automatically email customers back with a "ticket" number that is assigned to their issue. Normally this is done by capturing their email address in the Incoming Mail Listener, but I don't want a new user to be created for them based on that email. I've read about Project vs. Issue level security and it seems that what I might need is Issue level based on the fact that our customers have 1:n number of reps that might email / submit issues to us. I don't want to go down the path of pre-creating a bunch of user accounts as that would require more user management on our side (ex. if they have high turnover at their company). Does anyone know how Atlassian does it internally? I've read their articles about how they create a Support env with Jira, but I didn't see anywhere where it talks about if they create a "jira-user" account for anyone who submits a ticket. I suspect they do because they don't care about the licensing constraint. They also have it set up where the submitter and their support team can go back and forth in Comments on the created ticket. I don't want to do that. I want that communication to happen in email only because I don't want customers to see Comments that take place between our internal staff who are triaging/working the issue (ex. We don't want them to see comments like "Low priority, let's not focus on that this week.").
Does anyone know how Atlassian does it internally? I've read their articles about how they create a Support env with Jira, but I didn't see anywhere where it talks about if they create a "jira-user" account for anyone who submits a ticket. I suspect they do because they don't care about the licensing constraint. They also have it set up where the submitter and their support team can go back and forth in Comments on the created ticket. I don't want to do that.
This is most intesteing part for me. "Creating customer account without consuming licenses." I have couple of hundred customers while we have only 25 peoples.
For example, I wish new lincense term like "Customer ID" just like "Atlassian ID" with ability to CREATE and COMMENT on their own issue, but with hard-coded permission restricted for ASSIGN, RESOLVE, TRANSITION, MOVE, CLONE, MANAGE PROJECT, and RESOLVE.
I want that communication to happen in email only because I don't want customers to see Comments that take place between our internal staff who are triaging/working the issue (ex. We don't want them to see comments like "Low priority, let's not focus on that this week.").
If you need to hide internal comments, you will need to create a clone from the issue and setup a security scheme not to be accessible by customer. That's how Atlassian doing with their internal. Actually, they are doing that on Confluence though. (So customer can't access their internal wiki but the issue is linked into certain page of Confluence.)
Are we on the same page, Michael?
We let out customers send emails to our system and create a new user for each new reporter.
But we put these users into a seperate group that doesn't have the Jira User general permission and so will not count towards your license limit.
You can now see who the reporter is and if you give create issue, create comment and create attachment rights to anyone (or the specific group) for your support project you can use the comment system in combination with email to communicate with your reporters. (They simply need to reply to the emails they get from JIRA).
That's the short version, it is possible and I've already implemented is at several of my customers.
I can recommend the following plugin for Support: Issue Viewer:
With this plugin, you can give each customer a view of a ticket, but it only needs one support user.
being in a similar situation, currently your best bet is to build another WebApp-GUI on top of JIRA, using JIRA only as your back end system.
However Atlassian seems to realized that this use case is an major issue, so the are developing another Product/Plugin named 'Viewport'.
and also http://atlassian.com/viewport for more information.
However there is no information about a release date, so if you need a solution fast, i fear that you have to go the custom solution route
Hi Peter. I think you are pointing me in the right direction, but I have some clarification questions:
When you let external customer send email to your system, and you create a new user, and you put them in a seperate group, does putting them in a new group happen automatically or does your Jira admin have to do that manually each day (or as the users come into the system)?
What Incoming mail handler do you use and how do you have it configured?
This is what I'm going to to try and test with today:
1) create a new Jira user called externalcustomer (who is not part of the "Jira users")
2) create a new Group called externalcustomergroup (all external users will be part of this group, while all internal "real" licensed Jira users will be part of our Company group.
3) create a new permission scheme called externalcustomerpermission scheme (because my "normal" permission scheme is different and I don't want it to be changed). Assing this permission scheme to the externalcustomergroup Group.
4) I'm going to add the create issue, create comment, create attachment permissions to the externalcustomerpermission scheme
5) I'm going to modify the Incoming mail handler (we use the "Create a new issue or add a comment to an existing issue" handler) so it doesn't it doesn't use a default reporter, it will use the Create Users checkbox, it will use the Notify Users checkbox. My question here (as above) is how do I get these new users to automatically get added to the Group called externalcustomergroup that contains all the external non-Jira license users? Or is that a manual process the admin needs to do each day?
Are there any other steps that I need to do? Are any of the above steps not required? I hate to bother you for the details, but I really don't have the ability to muck around with this too much as it is in a production environment. If you've already set this environment/process up successfully, would you please mind sharing the steps I need to follow in order to get it working here. Thank you very much in advance!
Teams break work down in order to help simplify complex tasks. This is often done iteratively, with tasks being broken down into smaller tasks and so on until the work is accurately captured in well-...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events