最近搜索
没有最近搜索
Multi tenancy email ticket creation issue.
已于 2022年1月14日 发布
This is a very hard ticket to title to get up votes.
I hope the zendesk Domain logic creators get a chance to read this.
I have an issue with the domain logic defended enough to warrant you to create a FAQ on your position - https://support.zendesk.com/hc/en-us/articles/4408881694362
This logic rules out ALL of your customers sharing a common business relationship.
Scenario:
Our customer Z needs to organise products from Company A and have them installed by Company B and have both companies involved if any issues may arise during the project.
Z does not know (nor care) what ticketing system A and B use and sends one email to both parties (directly) regarding the project issue. In doing so the ticket is currently only created in one of A or B zendesk tenancies. The email is asking A for information so B can do the job, but B only got the ticket and is waiting for A to respond. B and Z are waiting for A who knows nothing about the issue because of this current logic. Z rings A to find out why they have not responded to the repeated emails only for A to explore why they did not get the ticket.
Based on this scenario (which can be very costly!) Company A looses faith in the zendesk service.
Zendesk claims the email has a unique ID that can only exist in one tenancy across the entire zendesk system.
I propose when the email is received, zendesk search all "To" addresses to compile a list of tenancies in its eco system. For each tenancy create a ticket with tenancy ID+email ID so there is unique tickets for each tenancy (A and B) to action upon.
The solution your support team gave, was to create two tickets, one for Z and one for B, the problem with this is Z instigated the tickets by email. Z does not know zendesk limitations nor that A and B use zendesk, and therefore A never knows to create 2 tickets. Nor does B know that A has that issue.
32
13 条评论
Morgan Clark
We have this issue as well - We are a global team who receives information from internal sources, but needs to be communicated to all team members at the same time. For example, we receive a report from Team A to 3 of our 7 email addresses. Those 3 support addresses are 3 separate groups in Zendesk. The ticket is created and now only 1 team out of the 3 know the details in the report. With the amount of team members working in our Zendesk instance, it is not feasible to have all team members know to create clone tickets or apply correct logic to these tickets.
0
Laetitia CORDIER
+1
0
Kiliaen Ludlow
Has anyone developed a work-around to this issue? We have multiple business lines that clients can access and it is infuriating to them that many don't even see their request because of this issue. It also seriously degrades the service we are able to provide. I agree with previous posters that this is causing us to look at other providers.
0
Shawna James
0
Amanda L.
This seems to be a topic since 2022 (link below) and yet there are no updates!! This functionality would be extremely beneficial
https://support.zendesk.com/hc/en-us/articles/4408881694362-Can-one-email-create-two-tickets-in-different-Zendesk-accounts
0
Carlos J.
+1
0
Carlos
+1, we definitely need this for our team.
0
Sydney Neubauer
+1 Our major team works in Zendesk, we have another team in a separate instance where had to create a workflow to transfer tickets with the API. However, we have just come across that some of our contacts ALSO use ZD. We can't keep creating API workarounds just because you can't create 2 tickets with one email. This is a major problem
Is there any update?
1
Sarah Lehmann
We currently have the same problem.
Our example:
There are 4 different stores that are all connected with their own email address in Zendesk.
A colleague from another department (which does not work in and with Zendesk) has sent an info mail to all 4 stores - only one store has received this info mail.
So it would have been good if there had been 4 different tickets so that each store received the information. In our case, the other three stores did not receive the important information.
1
Benjamin Kirsch
Hey all, thanks for engaging on this thread and providing feedback on this product area. We have logged this feedback for our backlog but we are focused on features to surface outbound email bounce information and the ability for customers to connect their email servers directly to their Support Instance. We will continue to leave this thread open for community comments for more use cases and if anything changes in the future on our end we will update as soon as possible. Thank you again for providing your feedback to us!
3
登录再写评论。