Requests

• Manage requests and inquiries already in the system
• Create internal and external requests
• Respond to incoming inquiries
• Obtain an overview of the statuses of all requests in the system

Terminology

A request is a form of communication where a (potential) customer, client, or business partner seeks information or assistance. For example, support issues, questions about the product and services, questions about invoices, or feedback regarding their experience with interaction with the company.

The terms request and ticket are often used interchangeably in SuperOffice. For example, you’ll see the Request screen in the SuperOffice user interface, the ticket database table, and the Ticket CRMScript class. In the context of CRM, not to be confused with API requests (such as GET, POST, PUT, DELETE) or authorization credentials (such as system user ticket).

Request handling

Requests can be linked to contacts, who in turn can belong to a company. This means that requests cannot be linked directly to companies (only indirectly via contacts).

Companies employ varying procedures for handling requests and may utilize SuperOffice in diverse manners. Here are two common scenarios:

Scenario 1: The customer submits the request by email

1. The customer emails support@company.com or fills out a form in a user-support portal.
2. The customer gets an automatic reply letting them know the inquiry is received.
3. The system automatically turns the inquiry into a request in SuperOffice.
4. The request goes to a request handler, who reads through it.
5. The request handler sends a response to the customer.
6. The request handler closes the request and proceeds to deal with other requests.

Scenario 2: The customer calls the request handler

1. The customer has a problem with a product and calls user-support.
2. The request handler who answers the call registers the request.
3. The request handler sends a response to the customer.
4. The request handler closes the request and proceeds to deal with other requests.

In both scenarios, if the request handler is unable to fulfill the request on their own, they can either:

• Ask a colleague.
• Or, get help from outside the organization, for example for a sub-contractor or supplier.

Status

A request has one of the following statuses:

• Active
• Closed
• Postponed
• Deleted
• Merged

The status will change as the request flows through the support system. You can create additional request statuses.

Request category

All requests belong to a category, and each category has its own rules that define how requests are processed in the system. The request categories are arranged in a tree structure. Users can be added as members in the categories individually or via the user groups they belong to. You can create additional request categories.

Tags are a more flexible alternative to request categories. You can create tags on the fly and tag any request with as many tags as you want.

Priority

The priority of a request reflects the importance of the enquiry, such as high, medium, or low. After a request is assigned a priority, the priority can be used to control any escalation of the request.

Priority is tied to:

• Deadline
• Read status
• Actions and escalation chain

You can add new priorities and edit the settings of existing priorities.

Escalation

The escalation chain has multiple levels. Each level has its own settings, such as:

• Priority
• Alert level (strictly ascending number)
• Time (in minutes) before the ticket is escalated to the next level
• Action (what should be done when escalating to this level)
• If and who the ticket should be delegated to on escalation
• The ID of a CRMScript to run when the ticket alert goes off

You can define additional escalation levels for each priority.

Response time and time spent

ticket.replied_at is set (if empty) based on the time of action (selecting Reply/Reply all).

All other calculations run in the background. We use time_counter to mark which field in the ticket to count time spent on (queue, internal, external).

Service reply templates

A reply template is a blueprint for an email. It consists of regular text and template variables.

Example email confirmation template:

Hi [[fullname]]

Thank you for registering on our Customer Centre.

Please click on the following link to complete registration.

[[confirmUrl]]

Best regards
[[config.companyName]]

Example new request assignment template:

You have been assigned request no. [[ticket.id]]. The URL of the request is:

[[ticket.url]]

Title............: [[ticket.title]]
Posted by........: [[ticket.author]]
Category.........: [[ticket.category.fullname]]
Security level...: [[ticket.slevel]]
Customer.........: [[ticket.custName]]
E-mail...........: [[ticket.custEmail]]
Company..........: [[ticket.custCompany]]

Template components

Reply templates have the following general components:

• Name
• ID
• Subject
• Body
• Attachments

You can look up specific fields in the database reference.

Translation

If customer languages are configured it is possible to create language versions of each reply template. More information about this can be found in embedded help under working with customer languages

Template variables

A template variable is a named placeholder that you can put in a document- or email template. When the template is applied, the variable is substituted with the actual value. For example, {customer.firstname} translates to the customer’s first name. This lets you automate the personalization of content.

Complete list of all standard fields (does not cover your user-defined fields)

Each incoming email box can be configured to send an automatic answer back to the customer using a reply template. In addition, you have a parser variable called ticket.lastMessage which will contain the last message on the request, normally the text the customer wrote.

You can also extract anything from the email using Find regular expressions, and those matches will be available as parser variables (see the help for syntax).

Syntax

The syntax for a parser variable is the name of the variable enclosed by the tags <cs:parser> </cs:parser>.

To get a complete overview of template variables available for your database, create a new reply template with the plain text body %PARSER_TREE% (case sensitive).

When this reply template is used in a request, you will get a list of all available template variables by using the parser tree variable. %PARSER_TREE% is especially useful when you want to debug why something is not working.

System templates

Not all parser variables are available in every context in SuperOffice Service. The following tables show which parser variables are available in which reply templates.

Standard variable

The standard variables are Message, Company, Customer, Ticket, and Config.

Other parser variables

Some parser variables that exist will not be described. These are present only for backward compatibility.