Ticket merging - a mess?
Here's what I expect from ticket merging: all timestamped interactions are shown in their original sequence. So, if I merge two or three tickets, I expect a larger single ticket that maintains an exact chronology of all the interactions, because two different tickets may have overlapping interactions.
However.. what seems to me that is happening in merging, is that one ticket is simply *added* to another. And I expect *intersection*.
Or am I getting things wrong? All I know is that merging in OTRS just works and makes sense, and after moving to FD I get headaches when trying to make sense out of merged tickets! Is it just me?
20 people have this problem
Agreed. I've merged tickets & while it shows that they have been merged, when I go to my "All Tickets" view I still see all of the merged tickets listed separately. The tickets that merged should not show in the ticket view list - they should only show in the ticket they were merged into. Is this just Freshdesk being slow or is this an error? Merging tickets is supposed to take you from multiple tickets to just 1. That 1 should be the only ticket you see anywhere in Freshdesk - except of course, in that ticket's history.
Freshdesk Support: I believe an entry of mine (https://support.freshdesk.com/support/discussions/topics/304867) should be merged with this ticket, as it describes the same issue.
Wow, this is really bad indeed. 2yrs and no fix???
BTW, the current appearance the comment 'Conversations from the merged tickets will be added to the primary ticket' is misleading.
This is absolutely terrible. "Messy" is an understatement. Not only do merged tickets simply appear one after the other (regardless of the chronology of the interactions they contain), in many cases the order of the interactions within a single ticket gets muddled.
For example, I merged two tickets as follows:
Upon merging Ticket 456 into Ticket 123, the end result was:
This is not only unhelpful - it's actively confusing and results in terrible customer service.
The private note with content "Ticket with id 4598435 is merged into this ticket." is correctly added with a timestamp that shows when the note was created ( i.e. when the merging happened ).
The private note with content "Merged from ticket 4598435" plus the contents of the "slave" ticket request is also added with a timestamp that shows when the note was created ( i.e. when the merging happened ). I believe that this note should have the timestamp of the original ticket request of the "slave" ticket and also have some extra div class qualifier: <div class="commentbox commentbox-gray private-note original_request_copy"> Doing this, will make the timeline look more consistent and there will be a way to make that note more visibly distinguishable.
In my opinion, ticket merging in Freshdesk has improved greatly in the past few months.
Really sorry for keeping you all in the dark regarding this feature. We've made some major changes to the merge functionality in the last few months which should've improved it's performance. Having said that, we agree it needs more improvement. We've consolidated this list and sent it across to our product managers. We'll make sure to keep this thread updated once we hear back from them.
I will open a ticket about this, but I thought I would mention it here.
Guys this is STILL terrible!
I just merged two tickets. It was a really simple one - all of the ts from the second ticket were added in reverse order.
Now if you read the ticket from top to bottom, it goes:
Ticket 1 Post A (original post)
Ticket 1 Post B
Ticket 1 Post C
Ticket 2 Post C
Ticket 2 Post B
Ticket 2 Post A (the original post from the second ticket.
All of the posts in ticket 1 were posted chronologically earlier than those in ticket 2, so there shouldn't be anything complicated here!!
While this gets sorted out, can we PLEASE have the functionality to MANUALLY re-order posts within a ticket? This is a nightmare!
This is awfully confusing, because Freshdesk encourages people to start reading threads from the bottom. Anyone reading that "last" message in the thread.will assume that there were no responses to it Or --- if the reader knows that there really were responses -- may assume (as I did) that those were somehow lost in the merge.
I recently have a trial FreshDesk and spent some time on the merging. Many people (including me) think that the merged tickets should NOT have lives of their own.
But consider the following imaginary case.
I have Ticket A and TIcket B created by two different customers by email.
An agent responds to both tickets, so both customers receive an email.
Next, ticket B is merged into Ticket A. Assume that Ticket B would disappear on this merge.
Now imagine that the customer of Ticket B would reply to his email he received earlier.
How could this work? Because Ticket B is gone, there is no way for the system to relate that incoming reply (which originated from Ticket B) to Ticket A.