HubSpot Ideas

Herschel

Assign Ticket Owner to Associated Conversation

Issue: Tickets Owner and associated Conversation Assignee are not linked.

 

Use Case: Our support team rotates who is on call. Whoever is on call during a specified period of time will answer incoming client issues for that period. To facilitate this, we have the Conversations Inbox set to unassigned for new incoming messages. We also have it set to automatically create new tickets, which also have the ticket owner as unassigned. If a support rep claims a Ticket they set themselves as the owner, BUT the associated Conversation is still shown as unassigned.

 

As a result it diminishes our team's ability to work out of both the Ticket and Conversation areas concurrently, as ownership of something in one area is not reflected in the other. This reduces the usefulness of the Conversations Inbox.

 

Solution: When an unowned Ticket (automatically created from a new Conversation) has it's owner set, also assign the associated Conversation to the same user.

62 Replies
hubmetropolis
Contributor

@cdewey22 Any update on this?

JVitoux
Member

I need this feature too 🙂

AMac1
Member

We need this feature too. Let us know when this has been added. Thank you

LPowers
Participant

Hershel,

One way our team has worked around this is to assign the conversation in the inbox first.  The ticket will then assume the same owner as the conversation.

 

Hubspot,

On occassion, a ticket needs to be handed off to another department, requiring it to have a new ticket owner - which we have been able to easilly reassign through a workflow, but ALSO needs the conversation owner to reflect the new ticket owner, along with being moved to the new department's inbox.  When we manually move a conversation to a new inbox, it automatically unassigns the conversation and I would like to have the option to keep the assigned owner. 

 

Since 2 of our departments use the same pipeline and frequently hand off tickets between each other, the teams have access to each other's inbox and we have been able to manually assign the conversation to match the ticket, but then it all goes kerplunk when we move the conversation.

 

Thank you for your help!

DStoppler
Member

@cdewey22 was this still in planning? Any update on this? 

SupernovaKMR
Member

My business would also love this feature! We're never in a situation where the ticket assignee and the conversation assignee would be a different person. We use mainly tickets over the conversations, and remembering to change both is proving very difficult.

JuanHilario_AVO
Member

I actually just encountered this problem. It seems rather unfortunate that a Workflow cannot "assign" a conversation to the ticket owner... 

 

Hubspot, do we have any updates on this?

swooddesign
Member

The sooner the better on this one...

 

Our reps are having to manually assign the conversations to themselves when the ticket is automatically done. I am trying to convince leadership to upgrade to enterprise and to roll this out company-wide and this small issue negatively weighs on the decision. Hoping it happens soon! 

 

 

FHolbrook
Member

@cdewey22 For us there is no reason that the conversation and the ticket should ever have different owners.

06734
Member

No reason for the conversation and associated ticket to have a different owner as well. 
Would be very usefull to be able to assign the ticket owner to the conversation.

callie
Contributor

Agreed! This is a huge need!! @cdewey22, is there any update from the PM team?

heath
Participant

Disappointed no solution exists for this yet. We've recently migrated to the Service Hub and this add unncessary complexity/uncertainty for our support team

stacey0367
Participant
Totally Agree!
FHolbrook
Member

This one must take a **bleep** load of planning. They've been hard at it now going on 2 years.

tcxen
Contributor | Platinum Partner

Is this still in planning?

JJMacSnr
Member

Update please Hubspot!   This is urgently needed. 

Brucey
Participant | Diamond Partner

We've got a similar use-case. A workflow that updates the Ticket Owner whenever the associated Conversation Owner is changed - but we can't do the reverse, to update the Conversation Owner to match that of the Ticket via Workflow.

callie
Contributor

@Brucey - just a heads up, the automation to update the Ticket owner whenever the associated Conversation Owner is changed is native functionality. 

Brucey
Participant | Diamond Partner

Hi @callie - thanks for that. I don't see that in out portal. I just did some more testing and the Ticket Owner still isn't updating.

 

Perhaps this only happens when in Inbox settings "Automatically assign conversations" is set to on (we don't use this, as we use a Workflow to triage based on a few key data points and define the owner); and then the subsequent Inbox setting below this "Treat incoming conversations as support tickets", where you can tell HubSpot to "Inherit Conversation Owner", which we have turned on, but as I said it seems not to work, presumably because either (a) we have the former setting turned off? or perhaps (b) because some of our users are not Service Pro and therefore HUbSpot doesn't rotate to the next owner (though we are able to do this in a workflow). Unless I'm missing something else?

Brucey
Participant | Diamond Partner

Hi @callie - OK further to my last message (humble face) it seems Conversations does do what you said - except not for the very first assign Owner action in Conversations.

 

What I mean is, per the settings I previously outlined, we don't assign an Owner to any Conversation, hence no Owner is updated on the Ticket (except if we have a Workflow turned on). Then if we add a Conversation Owner for the first time, it doesn't update the Ticket - again, this applied to scenarios where there has never been a Ticket Owner and where there is one already assigned.

 

However all subsequent changes to the Conversation Owner then update the Ticket owner too.

 

So I guess our Workflow that updates the Ticket Owner based on the Conversation Owner change is still needed, though only for that first change.