We’re working to accurately gauge the time spent on each ticket. Please see our guidance on time tracking.

Each ticket needs to be appropriately tagged before it is Closed. Learn about tagging here.

To learn more about how to work on a day to day basis, click here.

Using Views

After logging into ZenDesk, navigate away from the home screen to the sidebar “Views” option.

Views are separated into Tiers. Tiers 4/5 are monitored by specific LSS per region. If you haven’t been instructed to work on Tiers 4/5, please use the other views Tiers 3-0 to find the most urgent tickets to complete.

The Non-tiered View

The Non-tiered View in Zendesk populates with tickets that come from unverified requesters. If a client uses an email they’ve never contacted us from before, Zendesk will place their ticket here.

Before handling any tickets from this view, you should look for the requester’s email address in Close.io to confirm what tier the ticket belongs in. If it belongs to Tiers 4/5, please send it to the LSS responsible for that queue in your region.

Once you’ve identified who this requester is, follow the steps in the Ensuring ZenDesk Tickets Are Attached to the Right Organization helpdoc before completing the request.

Using The Right Submit As Status

Tickets within ZenDesk can have a variety of statuses to reflect what work remains in the request. They help LSS understand from a glance whether or not they should pick up the ticket or if it’s already being handled.

Status changes are saved by using the ‘Submit as’ dropdown in the bottom left corner of the ZenDesk interface. In order to reassign/claim the ticket, save any notes on the ticket, or post public replies to clients, LSS need to have that content entered into the notes field and submit the ticket as the appropriate status.

Status Definitions

Open

An Open ticket is defined as a ticket assigned to an agent or agent group. To start work on any request, LSS should assign the ticket to themselves and submit as Open.

Open tickets are the heart of your support workload — they indicate those issues that you’re working on. We also set tickets as Open when assigning them to other teams, or for when awaiting action from a FH Team Member (i.e. the Account Manager).

New

A New ticket is defined as a ticket that has been submitted to the queue and has not been touched by an agent. Once a ticket’s status has been changed from New, it can never be set back to New.

Solved

We solve tickets when there is nothing more to do. For example, when the request is completed or more information is needed from client to move forward.

Solving tickets removes them from the queue, making sure LSS are more focused on the requests we can immediately resolve. Solving tickets also posts any public/internal note content, so be sure to formulate your response before pressing submit as Solved.

If or when the client responds, a Solved ticket is automatically re-Opened and assigned to whomever was working on it before.

If too much time has passed since the last communication, a new “Follow Up” ticket may be generated instead. The link at the top of any Follow Up ticket leads to the original request (for more context).

Pending

Do not use the Pending status. If a ticket can’t be acted on immediately but needs to be followed up on later, choose the appropriate action based on why the ticket can’t be completed:

1. Missing info – Internal: Leave it as Open and escalate the ticket to the appropriate people (regional LSS team, AM, OB, etc) through Slack
2. Missing info – External: Ask the client for the needed information to complete their request and Solve the ticket
3. Not Enough Time: Send the “Request Received” macro to the client and leave it Open for the next LSS to start their shift

Service Level Agreements are standards for the time it should take Live Site Specialists to acknowledge a new ticket. Different tiers are held to different standards. Please review the guidance from the Team Expectations & Day to Day Guidance for more information on how SLAs differ by tier.

If a ticket isn’t responded to before the SLA timer runs out, it is considered “Breached”.

LSS should prioritize breached tickets if they have the time to complete them same-day. As soon the LSS starts work on the request, they should post the “Request Received” macro if the ticket allows client communication.

The majority of tickets come directly from clients, who either email support@fareharbor.com or call into the Dashboard Support phone system with their request.

When a request needs Sites to complete it, Dashboard Support then routes these tickets to the LSS team by assigning them to the FH Sites Group in ZenDesk.

Unless explicitly stated otherwise, when Dashboard Support forwards the request LSS will handle all client communication from that point forward.

For tickets that are fully completed…

1. Populate the public reply field with the “Fh Sites Reply” macro

2. Change any information from the macro as needed (client’s name if provided, any clarification needed about the work done if you couldn’t fulfill the exact request, etc.)

3. Tag the ticket. At minimum, attach one duration tag (fhs_small, fhs_medium, fhs_large) and one task type tag (fhs_activityadd, fhs_pageadd, fhs_help, etc).

4. Submit as solved. The ticket will re-open and assign back to you if the e-mail is responded to.

For tickets that need additional information from the client…

1. Document the changes you’ve made so far in an internal note.
2. Add the “fhs_missinginfo” and “fhs_bump” tags. The bump tag will automatically remind the client you are waiting on information after a full day of no response.
3. Respond to the client in a Public Reply requesting the needed information.
4. Submit the ticket as solved. The ticket will re-open and assign back to you if either the original or bump e-mail is responded to.

Before anything, determine if the request will impact anything on the site.

1. If it will impact the site:
   1. Create a new ticket to assign to the general Support group using the FH Sites to Support Internal Request macro.
   2. On the new ticket, include in your internal note that the site will still need to be updated once the Dashboard changes are complete, so the Dashboard Support agent needs to submit a Sites ticket when they are finished (if you would like it assigned directly to you, please specify that).
   3. Notify the client on your original ticket that you’ve submitted the request to the Dashboard team and Sites will complete the remaining changes once the Dashboard is accurately updated.
   4. Solve your original ticket.
2. If it wont impact the site:
   1. Create a new ticket to assign to the general Support group using the FH Sites to Support Internal Request macro.
   2. On the Sites ticket, let the client know you’ve submitted their request to the Dashboard Support team and that they will reach out directly.
   3. Solve the Sites ticket as normal.

Dashboard Support agents will receive phone calls that contain Sites requests. Because Live Site Specialists do not speak with clients over the phone, we need to either communicate with the client via email or notify the right person to call the client instead.

When the Original Request Was a Phone Call

The Dashboard Support agent will answer the call, take notes on the full request, and complete any work concerning the Dashboard. Afterwards, they should create a separate ticket with the details of the Sites request and assign it to the LSS. This means a few things:

1. The new ticket should contain all the information the LSS needs to complete the request AND a link to the original phone call ticket.
2. The phone call is recorded through Zendesk, so the LSS may use that link to listen to what the client directly described to the Support agent (if the request seems odd or needs more detail).
3. With two separate tickets, Support can track how much time is spent by their agent and Sites can track how much time is spent by our LSS on the same request. Both people get credit for their part.

If a Dashboard Support Agent Assigns You a Phone Ticket

1. Find the correct email address for the ticket’s requester. You can search their phone number in Close to see if it’s registered under a company’s contact information and find the email address on file for that person (if there is one).
   1. What if there isn’t an email address for the person who called? Notify the Account Manager (or AM Team) through #account-management to give them a call.
2. Create a new ticket, and enter that email address in the requester field. You’ll need to submit the ticket as Open with an initial internal note containing a summary of the work to be done and the URL of the phone call ticket in order to get a URL.
3. Place a link to the new ticket inside the original phone call ticket, and close the phone call ticket.

If A Client Requests a Phone Call From The LSS

Notify the Account Manager of the ticket by using the LSS Updates workflow in the #account-management Slack room. Do your best to explain the situation to the AM to prepare them for the call and promptly complete the request once the AM gets back to you (if there is still work to be done).

Typically submitted by Account Managers, but available to any FareHarbor employee is the internal request form. All internal requests to LSS should go through this form (AM, OB, Strategic Partnerships, etc).

This form sends a pre-formatted email to our ZenDesk email address, which in turn generates a ticket. If the submitter selects either “FareHarbor Site Update” or “Dashboard AND FareHarbor Site Update”, triggers within ZenDesk automatically assign that ticket to our FH Sites queue.

Here is an example of a FareHarbor Site Update Ticket from the form.

Here is an example of a FareHarbor Site and Dashboard Update from the form.

Who handles client communication for internal support requests?

The form submitter must select whether they would like to handle client communication or if the Support Team/LSS member picking up the ticket can communicate directly with the client. Be sure to find and read the selection in the ticket details. Based on that selection, the following processes apply:

Ticket Complete: AM Handling Communication

1. Document all your changes in an internal reply. Use the LSS Updates Workflow in the #account-management slack channel with the Account Manager tagged and a note that the ticket is complete.
2. Close the ticket.
3. If an AM has feedback/changes to a completed request, they’ll likely respond through Slack.
4. Re-open the ticket from the link posted in Slack if more work is needed, notifying the AM again when the ticket is solved.

Ticket Needs More Information: AM Handling Communication

If you need an Account Manager to take action around a ticket (i.e. ensure a dashboard setup is correct, get more information/content), follow these steps:

1. Document all your current changes and what you need in an internal reply.
2. Use the LSS Updates Workflow in the #account-management slack channel with a brief summary of your needs and the account manager tagged.
3. Solve the ticket and tag it with ‘fhs_missinginfo’ and ‘fhs_amhelp’.
4. From there, coordinate with the AM as needed, either directly or through that Slack thread.
5. When you have the info you need, re-open the ticket (or create a follow up if enough time has passed) and complete the work as normal, notifying the AM when done.

The AM process is also reflected here and should be updated if the above changes.

Ticket Complete: LSS Handling Communication

The LSS will respond to the client and solve the ticket without notifying the Account Manager.

Ticket Needs More Information: LSS Handling Communication

If the ticket requires additional information from the client, the LSS will reach out with that request and solve the ticket as described in the Client-submitted requests section of this doc.

If you have not explicitly been given permission to complete Tier 4/5 tickets, please do not claim them. Specific LSS per region have been asked to monitor this queue.

The only difference in procedure for Enterprise tickets is that these LSS will be communicating with Enterprise Dashboard Support (sometimes called “4” or “4support”).

If you need to create a ticket to submit a Dashboard request for an Enterprise client, please follow the same procedure described in the Client Submitted Tickets section but assigning to the 4Support group in Zendesk rather than Support.

These senior agents have been trained on basic site edits, so they may only forward the requests that they are not qualified to perform on their own.

Currently, requests for theme updates, large activity/content requests, translations, site rebuilds and/or redesigns go to our Updates team. Please refer to the What is an LSS Project vs a Site Update? helpdoc for Updates criteria, ZenDesk procedure and more.

Sometimes a request will come through for changes to a FareHarbor Site that is still in the process of being built. You’ll discover this either in the process of reading the ticket, or when you visit the client’s site and discover that it’s currently not on our platform.

In these instances, we do the following…

1. Find the project in AirTable and check the “Status” field. If it isn’t “Live”, it means the site is still being built.
   1. If you’re having trouble finding the project, reach out in Slack through the Question Queue workflow in #fhs_all.
2. Locate the Project Coordinator assigned to the build in the Airtable Card
3. Copy the requested edits into a Google Doc and create a share link
4. Paste a comment in the AirTable card for the Site and tag the Project Coordinator
5. Inform the client that you’ve passed their request to the person building their site and that any additional follow-up will come from the Project Coordinator.
6. Submit the ticket as Solved.

If a ticket contains a Translations project, follow these guidelines.

Due to the complex nature of many of our support requests, we only claim other Agents’ tickets in very specific instances…

1. When a LSS has claimed a ticket, but not started the work requested and the ticket is about to enter SLA breach.
2. When a ticket needs to be transferred because another team member has a skill set better equipped to handle the issue.
3. When a team member is out of office or on vacation as has a ticket that re-opens under their name.

LSS should not prioritize tickets from their own region above others unless they have a functional reason to do so (like speaking the specific language of the requester or site). LSS should instead work the most urgent tickets (closest to SLA breach or specified as urgent) first.

If you find an urgent request that cannot be handled in your timezone for some reason, please post the ticket in the #fhs_lss Slack channel and tag the appropriate team:

1. @amer_lss
2. @apac_lss
3. @emea_lss

If the ticket concerns Javascript, CSS, or other custom site work, please fill out the Custom Request Form here and check #fhs-custom-requests for updates. Typically, if the instructions for a script call for it to be added to the “head” or “body tag”, the dev team will need to implement it.

If the ticket concerns a bug, please troubleshoot the bug per the instructions detailed here, submit the bug report form here and check #fh-sites-bug-reports for updates. The ticket is still your responsibility until the issue is resolved.

For more details on custom script and css integrations click here

If a ticket comes through for a website that isn’t a FareHarbor Site and just contains embedded book buttons and calendars, assign it to Dashboard Support so they can submit an Integration Request.

How you can identify a FareHarbor Site

A FareHarbor Site will always have our logo and “Powered by FareHarbor” at the bottom, like this…

Please Note: We have clients that have both FareHarbor Sites and Sites built by marketing agencies/freelancers/etc. If a URL isn’t provided, seek clarity so you can ensure the request makes it to the right place. You can check Close to see all the websites a client currently has.

Triage the ticket

If a Zendesk ticket enters the LSS queue that has SEO-related questions, it may be appropriate to escalate it to the SEO team if you can’t answer the request on your own.

Examples:

1. Client says that their SEO has dropped a 20% from last year
2. Client sent us a ticket requesting an improvement in their SEO
3. Client came in with tech errors from a semrush audit and wants us to review it
4. Client has gotten a notification from Google Search Console or Google Analytics describing an issue they don’t understand
5. Client wants to make a change to their website and wants to ensure it will not affect SEO performance

The LSS should post these kinds of requests in the #seo slack room using the LSS>SEO workflow, then change then assignee on the ticket to “FH Sites/SEO Team”.

Make sure to let the client know the issue has been sent to the experts! When reassigning the ticket, send the “FH Sites: SEO Request” macro to the client.

The SEO team will claim the ticket through Slack by reacting to the escalations with an emoji. After arriving at an answer, they will add an internal note to the Zendesk ticket and assign it back to the LSS member who originally picket it up. SEO will alert the LSS member in the escalation thread that they’ve added a response to the ticket.

LSS will deliver communication to the client and close out the ticket. If the LSS need more information before closing out the ticket, please continue the conversation in the #seo slack escalation thread.

Ask a fellow LSS for help! You can also ping the person who submitted the ticket in Slack to get clarification on the ticket, or ask for clarification from the client.

There are certain points when providing support that it makes sense to escalate tickets to the client’s Account Manager for them to step in.   

Why?

  Account Managers often have a closer relationship with the client than you will as a Support Agent, and have built a history with the client that increases trust and the client’s willingness to listen to their suggestions. This trust is indispensable when it comes to issues around a client’s website, which is one of the core components of their business.   

When?

  A client may be requesting something outside the capabilities of what we can offer and is refusing to take no for an answer. Make sure you’ve worked to provide an alternative solution to the client, and don’t be afraid to brainstorm with your team.

How?

1. Collect and document all the information regarding the issue(s) at hand in an internal reply on the ticket. This includes what you’ve done so far, any solutions you can offer, and other related information. It’s also a good idea to explain exactly what you need from the Account Manager, and give them points to communicate to the client.

2. Find out who the client’s Account Manager is using Close. Reach out to them in the #account-management Slack room using the LSS Updates workflow. Include a brief explanation of why you’re escalating the issue to them.
   

3. Teamwork makes the dream work! From there, the AM will work with you to develop a strategy for responding to the client.  

Every Saturday at 9 AM (MDT) the following message will be posted on the #fareharborwebsites slack channel:

There is also a workflow called Emergency Weekend Request that shows the same message when clicked if the support agent missed the scheduled message.

This way, the support agent has two ways of submitting an emergency request:

1. through the scheduled message by clicking on “Yes, this is an emergency”
2. through the Emergency Weekend Request workflow

When the support agent fills out the emergency form, it will post in #fareharborwebsites channel:

The region that will be picking up the ticket will be determined by the time the request is posted.

For instance:

• If the request is posted between 9am & 5pm (MDT) Sat or Sun, AMER LSS team would pick it up
• If the request is posted between 5pm & 1 am (MDT), APAC LSS team would pick it up, since this is their 9 – 5 pm weekend.
• If the request is posted between 1am – 9am (MDT), EMEA LSS team would pick it up, since this is their 9 – 5 pm weekend.

What we consider an emergency weekend and/or holiday requests are:

• Site is completely down
• Broken links (affecting the booking flow)
• Closures/Announcements applying to the current weekend or holiday

If the support agent posts in the slack channel during the weekend and its not an emergency. We can use the :no_entry_sign: emoji on the post and they will receive the following message:

The Emergency Weekend Procedure is a Global team effort. An emergency request will be rare, and we want to thank you for being part of the team and helping in every way possible.

Everyone makes them! But seriously, checking a few common elements can ensure your tickets come back with less client feedback and changes…

1. Missing Taxonomies
2. Matching Formatting of Activities
3. Updating Meta Descriptions For Duplicated Activities/Pages
4. Adding Alt-Text/Descriptions for Added Photos
5. Spell Checking Text Provided From Client
6. Matching Parent Page Structure and Page Hierarchy
7. Verifying correct shortname if working with multiple dashboard company.
8. Making sure you are working on the correct website. (Check Close).