HubSpot Ideas

James-Preseem

Customer Support Survey - more control, flexibility, options

Customer Support Survey

Today:

  • 1 survey
  • No control over content of survey (type, wording, measurement, etc...)
  • Recipients based on pipeline(s)
  • Event driven based on status change from  an open status to any closed status
  • No option to suppress

Future wishlist:

  • More criteria to define when to send or not send the survey
    • existing or customer property value
    • specific closed status i.e. Closed = send survey, Closed No Survey = don't send survey
    • multiple people open up a ticket for the same reason and we decide to close 5 tickets and merge them all into one, we need an option to send out 1 survey, not 5.
  • Options to change the type of question asked in the support survey from 😞 😐 🙂 to whatever we would like.  Providing an industry standard option for CES survey is great.  Forcing everyone to only use 1 survey is not great
  • Allow more than one CES survey.  Not all departments, pipelines, and tickets are the same.  A technical support bug ticket and a customer service billing issue ticket are not the same thing.  An internally generated ticket that is requires an outbound contact to the customer vs. a customer intiated inbound ticket to the same group are not the same things. 

 

UPDATE: See update for possible workaround of some of these concerns that I posed on April 24, 2023 in the replies below.

 

12 Kommentare
mikloso
Teilnehmer/-in

This please!

 

I thought the beta custom feedback surveys would resolve our issues but they do not sadly. Custom feedback surveys have reinrollment isues. It would also be great if the CES could be sent at a specific pipeline stage. For instance, we have a "Pending review" at this point it would send a review and if the survey is completed then the ticket would be moved on to either the "Client satisfied" stage or "client unsatisfied" stage based on their feedback. Unenrollment for this automation would be triggered if we manually move the ticket to either stage (if we got feedback though another medium).

 

Having the body and question of the CES survey be the same for everyone doesn't make much sense. We arent comparing responses between businesses, we're getting feedback for internal use.  The question itself does not fit well with our model at all either.

 

The original posts other ideas are also excellent and I second them all. If I've made a mistake and the things I'm describing are possible then my mistake, but I have been on the phone with support several times with no resolution.

FRöttger
Mitglied

Agree!

Especially the fact that we are not permitted to customize the body and question of the CES turns this survey from an interesting solution to get feedback from cutsomers into no solution at all.

LukeAsprey
Mitglied

Agree. In particular, I'd like to see:


    • specific closed status i.e. Closed = send survey, Closed No Survey = don't send survey

The functionality to close tickets and be able to configure which tickets trigger a survey would be incredibly useful for our team.

LPowers
Teilnehmer/-in

We oftentimes have customer's reply to our last communication after a ticket has been closed and their issue resolved.  This reopens the ticket and will send a second survey when closed again.   Their final communication is oftentimes just a Thank you, which requires no further action on our part.

 

We don't want our survey's to become spam and would like the option to limit the number of times a survey is sent for a ticket to be 1.

BrettloweAUS
Mitglied

Would be very keen to see this. 

Ideally would like to be able to embed more custom questions into an email rather than have to use a survey link. 

Alternatively having the option to change the CES/NPS question would be great. 

 

This means we are better placed to get more responses but have control over the questions. 

lrn24
Mitwirkender/Mitwirkende

We definitely need more customization. I'd love the ability to customize the question on the NPS survey. The way it currently reads is a bit clunky, and would be better written as, "On a scale of 0 to 10, how likely are you to recommend our business to a friend or colleague?"

CGoodwinOlsen
Mitwirkender/Mitwirkende

Hi! Great suggestions in this idea - hope to see some movement on the customization possibilities for the standard surveys.  Adding our use case:

 

Our customer support teams handle tickets raised by customers, in addition to inquiries from suppliers/partners.  We would rather not send a CES survey to suppliers or partners given that they have a different relationship to our company, but their tickets should still be handled through our support channel (therefore routing supplier/partner tickets to an own pipeline is not an option).  It would be great if we could exclude certain domains from receiving the surveys.  I know this is possible with a custom survey, but then we lose some of the benefits of the standard surveys - such as data in the ticket properties "Last CES survey date/rating/comment".

James-Preseem
Mitwirkender/Mitwirkende

Update / Possible workaround solution

 

When I originally posted this idea, my concern was that there was no way for me to control the CES survey being sent.  I felt at that time, that there were situations where I would want to close a ticket that was in a survey enabled pipeline and not have the survey sent. Some examples:

  • Duplicate tickets
  • Tickets that had been manually created in error
  • Internal tickets that were not customer initiated
  • Tickets that were not generated by a specific subset of sources

Based on the current functionality, none of these things are possible.   Current functionalty I experienced was:  

  • If a ticket was in a pipeline that was enabled for the CES survey and that ticket was placed into a ticket status that is a "Closed" status, that ticket was going to send a CES survey to contact for that ticket.
  • The only control that existed was being able to contol whether it was immediately sent or whether there was a delay before sending the message.

What I want(ed) is to be able to control which tickets get sent a survey based on the properties of the ticket in a manner that was consistent with a ticket workflow.  Ultimately this is how I solved the problem.  It wasn't especially pretty, but it works very consistently solves virtually all of the problems that I originally had.

 

Problem one: Control which tickets are going to be sent a survey

 

Constraints: 

  • No existing functionality to control this in the current pipeline
  • Pipeline enabled for Survey & ticket status = closed survey is sent no questions asked no control

Solution

  • Pipeline
    • Create a second pipeline to handle and manage the sending of surveys for the active ticket pipline "Support Pipeline"
      • Survey Pipeline Name:  Support Surveys
    • Support Surveys Pipeline Statuses
      • All HubSpot Ticket Pipelines have to have at least one Open status and one Closed Status
        • Pending (Open)
          • Initially I used this status as a way to test the workflow
        • Closed (Closed)
    • Tickets are created in the "Support Surveys" pipeline by a workflow that enrolls tickets from the "Support Pipeline" when they enter a closed state and meet specific criteria (see workflow details below)
  • Ticket Properties
    • I created a property called "Send CES Survey" as a way to automatically track and manually control the sending of a survey for a given ticket.
      • Property created was a drop down list with the following options
        • Already Sent:  set by the workflow when a survey was sent to the customer, intended to prevent sending a second survey should the ticket be reopened and closed a second or subsequent time
        • Workflow excluded:  If the ticket is closed went through the workflow and failed to meet specific criteria in the workflow, this criteria is updated to highlight that it was excluded by the workflow from being sent a survey.
        • Don't send:  This is a straight up manual option to prevent the survey from being sent.

Workflow

  • Enrollment Criteria
    • Pipeline = "Support Pipeline"
    • Source = Chat, Phone, or Email
      • Chat, Phone, or Email in our case represent what I would describe as "Customer Initiated" interactions.  i.e. this ticket was created based on the customer contacting us
      • In our case we have other sources of tickets being created in this support pipeline that represent proactive initiatives that are not customer initiated and may not have a specific customer contact associated.
    • Ticket status is any of "Closed (Support Pipeline)"
      • This limits the tickets status to a very specific status and not any status that represents a closed state.
    • Create Date is after <01/01/2021>
      • I added this criteria to limit workflow from enrolling all past historic tickets that otherwise met the criteria.  (see Close 
    • Close date is after 02/24/2021
      • I added this criteria in combination with create date to narrow the scope of tickets that would initially be enrolled in the workflow.  This workflow was enabeled on or around 02/24/2021 so effectively I was defining the criteria for sending the survey as any ticket that was created in 2021, that was closed after 02/24/2021. 
    • "Send CES Survey" property is none of "Already Sent", "Workflow Excluded" or "Don't send" or is empty
      • Intended to exclude those tickets that had previously been processed or excluded manually or by other workflows
    • Resolution is none of "Duplicate Ticket"
      • In our case we have a property called Resolution for our tickets, in the case where a duplicate ticket is created inadvertently, we will close that ticket with a Resolution of "Duplicate Ticket" to exclude it from other reporting.  It is added here as a way to prevent "Duplicate tickets" from being sent a CES survey.

When meets these criteria, it is enrolled into the workflow and the following actions are performed

 

  • Create a new ticket
    • Assign ticket to "An existing owner of the ticket"
      • This preseves the original assignment of the enrolled ticket
    • Which ticket owner:  "Ticket Owner"
      • This preseves the original ticket owner of the enrolled ticket 
    • Ticket Name:  "Ticket Property:Ticket Name" - Survey
      • This preserves the original name of the ticket and highlights that this is the corresponding survey
    • Ticket Pipeline and status:  "Closed (Support Survey)"
      • Setting the Status of the new "Survey" ticket to Closed (Support Survey), creates the ticket in the "Support Survey" Pipeline and sets it to the Closed state immediately.  This will immediately set the wheels in motion for a survey to be sent.
    • Ticket Description:   http://app.hubspot/contacts/123456/ticket/"Ticket Property: TicketID"
      • I used the http url and the Ticket Property: TicketID to compile a http link back to the original ticket that was enrolled and was the actual ticket for which this survey was being created.
    • Associate with ticket
      • Contact associated to the enrolled ticket
        • This is necessary for 2 reasons
          • to ensure that the contact information needed for the survey to be sent is available and
          • to make sure that the survey ticket is associated with the contact.
      • Companies associated to the enrolled ticket
        • Necessary to make sure the survey ticket is associated with the company
  • Set "Send CES Survey" property to "Already Sent"
  • End

 

In terms of the CES Survey details, I didn't do anything out of the ordinary here.

 

Recipients:

  • Who?
    • Pipeline: "Support Survey"
  • When?
    • Set Delay:  15 Minutes

 

Summary:

For my needs and the needs of my organization, breaking this process down in this way has allowed me to build a CES survey process that gives me the flexibility I was looking for.

Workflow

  • The workflow above limits the enrollment of ticket to the specific "Support Pipeline".  This could easily be be adapted to include other different criteria or additional pipelines. send notifications etc... OR
  • The workflow could be duplicated and criteria altered to create customized enrollment criteria and actions that are unique to specific ticket pipeline.

 

There have been some additional changes made to the Survey functionality in HubSpot in recent months that are positive and I am happy they have been added.  However, I will continue to use this method for the foreseeable future as it makes available the full workflow capabilities of HubSpot as a way to control the sending of CES surveys to our customers.

 

 

 

VMazurenko
Mitglied

If it implemented it will be just great!

OBulava
Mitglied

+1

Please add more flexibility into Customer Support Survey so that it better surves our needs. Specifically, we are looking for:

- a way to change the questions, phormulate it in a better / more suiting way;

- to be able to not only pick a pipeline where survey is enabled, but exlude some tickets based on ticket properties, for examaple, category = spam -> close ticket without survey;

- to be able to exclude certain domains / accounts from receiving the surveys. We have long term customers and partners and we don't want to bother them with standard surveys.

James-Preseem
Mitwirkender/Mitwirkende

The CES survey that I am referring to in my post above is an industry standard survey that many organizations use as a common metric.  Because it is an industry standard survey, it isn't subject to being customized.   That said, for more a survey that has more flexibility in terms of what quesions to ask, the "Custom Survey" has the ability to send specific questions to customers and define a custom enrollment criteria.

Also, I believe that the custom survey can be used multiple times.  Given the enrollment criteria under the "Start from scratch" option under the recipients tab, you define ticket properties including (pipeline) and company properties (where you could add an exclusion for your long term customers).

 

 

Iffah
HubSpot Employee

Sharing idea on behalf of customer- Would also be great to include a 'remove when contact no longer meets criteria' option when using delays to send out surveys.