Assuming a ticket has:
then we need to ensure the ticket:
Tickets should have the appropriate SLA according to the support service levels.
Some values for GitLab Plan for ZD organizations (called Support Level in SFDC)
do not receive a SLA if they are linked to a service level. These are not expected to have SLA:
Community. EDU and OSS program do not include Support, but are in SFDC and synced.Expired. Former customer with expired subscription. If you believe this is incorrect, see Handling customers with incorrect expired support.Hold. This is rarely used and indicates delayed payment or another issue with the sales process.
Consider contacting the Account Owner (Manager) to clarify the customer's status.
Note that we have an ongoing issue
that causes a lot of accounts to be incorrectly shown as Expired in SFDC.
See the Handling customers with incorrect expired support section for these cases.
In other cases where there is a mismatched Support Level in SFDC and GitLab Plan in Zendesk,
you can follow a similar process as the expired support process.
However, if you're unsure, it may indicate a potential problem with the SFDC -> ZD sync. Open an issue in the sync project.
If you believe a customer marked as Expired support and Former Customer is in fact a current paying customer,
follow this process to verify and fix the issue.
Show feed button at the upper part of the page.
@Sales-Support username in SFDC, they should be able to help with such cases.
Make sure that @Sales-Support is converted into clickable username, otherwise
Sales Support team will not get your message (see the GIF below):
Example of the message:
John Doe (Support Engineer): @Sales-Support, this organization has
Support Level set to Expired, and they opened a new ticket. Can you clarify if
the support is really expired and if we should decline support for this customer, or
this is some kind of error and Support Level should be updated? Customer also
provided screenshot of their license and it seems valid.
Prepending your message with your name and role (e.g. John Doe (Support Engineer):
helps as everyone in Support is using a shared account so it is not possible to
deduce who sent which message.
Note: the same workflow applies if you notice that customer-related
information is not up-to-date on SFDC side and you are not able to update it
using our generic Support Admin account.
Expired organizationThis part should be done in combination with the above section to fix future tickets.
If data in SFDC or CustomersDot show that the customer has a valid subscription you should update the ticket in Zendesk side.
For the specific ticket:
Tags field where all the tags are listed.x next to former_customer and expired tags to remove them.bronze in Tags field.
Note: When you assign a tag, there is a chance that the ticket will breach immediately. It is not strictly necessary but, if possible, send a public reply before you assign tags to prevent breach. Or, write your public reply and apply the tags, to submit the ticket with both changes at the same time.
Now that you've added the appropriate domain, head back to your original ticket and verify that it is associated with the appropriate organization and SLA.
GitLab Plan is shown as Expired.GitLab Plan value on Zendesk side will change from Expired to the valid one after the sync is done.
After that new tickets from this organization will be shown correctly.Check the SLA by plan for a list of types that do not receive SLA. Otherwise, the lack of SLA may be one of the following cases.
Tickets do not have a SLA if the latest public reply is from a Zendesk Agent (Support member). The ticket should be assigned to someone, and there should be nothing to fix.
When a customer responds to a ticket from an email address that is not included in CC or is not the original requester, the customer's response is recorded as internal. There is a trigger which sends an internal note to remind people to add the user to CC and reply, see this issue for more details.
If the email is obviously the original requester, you can merge the users.
Alternatively, add the email of the customer to CC.
Please reply (or let the assignee know), including a note to let the customer that a CC has been added to the ticket. For example:
We got a note from John with email address john@domain.org. From the context it looks like they should be included in the ticket, so for convenience I added them to the CC list. If they shouldn't be included, please let us know so we can remove them.`
After that, the cc'ed user's next replies will not be marked as internal anymore.
Tickets should show in the appropriate view(s).
When a ticket is initially created or an org is first tied, the ticket will receive all tags associated with the org.
This means that orgs with multiple subscription related SLA tags (such as silver and premium),
the ticket will show up in multiple views.
Remove the SLA tag that does not apply for the ticket.
If you find an org with multiple active subscriptions and it's missing the appropriate tag(s):
By default, priority_prospect tagged tickets will be shown in both SM and GitLab.com views.
To make it visible only in the appropriate view, add either prospect_saas or prospect_sm tag to the ticket.
In cases where a ticket is showing in the wrong queue:
prospect.If there's anything that doesn't fit in the relevant workflows, you can investigate and try to fix it.
Important: Always leave internal comments when doing something on the SFDC side or modifying some tags in Zendesk. It will help the next engineer to understand what was done in the ticket.
If you have any questions, please ask in the #support_operations Slack channel.