Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 18 Next »

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 a first response within 2 hours. 
  • Someone is typically assigned to monitoring the queue and assigning tickets as appropriate - otherwise, we recommend all agents check the Unassigned Queue every 20 mins. 

When a new ticket comes in, update the necessary ticket fields. Here are some guidelines:

  • Fill out the Assignee field with your name. You can do this by clicking on “Assign to me” 
  • Confirm that the "Reporter" field is field out with customer's contact details. (This may initially be listed as @goEverBright if the message was forwarded from a staff person).
  • Ensure that the "Organization" field is filled out accordingly. In case the Organization can’t be entered, please go to Customers tab on JIRA and search for the Organization to find the right name, or add it if it isn’t added yet.  If a channel partner, use the channel manager's name
  • If related to EverBright financing, add "EB" to the "label field" on the right
  • Check the "channel field" and make sure phone, email, or chat is selected - or select multiple channels if you needed to use a combination of channels to resolve the original request
  • Add anyone who should be kept in the loop as a watcher (eyeball icon at the top right of the ticket) 
    • However, if account managers should be looped in, send them a slack.  You may find the list of accounts and their managers in SalesForce or the support dashboard in QuickSight
  • Update the Assignee as needed. Sometimes Assignees need to be reassigned after sending out a reply.

Determine the Request type. There are several request types. We've listed guidelines for categorizing request types below.

  • Investigate the 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, 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. More information and examples of General Inquiry tickets can be found here.

    • /wiki/spaces/SS/pages/694026241

      • These are tickets with concerns that imply that the software is not working as it should or there is a question on a technical request, like how to properly format an API request. Support’s key role is to rule out the 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.  More information and example of Technical Support tickets and examples can be found /wiki/spaces/SS/pages/694026241.

    • Industry-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.

        Here are two other specific industry-wide data change requests, and how they should be handled: 

         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 and will attach to the ticket 

        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:

RequestTo Do
Invite a new downstream orgSupport 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 SOP
Non-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.


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

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 new ideas, and feature requests, Support will document the request according to the process /wiki/spaces/SS/pages/2468970577


Send an initial reply to to the customer

Here are types of initial replies:

  1. Probing questions - use if we need more details to proceed with the request
  2. First step to resolution - if we’re able to narrow down the issue right away, we can immediately send a resolution or a suggestion the customer can try.
  3. 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.
    1. 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.

Follow-up with the customer regularly. 

A ticket can be closed when:

  • Customer has confirmed that the issue is resolved
  • We believe 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 we can't 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










  • No labels