Tickets are investigated carefully so they can be handled in the best and most efficient way possible. Here’s how it’s done:
Regularly monitor the JIRA Service Desk queue to make sure all SLAs are met.
All New and Unassigned tickets must be given first response within 2 hours.
We recommend checking the Unassigned Queue every 20 mins. For reference, you may check all SLAs for various Ticket Status here.When a new ticket comes in, update ticket fields. Here are some guidelines:
- Fill out the Assignee field to your name. You can do this by clicking on “Assign to me”
- Confirm "Reporter" field is customer contact (may be initially listed as Sighten staff if message was forwarded)
- Make sure that the Request Participant field has no Sighten employees. If there are any, please remove them from the Request Participant list and make sure that they’re added on the Watcher list instead.
- Ensure "Organization" field is completed. In case the Organization can’t be ended, please go to Customers tab on JIRA and search for the Organization, or add if it isn’t added yet.
- Add anyone who should be kept in the loop as a watcher. This includes Account Managers.
- Update assignee as needed. Sometimes Assignees need to be reassigned after sending out a reply.
- Determine the Request type. There are several request types. The 4th number on this outline lays out how to set them apart:
Investigate ticket to determine the request type.
To do so, check the Subject and description of the ticket. Review any included screenshots and forwarded correspondence to have a better grasp of the root cause.
Categorizing the ticket correctly will help ensure that it can be resolved in the best and quickest way possible.
Here are the 7 request types:General Inquiry
This covers all questions about software navigation, features, usage, financier’s inquiries about the Sighten status of their new partners, as well as all other inquiries that don’t fit into other categories.
As a rule of thumb, if a ticket is yet to be categorized; meaning, if the request is vague or does not fall under any of the request types, it may first be categorized under General Inquiry. This can then be updated later on.
Here are other tickets that should be categorized under General Inquiry, as well as how they should be handled:
i. Sales inquiries from potential customers should be assigned to Joe Kelly
This includes current users who are not direct Sighten customers.
ii. Lifestyle contractor welcome emails
These are emails sent from Lifestyle, addressed to one of their partner orgs. The email would start with something like "Welcome to the Lifestyle Energy Financing Program!”. In this case, no reply or other action is needed. Close immediately as:
Request type: General Inquiry
Resolution: Other
iii. Contractor confirmation requests.
These are inquiries sent by financiers to confirm if an installer is already a Sighten client.
iv. Financier-specific or sales-related inquiries
This will be handled by Ops as specified for Company-Specific Data Change requests section below.Technical Support
These are tickets with concerns that imply that the software is not working as it should.
Support’s key role is to rule out possible root cause, and ensure that the issue is not a byproduct of a user-error, or a browser-related, or hardware-related issue, before forwarding the concern to dev.
If concern is ruled out as user error, support will provide appropriate training/documentation
If concern is ruled out as a technical issue/bug, support will resolve if possible through the troubleshooting guide here.
If Support isn’t able to resolve the issue through the troubleshooting guide, here are the next steps to take:
1. Support will document thoroughly and create linked bug ticket for Prod/DevIndustry-wide data change
These are data change requests that affect all businesses in the platform. Examples include adding, editing, or removing solar equipment, equipment manufacturers, and incentives.
Here’s how tickets requesting to add, edit, or remove incentives should be handled:
Send a reply to the customer to let them know we received their request and are now working on it. Then, create a CS ticket for the configuration team. Keep in touch with the customer for any follow ups or additional information needed, and with the configuration team for updates. SS ticket will be ready to close once CS ticket is placed in UAT Status.
i. Adding or updating SRECs. This can be done by Support as outlined by the process here.
ii. Adding Equipment. Support will maintain communication on the ticket and create a CS ticket according to the process here.Company-specific data change
These are data change requests that only affect the reporter’s organization. This includes adding, editing, or removing a financial product, product rules, contract templates, etc).
Here’s how company-specific data change requests should be handled:
i. Support will collect all the needed documents (sheet for equipment addition, link to the incentive for an incentive update, etc) and will attach to the ticket [Is this ticket pertaining to the CS ticket? Also noting that it would be nice to get screenshots of these, an assignment for myself later on].
ii. Support will maintain communication on SS ticket and create other required tickets as outlined here. Here are how some specific types of company-specific data change requests are handled:Request To Do Invite a new downstream org Support will create the CS ticket and establish the requested partnership according to the process outlined here. Small configuration requests - For adding incentive override: use SOP.
- For enabling and disabling features (docusign, Cost Buildup, PV Watts, Project Sunroof, etc): use SOP
- For updating utility degradation percent: use SOPNon-integrated financing products: Support will coordinate with the reporter and configuration team, and create a CS ticket according to the process here.
De-activate integrated financing: Support will coordinate with the reporter and configuration team, and create a CS ticket according to the process here.
Installer contracts/documents: Support will coordinate with the reporter and configuration team, and create a CS ticket according to the process here.
Any non-Tesla Sunlight Financial requests: Support will coordinate with the reporter and configuration team, and create a CS ticket.
If the request was directly made by sunlight, follow steps here.
If the request is made from a Sunlight partner, follow this SOP instead.Any Tesla-related Sunlight Financial configuration requests: Assign to Kira Gaza and send a Slack message.
Any other financier requests (Lifestyle, PACEfunding, Renew, etc.): Support will create the partnership on their own according to the process outlined here.
Any non-related financier configuration requests (such as questions on integrated qualification, webhooks, etc.)
Please assign to Bhargav Gor and we will answer.
Project-specific data change
These are data change requests that are only applicable to specific projects. This usually involves updating data on a specific customer site. Most of these are un-archive requests or updating legal contact information.
i. For requests to update legal contact information, refer to financier.
ii. For requests to unarchive customer site, follow the unarchive request SOP.Account Management
These are inquiries on billing, cancellation, subscription changes, and requests for company/team trainings, status checks, etc).
i. For cancellation requests, follow the Cancellation Request SOP. Please make sure to include the Account Owner as a Watcher.
ii. For requests to update billing information, assign to @Sarah-Jane. She will then send instructions on how customers can update their billing information here.
iii. For training requests, please respond by sending them a link to their Account Manager’s calendar to schedule the best time for training. Then, send a follow-up to ensure that an appointment has been booked. Account calendar links can be found here.
iv. Otherwise, support will re-assign ticket to the Reporter’s organization’s Account Owner. An organizations Account Owner can be found on the Support Salesforce Dashboard in Quicksight.Onboarding
These are emails automatically sent to Support to initiate the Onboarding of a new organization.Feature Requests
These are enhancement and feature requests that may include but are not limited to: suggestions to improve the UI, adding features on certain project phases, and so on.
For these requests, Support will document the request in Aha! First, Support will make sure that the feature request is unique. If it has been made before, Support will simply add the organization and SS ticket ID on the comments of the existing request. If it’s a new request, support will include Aha! link to the feature request on an internal comment on the SS ticket, and the SS ticket ID will also be mentioned or added as a comment on the Aha link. This is done to make cross-referencing easier in the future.
Draft a reply for the customer.
After all fields are carefully filled out as outlined in the steps above, draft an initial reply to send to the customer.
Initial replies can either be:- Probing questions - these are sent out if we need more details to proceed with the request
- First step to resolution - if we’re able to narrow down the issue right away, we can immediately send a resolution that the customer can try.
- A general initial response - Since we have a 2 hour SLA for all incoming emails, some emails need more time for investigation before we can send a troubleshooting step or needed probing questions. In these cases, we send out a general initial response to let them know that we received their request and are now looking into it. Let them know as well that we’ll be in touch right away once we have more news.
*For these cases, make sure to toggle the status from Waiting for Customer back to Waiting for Support. This is because we are yet to send a resolution for these tickets.
Handle Ticket as specified on SOPs and steps on #4
Follow-up with the customer regularly. Follow-up SLA's are found here
A ticket can be closed when:
- Customer has confirmed that the issue is resolved
- Sighten believes the issue is resolved, and at least one attempt to confirm with the customer has been made. If we don’t get a reply 24 hours after we send a confirmation, the ticket can be closed.
- When Sighten isn’t able to proceed without customer input (additional details, a more thorough description of what has happened), and customer has been unresponsive after we’ve attempted to follow up at least twice (2x).
- When there is an active low-priority dev ticket