Difference between revisions of "Best Practices for Using ServiceDesk"
From AgileApps Support Wiki
imported>Aeric |
imported>Aeric |
||
(18 intermediate revisions by the same user not shown) | |||
Line 1: | Line 1: | ||
Use the tips on this page to use your {{ | Use the tips on this page to use your {{HD}} solution in the most advantageous ways. | ||
__NUMBEREDHEADINGS__ __TOC__ | __NUMBEREDHEADINGS__ __TOC__ | ||
===Setting Up a B2B System=== | ===Setting Up a B2B System=== | ||
: For a business-to-business system, you'll typically: | : For a business-to-business system, you'll typically: | ||
::* Have an | ::* Have an Account record for each organization you serve, and Contact records for the individuals in those organizations. | ||
::* Set up | ::* Set up an Email channel so that Customers can use email to create a new case, but only if their email address matches an existing Contact record | ||
::* Set up your [[Support Portal]] so that only registered users can access it, so your knowledge base and community support channels are available only to your customers. | ::* Set up your [[Support Portal]] so that only registered users can access it, so your knowledge base and community support channels are available only to your customers. | ||
===Setting Up a B2C System=== | ===Setting Up a B2C System=== | ||
: For a business that sells product to consumers--especially one that sells through indirect retail channels, rather than through direct contact, you'll typically: | : For a business that sells product to consumers--especially one that sells through indirect retail channels, rather than through direct contact, you'll typically: | ||
::* Maintain | ::* Maintain Contact records for people that file cases or use your Support Portal. (Except in rare cases, you won't have [[Account]] records.) | ||
::* Disable new case creation in | ::* Disable new case creation in the Email channel, to minimize the effect of spam. | ||
::* Allow anonymous users to access your [[Support Portal]], along with your knowledge base and community support channels. | ::* Allow anonymous users to access your [[Support Portal]], along with your knowledge base and community support channels. | ||
::* Depending on the size and activity of the anonymous-user base, you may or may not allow anonymous users to create new cases in the Support Portal. | ::* Depending on the size and activity of the anonymous-user base, you may or may not allow anonymous users to create new cases in the Support Portal. | ||
===Use Case Status to Manage Workflow=== | ===Use Case Status to Manage Workflow=== | ||
: You're free to use Case Status settings in any way you like. You can even | : You're free to use Case Status settings in any way you like. You can even __KB: modify the List of Case Status Values__. But the strategy outlined here is recommended, especially if this is your first encounter with a {{HD}} management system. | ||
::[[File:StatusTransitions.png]] | ::[[File:StatusTransitions.png]] | ||
Line 25: | Line 25: | ||
:#: | :#: | ||
:# When the customer is asked for more information (in an email, for example), the Case Agent changes the status to '''Pending'''. | :# When the customer is asked for more information (in an email, for example), the Case Agent changes the status to '''Pending'''. | ||
:#: This step is especially important when | :#: This step is especially important when __KB: Service Level Agreements__ are in place, because there can be monetary penalties if a problem is not resolved in time. So it is important to halt the clock when additional information is needed from the customer--in effect, calling a "time out". | ||
:#:: '''Note:'''<br>A Case should ''not'' be placed into Pending status when waiting on information from a co-worker, or from some 3rd-party supplier because, from the customer perspective, the clock is still running. | :#:: '''Note:'''<br>A Case should ''not'' be placed into Pending status when waiting on information from a co-worker, or from some 3rd-party supplier because, from the customer perspective, the clock is still running. | ||
:#: | :#: | ||
:# At times, the customer will indicate that the problem has been fixed. At that point, the case | :# At times, the customer will indicate that the problem has been fixed. At that point, the case can be immediately '''Closed'''. | ||
:#: When a case is closed, no survey is sent out. That's reasonable action to take here, because the customer has already responded. | |||
:#: As an alternative, however, the case could be marked '''Resolved'', which causes a satisfaction survey to be sent to the customer. | |||
:#: | :#: | ||
:# When the customer supplies the required information, the Case Agent changes the status back to '''Open'''. | :# When the customer supplies the required information, the Case Agent changes the status back to '''Open'''. | ||
:#: | :#: | ||
:# When the customer's issue appears seems to be handled, the Case Agent changes the status to '''Resolved'''. | :# When the customer's issue appears seems to be handled, the Case Agent changes the status to '''Resolved'''. | ||
:#: This status is in effect a '' | :#: This status is in effect a ''tentative'' closure, asking for confirmation from the customer. | ||
:#: To get that confirmation, | :#: To get that confirmation, system rules cause a Satisfaction Survey to be sent whenever a Case is resolved. | ||
:#: | :#: | ||
:# If it turns out that customer is not satisfied, the status automatically changes to '''Reopened'''. | :# If it turns out that customer is not satisfied, the status automatically changes to '''Reopened'''. | ||
:#: | :#: | ||
:# | :# The status changes to '''Closed''' when: | ||
:#: | :#: a. The customer indicates that they are satisfied, at which point the Case Agent makes the change. | ||
:#: b. A [[Timer Rule]] automatically closes the case after several days have passed without a response from the customer. | |||
<noinclude> | |||
[[Category:{{HD}} application]] | |||
</noinclude> |
Latest revision as of 19:31, 13 May 2013
Use the tips on this page to use your ServiceDesk solution in the most advantageous ways.
1 Setting Up a B2B System
- For a business-to-business system, you'll typically:
- Have an Account record for each organization you serve, and Contact records for the individuals in those organizations.
- Set up an Email channel so that Customers can use email to create a new case, but only if their email address matches an existing Contact record
- Set up your Support Portal so that only registered users can access it, so your knowledge base and community support channels are available only to your customers.
2 Setting Up a B2C System
- For a business that sells product to consumers--especially one that sells through indirect retail channels, rather than through direct contact, you'll typically:
- Maintain Contact records for people that file cases or use your Support Portal. (Except in rare cases, you won't have Account records.)
- Disable new case creation in the Email channel, to minimize the effect of spam.
- Allow anonymous users to access your Support Portal, along with your knowledge base and community support channels.
- Depending on the size and activity of the anonymous-user base, you may or may not allow anonymous users to create new cases in the Support Portal.
3 Use Case Status to Manage Workflow
- You're free to use Case Status settings in any way you like. You can even __KB: modify the List of Case Status Values__. But the strategy outlined here is recommended, especially if this is your first encounter with a ServiceDesk management system.
- Here is the way the status transitions are expected to work:
- When customer files a case, it's status is automatically set to New.
- When a Case Agent claims a case, or a Case Manager assigns it, or an automated Rule causes it to be assigned, the status of the case is automatically changed to Open.
- When the customer is asked for more information (in an email, for example), the Case Agent changes the status to Pending.
- This step is especially important when __KB: Service Level Agreements__ are in place, because there can be monetary penalties if a problem is not resolved in time. So it is important to halt the clock when additional information is needed from the customer--in effect, calling a "time out".
- Note:
A Case should not be placed into Pending status when waiting on information from a co-worker, or from some 3rd-party supplier because, from the customer perspective, the clock is still running.
- Note:
- This step is especially important when __KB: Service Level Agreements__ are in place, because there can be monetary penalties if a problem is not resolved in time. So it is important to halt the clock when additional information is needed from the customer--in effect, calling a "time out".
- At times, the customer will indicate that the problem has been fixed. At that point, the case can be immediately Closed.
- When a case is closed, no survey is sent out. That's reasonable action to take here, because the customer has already responded.
- As an alternative, however, the case could be marked 'Resolved, which causes a satisfaction survey to be sent to the customer.
- When the customer supplies the required information, the Case Agent changes the status back to Open.
- When the customer's issue appears seems to be handled, the Case Agent changes the status to Resolved.
- This status is in effect a tentative closure, asking for confirmation from the customer.
- To get that confirmation, system rules cause a Satisfaction Survey to be sent whenever a Case is resolved.
- If it turns out that customer is not satisfied, the status automatically changes to Reopened.
- The status changes to Closed when:
- a. The customer indicates that they are satisfied, at which point the Case Agent makes the change.
- b. A Timer Rule automatically closes the case after several days have passed without a response from the customer.
- When customer files a case, it's status is automatically set to New.