needs-org tag with appropriate organizationsOccasionally tickets come in without an associated organization, which means that no SLA is applied.
Potential reasons this might occur:
@gmail.com)It could equally be the case that a ZD organization was manually created and the SLA type is out of date / incorrect. Many of the same principles apply here.
Please do not manually create organizations. This can break the ZD<>SFDC integration and cause users to receive incorrect SLAs. If you notice an organization needs to be created, please notify support-ops to rectify this.
This workflow applies if:
needs-org is applied (implied by above)gmail.com)
For GitLab.com, if a user cannot be identified as a customers, nor a trial or prospect, then change the subscription dropdown to "Free user" and choose the appropriate "problem type".
Note: Due to the type of subscription/license they receive, trial users often identify themselves as Ultimate or Gold customers. This form field does not need to be updated as SLA is tied to the ZD org.
When applicable, tickets should have one of the following tag (not both):
A long term solution is still being worked on, but in the short term, prospects are supposed to email Support using the email address provided to them or use the appropriate form field, which will automatically add the prospect tag.
Otherwise, prospects are identified manually either through form content, ticket content, or the sales rep posts about it in one of the Support Slack channels. In the last case, please add an internal note on the ticket.
You can manually add the appropriate tag to the ticket (using Apps > Tag Locker).
Once tagged, the ticket will move to the appropriate queue, and for prospects, with appropriate SLA. However, trials do not receive support (wording included in our "free user" macro), and prospect SLA is for guidance only.
While SFDC syncs organizations nightly to ZD, it does not include trial licenses because no organization account is created in SFDC, only a lead. So organizations on a trial will not show in ZD, and this workflow does not apply and we should not manually create these organizations.
To check if a customer is on a trial: In SFDC (see search instructions below), the Initial Source will likely say Trial (check that initial date is within the standard trial period).
For prospects, there will likely be an organization account with Account Type Prospect. However, the presence of an org with type prospect does not mean they receive pre-sales support.
For self-managed, you can double check for a license in the license app.
For GitLab.com, in the Customers Portal, trials are marked with an expiration date under the Trials column in the GitLab Groups Tab next to a namespace. If needed, also check the dotcom-internal project for manual plan changes.
You may attempt to find the organization within Zendesk using the search functionality. Do note that TLDs don't necessarily correspond to company names, so you may need to search in SFDC to find the appropriate organization.
Also, note that users may be using generic mail providers you might not be familiar with, so the TLD on their email address may not correspond with their company at all.
When in doubt, check SFDC
See: Looking up customer account details in Salesforce
At times, the organization exists in Zendesk but has the wrong service level. You can force a resync for the specific organization.
Customer.Edit the Support Level to something aside from the current level.Save.Edit the Account again to change the Support Level back to the original.Save.If you refresh the organization page in Zendesk, the proper service level should immediately be reflected. However, for existing tickets where the user was already associated with the organization, the appropriate tag will need to be added manually to the tickets.
See: Looking up customer account details in customer.gitlab.com
Important: Be extra careful here. If a large company has multiple subscriptions it may not be appropriate to add the domain. You'll need to add individual customers to the appropriate organization (see below)
Once you've determined the appropriate domain to add and identified the correct ZD Organization, you can click
the Domains field to add it.
If you don't have admin access on ZD, you can still make sure the proper SLA is applied by adding the user to the appropriate organization.
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.
If you see that the ticket still has no SLA after associating a user with an organization, it could mean that this
organization has some special status on Salesforce side. One of the edge cases - the organization is marked as
Former Customer and support level is set to Expired. In such case it is better to check with Sales if the
status is valid or not:
Show feed button at the upper part of the page
@Sales-Support,
they should be able to help with such casesNote: 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.
Example of the message:
John Doe (Support Engineer): @Sales-Support, this organization has
Support Level set to Expired. Can you clarify if the support is really expired
and if we should decline support (they opened new ticket) 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.
Once you follow the above procedure, mention that in the internal note of the ticket (e.g. with Salesforce link) so that others can pick up from where you left off.
