If you're reading this manual you've realized that email folders, sticky notes, or even your current help desk tool are no longer the way to handle Customer inquiries. You're looking for an improved experience for Staff and Customers with more advanced capabilities to manage your support operation...Welcome to HelpSpot!
HelpSpot's core function can be summed up as:
"HelpSpot is a web-based application that empowers companies to effectively manage Customer inquiries."
To create a product that is optimized to support this core function, we kept a few guiding principles top-of-mind:
Customer inquiries come at you from every direction. HelpSpot accounts for this by supporting the channels you need:
The needs of every company differ; some require elaborate issue categorization and meta-data collection capability, while others only loosely categorize issues. To accommodate all types of companies, we provide a structured framework of data collection/categorization that is fully customizable yet still easy to report against.
Individual ownership is required in HelpSpot. Requests cannot be assigned to a nebulous workgroup or department. Individual ownership is the cornerstone of driving processing efficiency and ultimately Customer satisfaction.
Every request has a complete log of all actions taken and messages sent. This allows any User, at anytime, to become current with a request.
This manual is intended for all HelpSpot Users, those new to help desk software as well as those migrating from another product.
Administrator-specific settings and configuration options are not covered in-depth in this manual.
The following terms are used throughout this guide:
A Users permissions settings and/or level dictates access to features. Permissions are set by Administrators, typically at time of Staff account creation.
By default, HelpSpot comes with 4 built-in User levels. Below is a high level look at each.
|Global and System Settings||Inbox||Access to in Assigned Categories||Access to Assigned Requests|
|Help Desk Staff||X||X||X|
|Level 2 Support||X||X|
As the table shows, User levels have graduated permissions ranging from broad site access (Administrator) to most restrictive access (Guest).
The permissions for any default User level can be modified, through the permissions group management area in the Administration section of the site (accessible by Administrator level only).
Administrators can use the Permission Groups area to create a new permissions group. New Groups can be cloned from existing User levels for ease of creation.
For example, you need two Guest level Users to be able to manage knowledge books. First, clone the Guest level user then check off for them to have knowledge book management access. This will give the Users Guest level access with the added knowledge book capabilities.
While this guide doesn't specifically cover Administrator configuration, the following provides Administrators with a quick look at the most important steps for getting the installation up and running. More detailed Information on configuration can be found in the HelpSpot Administrator area of the UserScape site (http://www.userscape.com/helpdesk/index.php?pg=kb.book&id=1).
The initial password for Administrators is start. This should be changed after initial login.
(Location: Admin>Settings) The settings page includes several system-wide configuration options that range from creating status types to defining the layout of the Customer portal. Administrators should review and become familiar with each as an initial step in the set-up process.
Status types are most useful for defining the resolution for each request.
(Location: Admin>Staff) User accounts must be created and assigned access to the system. The following provides a high-level look at each permission level.
(Location: Admin>Organize>Categories) To effectively route requests and allow for concise request reporting, Administrators will need to define request categories. Permissions for default ownership, accessibility by assigned Staff, and visibility on Customer portal must also be set for each category created. Reporting tags for each category are an optional way that further classifies individual requests.
(Location: Admin>Email Mailboxes) HelpSpot mailboxes serve as a way to seamlessly integrate email exchanges. By adding individual mailboxes, HelpSpot can pull all messages sent to existing support email account and create new requests or append notes to existing requests. Through additional configuration, Administrators can opt to route requests resulting from emails into specific categories or auto-assign to selected Staff.
(Location: Admin>Organize>Custom Fields) Custom fields are a means to create User-defined fields for the collection of meta data. With 11 different types available Administrators have a robust, structured framework for collecting the information specific to their product/service or organization.
When an account is created, the User receives via email his/her account login information. Upon login Users are brought to the workspace which is where our guide begins.
The workspace, or the initial landing page, can be thought of as the hub of all request management within HelpSpot. It is from here that Users can access individual request management functions: creating, viewing, and updating. This chapter looks at the basic structure, layout, and function of each of the areas within the workspace.
For the purposes of understanding the overall structure, let's break the workspace out into three areas. These areas are briefly introduced below and covered in-depth in subsequent chapters.
On a very broad level the Inbox is home to all unassigned requests. As such, its primary function is to serve as the entry point for new requests (submitted via email, portal or other channel).
Users can take a request from the Inbox by simply clicking on the Take It button to the far left within the request grid. Upon doing so, Users will immediately be taken to the request page for that request. Ownership begins as soon as a User takes a request out of the Inbox; it is no longer shown in the Inbox and will instead show in that User's My Queue.
As mentioned in the previous section, once a request is assigned to a User it is no longer available through the Inbox and can be found in the User's My Queue.
Request assignment can occur in several ways: User takes a request from Inbox, one User assigns a request to another User, or an automated process handles the request.
Once a User clicks My Queue, the request grid in the center of the screen will load all the open requests assigned to that User.
The list of requests shown here will vary between Users because it reflects the requests assigned to the person logged-in. Additional views, or filters, can be created and saved for viewing requests assigned to others.
HelpSpot uses My Queue as the default view when Users login and click the Workspace tab. However, this is customizable, allowing Users to select any filtered view as the default.
SPAM (overt advertising, typically created via an automated process) is a common problem for support centers that openly publish support email addresses or web-forms. To prevent it from interfering with true Customer inquiries or incorrectly skewing reporting, HelpSpot has integrated a trainable SPAM tool.
HelpSpot will initially depend on Users to flag requests that are SPAM. Over time, while this flagging is being done, HelpSpot will learn to recognize the SPAM specific to the installation and automatically flag it accordingly.
Users can flag requests as SPAM in either the request grid (using the quick action buttons) or in the request itself.
All requests flagged as SPAM are available via the SPAM link in the left navigation. From here, Users can use the request grid to click into the request or select and delete it.
Messages which are sent to SPAM but later marked as NOT SPAM by a User also helps train the SPAM tool to not incorrectly mark requests as SPAM.
If either a User or the SPAM tool incorrectly flags a request as SPAM, check the box next to the request and use the drop-down at the bottom of the request grid to select Mark as Not SPAM. After hitting submit the request will move into the Inbox where it can be taken by any User. Marking a request as NOT SPAM will train the SPAM tool to not mark notes from that sender as SPAM.
SPAM must be deleted to reinforce the systems learning process. To delete, check the box next to each request and use button at the bottom of the request grid to delete the SPAM. Once this is done it will be completely removed from HelpSpot.
Requests that aren't necessarily SPAM but don't need to be worked or counted towards reporting can be flagged for the Trash. Using the Trash is a means for handling email bounces, training/test requests, and duplicate requests.
HelpSpot provides Users with a several different ways to find requests within the system. Each method is optimized to find the single-specific request, or group of requests.
Simply type in the customer or request ID to be returned the request(s) that meet the criteria. User's can also opt to do an advanced search. More on advanced search is covered below.
Advanced searches can be done on a myriad of customer, request, and installation-level details.
Users can search against any/all customer specific information found on the request page. Results are returned below the search boxes and clicking the linked request ID will allow Users to go directly to the request page for the individual request.
This search type allows Users to create a more intricate, specific set of search criteria. At a high level, the parameters by which Users can search are grouped by the following:
Users need to go into the filtered view to modify filter (such as making Global or modifying columns). Once in the filtered view, select the edit filter link in the options menu to make the necessary changes. For more on managing filters, see the filters page.
Filters are custom-created views of requests. Each filter has a set of criteria, defined by the creator using specific conditions that requests must meet to be returned in the results set. Filtered views can be created and saved on the User or global level.
At the bottom of the left nav, Users will see a list of both personal and global filters. Personal folders can be listed invidually on the left nav or grouped into folders. All global filters are listed within the global filter folder. There maybe sub-folders, if such were created. To access the contents of a filter, Users must simply click the filter name.
To modify the properties of a filtered view, simply click the edit filter link under the filter options menu (in request grid view).
For more on the specifics of Filter modification, see the Filters page of the manual.
The request grid is the display area for requests meeting specified criteria. The criteria will vary depending on the filtered view (Inbox, My Queue, or custom-filtered view) the User is in.
At the top of every request grid is the name of the view. For those views that are system created, it will be the names designated by HelpSpot; Inbox and My Queue. For those views created by Administrators or Users, via filters, it will be the name designated during filter creation. Just after the view name, Users will find a request count in parentheses. This count reflects the number of requests that match the defined conditions.
To the far right of the name and count, Users will find groups of icons that represent various actions that can be taken on the requests within the view. Those are broken out into:
The request grid returns specific information, in columns, for each request that is included in the results set for the view. The Inbox and My Queue have a default set of columns that are returned. Those columns returned in custom-created filtered views are defined by upon creation. Working left to right in the request grid, the default columns are outlined below.
Users can click the green/grey dot to change the read/unread state.
By default, HelpSpot loads each filtered view a grid-type layout (as outlined above). However, on the fly, Users can switch to the note stream view that shows only the real-time activity of requests. Users can specify if they want to see the following update types:
Users can think of this view as a timeline of request activity within the filtered view.
Simply clicking the grid-like icon will return Users to the standard, request grid view.
The quick action buttons allow Users to perform actions on request(s) directly from the request grid page, saving the need to enter the request page for each individual request. Quick action buttons can be found at the bottom of the request grid in all filtered views.
All actions are preformed by selecting the checkbox next to the desired request(s), than click the desired action button.
Available quick actions include:
At the top of each filtered view, within the name header, Users will find various options for viewing/editing that view.
The details of these view are described more in-depth on the General Layout page, linked under related pages.
For each filtered view, Users have a few options available to them. The Inbox and My Queue, because they are system default views, have a limited list of options available.
Only available for Inbox and My Queue. Allows Users to configure those default items included in the request grid view.
This only shows to the filtered view creator or an Administrator. From this link, the parameters of filtered views, permissions, and how they are displayed can be modified.
Any filtered view can be made as a Users default landing page when entering the Workspace. When used in conjunction with a Take It button, any filtered view can be used as an organizations/work groups default inbox.
RSS and .CSV export. The contents of any filtered view can be exported to either an RSS reader or .csv supporting application.
Along the top, Users will find icons to access other areas of HelpSpot. Not all icons are available for all User levels.
Top navigation icons include:
Filters are custom-created views of requests. Each filter has a set of criteria, defined by the creator using specific conditions that requests must meet to be returned in the results set. Filtered views can be created for use by various groups of Users. The filters button can be found just below the top navigation, above the request grid, in the Workspace.
To see how filters are used, see the Filters in Use: Working Examples page.
When creating a filter, Users can define an infinite number of conditions, and combination of conditions, that requests must meet to be included within that view. Conditions are based on individual elements of the request, Customer, or actions taken on a request. Users must define if the requests should match any or all conditions provided for the filter.
For each condition there is a means to define the value, via either a drop-down or text field. Each condition provides an additional drop-down for selecting the operator (for example: greater than, less than, is/is not) to define how the specified value is applied.
For more advanced filter creation, sub- or nested groups of conditions can be created using the advanced condition of ALL/ANY of the following are true. When either is used, nested drop-downs will appear where the sub-condition group is created.
To test the condition(s), Users can hit the Run filter button just below the conditions box. The results will truncate to show only the first 30 requests in the results set. However, the top of the results set shows the number of requests that match the condition(s) set. To see all requests, check the Show all Results box prior to running.
The results will return based on the preferences set in the Save filter box to the right of the screen. To see the results set, with the desired preferences (such as columns and sort) included, set preferences before running the test.
Once a User is satisfied with the conditions set, as demonstrated through the results presented in the testing, they can move to the final steps of setting preferences and saving.
As mentioned in a previous chapter, all filtered views are displayed and accessed via the left navigation (nested or individually listed).
Administrators and the designated creator can edit a filtered view. The link to edit can be found under the options link within the request grid layout of the filtered view. Once clicked, Users will be brought to the filter creation/modification page.
The create request button, below the top navigation, is used to manually create requests. Requests would typically enter the system via email, portal form, or API. However, there is a means to create request for such customer encounters such as phone or IM.
Once a User clicks the create request button, the request page loads.
Responses are predefined messages, available to Users when updating requests and/or responding to forum posts.
Responses can be created with stylized text (bolding, bulleted lists, etc.) and contain placeholder information, such as assigned Staff members' email addresses or request IDs. Additionally, specific actions can be tied to the use of a response (ie: changing categories, status, or assignment). As with the use of the response itself, the associated actions can be a huge time saver for Staff.
The page is broken out into a complete list of all active responses (click to edit each). Below the list is the form to add a response. Users will be required to define a name, location, and permission access for the response.
Users can expand the power of the response by defining specific actions to be taken on the request when responses are applied. Actions can range from updating a category or status to adding a private note. Any actions taken as a result of a request, will be logged within the request history.
Users can follow changes made to requests that aren't assigned to them by opting to subscribe to a request. The Subscriptions button allows a User to access all requests for which they are subscribed. It is from the subscription list that Users can view the individual requests or delete the subscription.
From the request page of an individual request, Users can set a reminder. Reminders are emailed at the designated date/time to selected Users and are listed under the reminders area of the workspace.
To access all of their reminders, Users should click the Reminders button. Once in the reminders list, Users can click the request ID to go directly into an individual request.
The request page is the Customer email, portal form submission, or phoned-in inquiry translated into a request; it's the core of individual inquiry/request management. From here, Staff can reply to the Customer, add meta-data, categorize, and assign the request.
The request page is accessible only for those with a HelpSpot account. The primary ways Users will access the request page include:
When a filtered view (including inbox and workspace) has more than one request, Users can easily navigate between requests through the use of the next and previous buttons in the top right of the request page. This eliminates the need to go back to the workspace to enter the next request.
For the purposes of understanding functionality, the request page can be divided into 5 main areas.
For every request, HelpSpot provides fields for logging Customer-specific information.
HelpSpot will automatically populate as much information as possible for requests initiated via the portal form or an email. For requests manually entered by Staff, the Staff member must enter the Customer information as part of the request creation process.
Within the History Search tab, Users can see all open requests for that customer. Searches default to General, however it can be quickly adjust to search on such parameters as domain name or Customer ID. Upon clicking the Customer ID for any request, you see a preview of the request with the option to insert customer data in the current request.
Live lookup allows HelpSpot to communicate with an external database (or other system that stores Customer data, pertinent to the support staff desk). Its power is it provides real-time display of data from external systems within HelpSpot, ensuring Customer information and custom field data is always accurate. For information on configuring Live Look Up, see the Administrators Manual.
HelpSpot offers two formats for creating/sending updates via email: HTML (via visual editor or formatted text) or plain text.
HTML formatting can be done in one of two waysâvia a visual editor or formatted text. Both provide the same end-result yet require Users to apply style in different ways.
HelpSpot defaults to sending/receiving HTML emails; so 'out of the box' Users will see a formatting tool bar across the top of the note box to support the sending of HTML emails. This tool bar functions similar to formatting tool bars in Microsoft Word and includes a spell checker to the far left (if enabled during installation). To format text, type in the box, highlight and click the desired formatting option.
For installations with formatted text enabled, HelpSpot uses a formatting text mark-up to modify how text is displayed. Formatting covers the basics most Users would need for a note such as bolding, underlining, linking, and bulleted lists. HelpSpot converts the mark-up into HTML once the User submits the update. The Formatting Options link opens a window listing the characters that must be used to achieve the various formatting effects and serves as a reference when applying styles.
As we review the note types, keep these key HelpSpot principles in mind:
These notes are used to provide the Customer an update on their inquiry. Public notes are:
Others, outside of the Customer or Users, can also receive a public note. Those individuals should be listed as a CC or BCC.
To add a recipient, click the Add a CC Email or Add a BCC Email, type the recipients email address and click Add.
When an email address is added, the recipient will continue to be included on all public updates until the address is removed. To remove the email address, simply click on the email icon next to the address.
As part of the public note options there are fields to modify the email subject and change the sent from email address. Users may find modifying the subject is an easy way for recipients that aren't familiar with the issue to understand the contents of the message they received.
Modifying the email subject doesn't mean you lose the interaction in HelpSpot. Because HelpSpot auto-appends the request ID to all subjects of outgoing emails, any responses will be correctly logged within the request history.
Staff may want to make a note on an action they took toward addressing a request, such as: making a phone call or leaving a note to the assigned staff member. In such cases, the private note should be used. These notes are logged within the request history however, no email is sent to the Customer (nor is there an option to send the note via CC or BCC).
The external note capability allows Staff to work with the necessary resources while still having the entire interaction logged within the request history. Customers do not receive email updates when an external note is used; only the specified recipients will receive the message when an external note is created. The external note options are the same as the public note options (CC/BCC options).
There are a few options that can be used for all note types. These include:
Every action completed on a request is logged within the request history. Actions can range from a note to the Customer to the logging of request detail changes. Logging all interactions enables any User, at any time, to become current on the happenings within a Customer request.
Users also have the option to filter history by: Full History, Only Notes, Public Notes, or Files.
While the actions that create the entry may vary, the basic look and feel of all entries remains the same.
HelpSpot includes the following in every entry type:
When hovering over a Users picture, Staff can access a menu for the following:
Across all entry types, images attachment are embedded within the request history for ease of viewing. For all other file types, there will be a link for downloading.
The request details area contains the information necessary to manage the working of the request as well as the data to classify the request for reporting or automated processes.
Users have the ability to assign a status to a request. A status assignment can reflect a milestone in the resolution process, including what led to the closure of the issue. For example, HelpSpot provides the following by default: active, problem solved, Customer found solution, Customer unreachable, and software bug. To close a request, Users must select a status type other than Active.
HelpSpot comes by default with a few status types to get Users started however; Administrators can customize the list of status types.
On a very basic level, categories are used in HelpSpot to group-like requests together. This grouping can range from defining the nature of the inquiry to specifying the work group/department responsible for resolution. HelpSpot's flexibility allows organizations to best define the function that the category assignment serves.
It's important to keep in mind that beyond just a simple label, each category defines the types of meta-data collected for a request by tying request assignment, reporting tags, and custom fields directly to the category.
Appropriate category application, in conjunction with the meta-data collected, can provides help desks with a framework for workflow management.
Administrators must define the Users that have access to work requests within a specific category. Once this is done, Users will see on the request page a list of Staff to which a request can be assigned. This list will always contain:
To select a Staff member, Users should use the dropdown to navigate available Staffers. Assignment is immediately applied as soon as the request is updated (via the Update Request or Update and Close buttons).
Assignment is the cornerstone of creating a request workflow. Once assignment is selected and submitted, the request will move to that User's My Queue and be flagged as unread for them to work.
Assignment can also be the basis for generating:
Within each category an additional level of classification is available via the reporting tags. The selection of a value within the category drop-down will determine the reporting tags displayed.
Users can select as many reporting tags as applicable for the request by click the checkbox next to the tag. When the Update or Update and Close buttons are clicked, the tags will be applied to the request and logged within the request history.
At anytime reporting tags can be un-checked when no longer applicable.
Because HelpSpot ties reporting tags to the categories, when a category changes, any reporting tags selected under the previous category will no longer apply and new tags must be selected.
Reporting tags can be used to create:
Custom fields represent custom meta-data that can be collected for a request. There are 11 types of custom fields available to Administrators for creation. These data field types can be used in a various combinations to collect the information necessary for meeting specific business requirements.
In addition to showing custom fields on the request pages for Users, Administrators can also make selected fields available to Customers via the portal web form (note: not all are available in the portal). In these cases, a custom field that is populated by the Customer will be displayed to the User on the request page.
Custom field values are applied to the request as soon as the Update Request or Update and Close buttons are clicked. Custom field changes/updates are logged in the request history.
Uses for custom fields include:
Within the header of the request details, there's an options menu that allows Users to:
Users can select to print a printer-friendly version of the request.
Set a reminder specific to the request, using the reminders icon along the request details header. Reminders can include a note along with the inclusion of additional Staff. All reminders for the logged in User are managed via the reminders area in the Workspace.
Knowledge books allow an organization to create documentation for their products/services. Books are organized with chapters and pagesâproviding a familiar structure for ease of navigation.
Throughout this section reference will be made to public and private knowledge books, the differences are:
Within the Knowledge area, books can be created via the Add a Book button.
During book creation, specify the book-level properties such as name, book editors and book type (public/private).
As soon as a public knowledge book is added it will be live on the portal. To prevent Customers from seeing partial books, select Yes to making your books private until you're ready to have them go live.
Using the Books Order button, Users will be brought to a page to sort either the public or private books.
All books (public and private) are listed on the left navigation. To edit any one of those books, click the title and use the edit book button within the book table of contents screen. The form to modify is the same as the one used to create the books. Keep in mind that when a book is deleted, all content within the book is deleted as well and cannot be recovered. When it's gone, it's gone!
Within the book table of contents page (accessible by clicking the left navigation), Users should use the Add Chapter button.
Chapters default to being visible (not hidden). Hiding chapters is useful when adding content to an existing, live book.
Chapters can be designated as an appendix, meaning they will appear at the end of the book without a chapter number.
Next to the chapter name on the book table of contents page is the edit chapter button. It is through this area the parameters of the chapter can be modified or a chapter can be deleted. Keep in mind that when a chapter is deleted it can not be recovered. When it's gone, it's gone!
Again, from the book table of contents page, Users should use the Add Page button located next to each chapter name to add a page within that chapter.
Adding pages is a two-step process. The first step requires naming and sorting order be selected. During the second step page content is created. Pages are defaulted to being hidden, viewable only to editors, for the purposes of creation. When you're ready to go live simply flip Hidden to No.
Editors can also link related pages, flag a page as highlighted or add an attachment file to complete the content of the page.
The built in visual editor, similar to Microsoft Word, allows Editors to stylize and format the content without the hassle of hand coding the necessary web mark-up. Type the desired content into the text box, highlight, and select the desired action from the tool bar.
Editors can copy/paste documentation already existing in Microsoft Word format into the visual editor to make page creation go quicker. However, the documents must first be saved as HTML (outlined below). This will hold most of the original formatting for moving into the knowledge book page.
1. Open the document in Microsoft Word.
2. In Word, go to File>Save As in the top menu.
3. In the file dialog box, select a location, modify file name, and change file type to save as html.
4. Open the saved HTML file of your documentation in your web browser.
5. Highlight desired text. Copy and paste into Page Editor in HelpSpot.
Each page can have any number of knowledge tags associated with the page content. For more on how to set knowledge tags and how they work see the knowledge tag page, linked under related pages.
Clicking the chapter title, within the books table of contents, to get to the page content. The page editor is accessed through the edit page button. From here, pages content and properties can be edited. When pages are deleted all content will be lost and cannot be recovered. When it's gone, it's gone!
HelpSpot's forums allow Users to create an engaging, self-service community where Customers and Staff can contribute to the collective knowledge of your products/services.
Forums have a hierarchical structure. At the lowest level there are posts, where readers will put their questions and/or comments and other readers will respond/comment. Posts can be thought of as individual thoughts submitted by readers, which collectively roll-up into a topic. These grouped thoughts, or topics, in turn roll-up into the larger structure of the forum.
Throughout this section reference will be made to both public and private forums; the differences are highlighted below.
Through the Manage Forums button, Users are brought to an area that both lists existing forums, for editings, and a form for creating new forums.
Forum creation is simple and requires just a few bits of information, including forum name, designated moderators, and open/close status. Once saved and opened, it is ready for posting.
Again, through the Manage Forums button, Users will see all public and private forums. To manage any, Users can click the forum name to be brought to the forum management form.
Clicking the forum name in the left navigation will bring Users to a list of all topics within that forum. Below the list of linked topics there is a form for adding a topic.
When adding a topic, Users must complete a series of fields. Included is the ability to make the topic sticky and subscribe to replies.
Once a topic is posted it will immediately be live within the forum. The steps for creating a topic are the same for both public and private forums.
If Moderators wish to draw attention to a specific discussion or topic, within a forum they can do so by selecting 'Yes' to the Topic is Sticky question within the Moderator Topic Controls box.
Sticky topics will always appear at the top of the topics list within a forum, both public and private.
Creating sticky topics that are closed can serve as means to creating a prominent area within a forum for posting Forum guidelines (rules) or announcements to readers.
All Forum topics can have any number of knowledge tags applied to the it. For more on using knowledge tags, see the linked related page.
All topic moderation occurs through the moderation box at the bottom of the topic page.
Moderator capability is limited to those who have been given permission by an Administrator.
When a discussion has run its course, or if Moderators need to reign in a discussion that has wandered from the original topic, clicking 'Yes' in the Closed dropdown will close a topic⎯preventing additional posts from being added.
If a topic seems to be automated, overt advertising or inappropriate for a discussion of your product/service, it can be flagged as SPAM and deleted by clicking the Delete Topic as SPAM button (just below the Moderator Topic Controls box on the topic page).
As with other areas of HelpSpot, flagging SPAM appropriately is necessary to facilitate the learning of the auto-SPAM filtering. Over time, with appropriate flagging, HelpSpot will learn the characteristics of the SPAM the site receives and auto-flag it as such.
Staff can check posts that were automatically marked as SPAM by going to the SPAM area on the left navigation. From here you can delete or Mark as Not SPAM for those labeled incorrectly.
HelpSpot has a security word (captcha) on the Add a Topic form on the portal that helps limit the number of SPAM forum posts.
If a topic isn't necessarily SPAM but is inappropriate and needs to be removed, Moderators can do so simply by clicking the Delete Topic button (just below the Moderator Topic Controls box on the topic page).
Once it's gone, it's gone! Deleting permanently removes items from HelpSpot.
Replies are posted within forum topics using the Post Reply form. This form can be accessed in a number of ways from the Forums area in HelpSpot:
The reply capabilities within HelpSpot are similar to those within the portal. Once a User posts a reply it is immediately available within the forum.
Beyond simply adding a message in posts, Users have the added ability to insert links to knowledge book pages and include prepared responses.
Users can elect to include links to public knowledge book pages in any posts. Adding these links can provide readers with further clarification regarding a process and procedure in a way that is quick and easy for Staff. Keep in mind that only published pages of public knowledge books are available for linking.
Using a prepared response in forums is a quick way to reply to posts that reflect a common inquiry.
Using the menu under the author icon, for an individual post within a topic (shown below) will bring Moderators to the post-level moderation options.
Within the Moderate Post area you can delete posts, mark as SPAM, or edit posts (as needed).
If a post seems to be automated or overt advertising, it can be flagged as SPAM.
As with other areas of HelpSpot, flagging SPAM appropriately is necessary to facilitate the learning of the auto-SPAM filtering. Over time, with appropriate flagging, HelpSpot will learn the characteristics of the SPAM your site receives and auto-flags it as such.
Staff can check posts that where automatically marked as SPAM by going to the SPAM area on the left navigation. From here you can delete or Mark as Not SPAM for those labeled incorrectly.
HelpSpot has a security word (captcha) on the Add a Post form on the portal, which will helps limit the number of SPAM forum posts.
If a post isn't necessarily SPAM but is inappropriate and needs to be removed, Staff can do so simply by clicking the Delete Post button on the moderating post page.
Once it's gone, it's gone! Deleting permanently removes items from HelpSpot.
HelpSpot provides the capability to flag posters (readers that create posts within a forum) with a text-based label. This can be done via the Known User menu item within the author icon menu. The label can help add creditability to the post(s) or put the appropriate context around a comment.
Users have the capability to turn posts that reflect an issue or inquiry into requests through the Turn into Request menu option. From there, Users will be brought to the request page where the request can be managed as they would any other.
Completely redesigned, HelpSpot's Reports area is a robust, graphical-rich way of monitoring your help desk.
The landing page for the Reports area is the Todayboard, which is 6 distinct reports to provide a high-level look at the activity of the help desk.
Broken down by each hour of the day, this report shows requests opened today (24 hour period) and also compares that to activity of that 1 week ago. Allowing Users to see request activity today, throughout the day, relative to the same day last week.
As the title would indicate, this report show how many public notes were submitted (per request) by Staff prior to closing.
The average and median for how long (in hours) until requests had a public note added by Staff. This is calculated within business hours (default is 8-5, local time).
Staff (3) with the most number of requests currently open.
Shows the top five categories to which requests are being assigned.
An hourly look at request types, broken out by type: public by Staff, private by Staff, and Customer.
HelpSpot includes 10 built-in reports that allow Users to monitor various aspects of activity on the help desk. Reports are broken out in to 3 groups: Requests Over Time, Analysis, Portal, and Time Tracker.
While reports differ in the data pulled, all reports have the following characteristics in common:
All reports allow for the following parameters to be set:
Perhaps the best overall look at the activity of the help desk, this report is broken out within the Reports navigation.
Requests over Time shows a count of requests (those opened) each day over the course of a 2 week period.
Shows the number of hours taken for Staff to update requests with the first public note.
Modifications available for this report:
Time it took to be assigned to Staff from first entering the system. This report is most applicable for those NOT using automation or mail rules for auto-assignment.
Modifications available for this report:
Number of public updates done by Staff. Commonly used to see how many Staff updates were necessary to close a request. When using for this purpose, be sure the Open/Closed filter is set to Closed (defaults to all).
Modifications available for this report:
Count of notes, broken out by type, based on note creation date.
Modifications available for this report:
Time taken (in hours) for a request to be closed.
Modifications available for this report:
List of search terms used by Customers, which yielded the fewest results. Note, this report does not have an accompanying graph.
List of search terms using in Customer portal. Those used most frequently are listed first.
Count of most used responses. List includes response title (link to response), response creator, and usage count. Users can use filtering to find the most used responses with a specific category or status type.
Modifications available for this report:
Count of those Customers with the most requests in the system (defaults to include both open & closed).
Modifications available for this report:
A list of all time events logged by Staff. The request ID listed in each event can be click to view the Request.
Modifications available for this report:
As discussed in previous pages, Users can further refine the results set (ie: modify the parameters) in a number of ways.
There are numerous filter conditions that can be applied only, or in conjunction with other conditions, to define the exact information needed. The filter conditions available in Reports are the same as those used within the Filter creation process.
Once you've created a report that is tailored to your needs, it can be saved for future use. Any saved reports can be found in the My Reports folder of the Reports area navigation. Reports can only be saved for the logged in User and will not be available for use by other Users.
Below represents a few of the report modification that can be made to find specific information; those areas most commonly monitored by help desk administrators/managers. As mentioned previously, any report can be saved in the My Reports folder for future use.
Base report. Request Over Time.
Description. Users can quickly see requests over time based on category, assignment or any custom field by using the Grouping drop down, as shown below.
Implication. Insight into any of these areas will allow managers to make adjustments such as: increased portal documentation on a particular topic (addressing high categories), use of auto-assigment to better balance workload, or coordination with other departments.
Base report. Request Over Time.
Description. Using the filtering conditions, Users can see requests submitted by a particular customer or customers meeting specific criteria within the Customer Information fields (ie: email domain or customer ID). Different from creating a Filter, this report will give you an aggregate snapshot over a defined period of time. Note: for this example, Customer email domain was used, in addition the results are being grouped by status and the time frame has been expanded.
Implication. Managers can use this to monitor service agreements or other contractual commitments.
Base report. Replies by Count.
Description. Find the aggregate of how many public notes occurred prior to an issue being closed. This type of report can be used as a gauge to determine how much work is required to resolve issues. Note: the filter condition of Open/Closed was set to Closed for this report.
Implication. Higher numbers within a particular category/reporting tag area or by select individuals could indicate a need for increased training or revision/creation of prepared responses.
The portal is the Customer-facing site for HelpSpot. It's designed to enable self-service and provide Customers with a centralize location for all support-related information/activities. From the portal Customers can:
While this manual uses one of the available default portal styles, it's important to note that HelpSpot's portal is fully customized; allowing consistency with the look of any company's website/intranet.
HelpSpot can support multiple (secondary) portals. This is used when separate customer facing support areas are needed. Configuration is done through the Administration area of the installation.
Given portal functionality is consistent across primary and secondary portals, the balance of this chapter will focus on the use of one, the primary, portal only.
When Customers enter the portal they'll see three distinct areas on the homepage
Public books are highlighted in four areas within the portal:
Once a knowledge book title has been clicked, readers are brought to the table of contents, which includes all live chapters/pages with editor-specified pages highlighted for the reader, if applicable.
Clicking on a page title will bring readers directly to the page content. Readers can vote on the helpfulness of a page. An aggregation of the most helpful pages from all public books is listed on the homepage.
Public forums are highlighted in three areas within the portal:
Clicking on a forum title from the homepage will bring readers to the list of topics within that forum.
From the forum's topic list, readers can click into any of the existing topics to read/reply or opt to create a new topic.
After the initial post by a reader, the name, email and website they provide is remembered to allow subsequent posts to go quickly.
Clicking the topic title will bring readers to the list of posts on the topic.
From here, readers can do the following:
When replying to a post, the only required fields are message and name. The exception is when a reader opts to subscribe to replies; in these instances an email address must be provided.
Using the link on the left navigation, Users can submit a request.
By default HelpSpot breaks out the description box into three areas: what I did, what I expected to happen, and what actually happened. Administrators can change the request description boxes to a single, open text box.
Some installations may create custom fields and/or categories that they wish to make public to enable request workflow or capture additional information directly from the Customer.
To help reduce SPAM, captcha can be turned on by administrators.
Customers can use the Check on a Request link, within the left navigation, to check on and update requests. Customers must provide the request access key, which is provided by default in the emails Customers receive, to see a specific request.
For the quickest and easiest access to all their requests, Customers should login into the portal using their email address (one provided when submitting requests) and password. Passwords can be retrieved via the retrieve my password link. Once logged in, Customers will see a list of all requests they have (opened and closed) as well as the option to change their password for future login.
Just below all public update entries and the initial request, Customers will find an open text field where additional updates.
Knowledge Tags allow Users to create a cross-resource base of knowledge. The advantage over traditional search is it's a much quicker, accurate way for readers to find specific content across knowledge book pages and forums.
Knowledge Tags can be applied to by Users to any knowledge book page or forum topic; during or subsequent to creation. Users should take care to include every/all relevant tags as this will maximize the pertinent results returned.
Tagging consistence across content is critical. As Users type to add a tag, HelpSpot will show existing matching tags. You can opt to select the tag, if applicable, or continue to type the full tag.
To the readers of the portal (typical your Customers), Knowledge Tags are listed in alpha order at the bottom of the homepage. Readers can click any tag to get a complete list of Knowledge Book pages and Forum topics associated with that tag. Notice the variation in size. The relative size of the tag name corresponds to the number of times it occurs within the content.
When Readers search within the portal, there's a section that will return the exact match Knowledge Tag (if such exists).
A list of tags is also include in HelpSpot (site Users log into) within the landing page of the Knowledge Books area. While the list is within the Knowledge Books area, it is not limited to that content but rather also includes Forums tags. The presentation will be as described in the portal (above).
Users can search within Knowledge Tags using the Advanced Search in HelpSpot. Tags can be search individual or combined for the desired results set.
Filters are a way to view create custom views of the requests. By default, HelpSpot ships with global 'All Open' and 'Recently Closed' filters. However, an infinitely combination of conditions can be combined to create a filter that meets your excact business need.
Here are 3 real world examples of Filters in use. Execution of these filters can vary, with additional conditions being layered on to meet the business need, but the following shown here is intended to give Users an idea of how each would be created.
Business Need: Support desk has a contractually agreement with Customer group (internal or external) to always respond to equipment issues within 24 hours of Customer updates.
Creation: Filter must be created to see those requests that haven't been updated within 24 hours, that has been assigned to Category: Equipment/Reporting Tag: Issues.
Business Need: Create an Inbox for only those Staff working Account inquiries. Allows those Users to focus on working only those requests within their area of expertise.
Creation: Filter must be created to see those requests assigned to the Account Inquires category.
Unique to this filter is:
Business Need: Monitor activity of selected Staff. Effective in providing timely feedback during training periods.
Creation: Filter must be created to see those requests opened Today, assigned to Staffer X, and are either currently Open or Closed.
Once an account is created, each User has the ability to set/edit preferences by click their name in the top right corner of the screen.
The preferences page covers everything from password changes to signature creation and allows Users to personalize their HelpSpot experience.
Make sure you hit Save at the bottom of the page to ensure all changes are applied.
The name, email, and password are displayed, at the top of the preference page, to the User as entered by the administrator during account creation. Users have the ability to update this information.
The email address listed here for Users is the default address HelpSpot uses for sending notifications.
This is only required for Users in installations that are running alternative authentication with an external source (such as Active Directory).
Users can select from the stock images provided or opt to upload their own photo. The selected photo is used as part of the request history when the User creates an update, serving as a quick means to identify individual Users.
Users should resize images to 32x32 (pixels) prior to uploading to achieve the best results.
The communication area defines alternative contact information, out of office manager, as well as signatures for outgoing messages.
HelpSpot provides Users with a means for providing an alternative email, phone number, and SMS number. Options in the notification area allow Users to configure when messages/updates are sent via these alternative channels.
If a User is going to be out of the office for an extended period of time, such as vacation or medical leave, all requests that would have been assigned to them can be assigned to an alternative User.
All Users are defaulted to being available. However, by using the drop-down Users can change their status and select whom their requests should go.
A visual indicator of out of office status appears in the assignment drop-down on the request page.
Similar to any mail client, Users can create a signature block that is appended to every outgoing message/update (public and external notes).
HelpSpot offers both a text and HTML signature format to account for varying system configurations. As such, it is recommended that Users complete both text and HTML to ensure the signature is included.
When creating the HTML version of the signature, Users must use formatted text mark-up.
There's a third tab within the signature creation area for creating a mobile-specific signature. This signature will be used only when a User creates a note using HelpSpot mobile. Often a varying signature is used to inform the reader the note was created on a mobile device.
The notification area allows Users to configure where and under what conditions they receive a notification. The list below outlines each of the notifications options.
These general preferences help Users personalize their experience by defining specific aspects of the look and feel to match their personal work style.
Regardless of the number set in the preference, Users can see all request history entries simply by clicking the Show All link at the bottom of the request history list on the request page.
The request merging feature forces the request history of one request into another. This is often used when multiple requests are created for the same Customer regarding the same inquiry.
Merging can be done from the:
Once the merge is complete, the User will be brought to the request page for the receiving request. The individual request histories of the merged request are inserted in chronological order within the receiving request. All merged histories are clearly identified, allowing you to retain an accurate account of all interactions.
Any responses to the original request are automatically routed to the newly created, merged, request.
HelpSpot gives Users that ability to batch response/update requests. Meaning, from in the request grid view (Workspace) Users can select a group of requests and initiate a response to be sent or an update to be made in the request details without entering the request page for each, individually.
Batch responding is understood through a real world example: Within a 20-minute period a support desk receives dozens of requests about connectivity issues that is determined to stem from a server outage. Using Batch Response/Edit, Users can send a message to all applicable requests explaining the situation while also updating the status, category/assignment, or reporting tags.
For later follow-up, such as sending sending status update notification, Users can opt to have a link to the results added as a filtered view on the left navigation.
For installations with this enabled, the time tracker will be across the top of the request page. It allows each User to log the time spent on a request. Time tracking is primarily used by organizations for billing/customer contract purposes.
Time can be entered manually or through the use of the stop-clock. When manually entering time, decimal or standard time format (for example: 2.5 or 2:30) is accepted in the hours/minutes box. When using the stop-clock, click the arrow when work starts on the request and click it again when work is complete. The time lapsed will be logged for the entry. A field is provided to provide a brief description of the work completed during that logged session.
HelpSpot includes a Billable checkbox, allowing Users to flag time which would be billable for later reporting.
Users can also use the options menu to log time for another User, if necessary, as shown below. If time is logged without selecting from the options area, the time will be attributed to the logged-in User.
Once Users click the Log Time button the time will be listed as part of the aggregate time spent on the request.
To report time logged across all requests, use the Reports area.
HelpSpot Mobile is available on both the Google PlayTM and the iOS App Store. The Helpspot mobile app provides a streamlined mobile user interface for interacting with the HelpSpot application. The Helpspot app will work on both self-hosted and HelpSpot Cloud instances.
Since the mobile app connects to your instance of helpspot you will need the URL of your helpspot site the first time you login to the mobile app.
If you encounter issues logging in. Visit our troubleshooting guide.
Android, Google Play and the Google Play logo are trademarks of Google Inc.
Apple and the Apple logo are trademarks of Apple Inc., registered in the U.S. and other countries. App Store is a service mark of Apple Inc.
Below are the support-related resources available for HelpSpot.