I want to manage our customer requests and map them to customers that originate from emails, but we do not want to expose any help portal. Is there a way to do so?
Another catch, when I add an email and associate it with the customer, they get access to this portal. I disabled this new account creation, now it won't allow me to add emails here.
Hi,
so in other words, you don't want your customers to use or even know about the existence of the portal, is that correct? So you just want to create internal requests to use for tracking purposes (have the customer as reporter - but them not being aware that the requests exist)? Do you want to create the requests yourself, or should customers be able to do it via email also?
If the above is the case, I would consider using Jira Product Discovery, with some small adaptations.
Alternatively, you could do some heavy modifications to your JSM to block customers from viewing their requests. You will need to modify permissions, restrict access to the portal or remove the Portal groups altogether. Without portal groups, their portal will simply be empty and they won't be able to see anything.
Could you maybe describe your use case better also? It would be useful to understand what you want to do and why.
Thanks Alian, yeah, so we want to track the email requests for internal tracking and visibility only, while grouping the requests coming from customers. We should be able to respond back to their 'ticket' with updates and it should get updated with the replies - just the way it is today minus the exposure of the portal.
I can explore product discovery, but does that allow incoming email ticketing? Maybe, I need to take a look at that.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I'm not sure if I fully understand.. So you want to answer them in the ticket "Reply to customer", but you don't want them to have access to the portal? Is there any reason why not? In order for a reporter to receive an email when there's a reply, the reporter must have an account with an email address. If they have an account, they implicitly have access to the portal. As described in my previous reply, you could theoretically remove everything from the portal, so that even if they log in, the portal will be empty so a reporter could only create email requests, but then again, you must configure this.
If I was you, I would also keep in mind the replies via email. In a reply, you only see what the latest comment was. If a case stretches to be a bit longer, the reporter will lose the context as they can't see the request via email. This is problematic.
We have a similar setup to yours, but then again it's different in some ways. We have customers who we don't have an email for, we handle a lot of phone calls, so we have their phone and/or name. Since a user must have an email, what I did is that I create a fake email for them simply for tracking purposes. But for users that we have an email for, they get a regular customer account and they can see their requests. I don't see a point in hiding their requests from them?
Once again, maybe I'm misunderstanding something here, or maybe you are? What is the purpose of hiding a request, that a customer created, from themselves? I mean they created it, they know about it...they should have an overview of it. You can configure what they can and what they can not see in the request, you can even have internal comments, should you need them, to discuss internal stuff in your own organization...
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.