BillMax Ticketing Installation and Usage Guide

Transcription

1 BillMax Billing Solutions The ispark Group, Inc. PO Box 1947 Colleyville, TX, USA Fax BillMax Documentation Copyright The ispark Group, Inc. Documentation for BillMax 2014 All rights reserved. No part of this documentation may be reproduced or transmitted in any fashion without written permission by The ispark Group, Inc. This documentation is for use of evaluating the BillMax billing software created by The ispark Group, Inc or for the use of licensees of the BillMax billing software created by The ispark Group, Inc. Any other use of this documentation without written permission of The ispark Group, Inc. is a violation of the use of this documentation. While precautions have been taken in the preparation of this documentation, The ispark Group, Inc. assumes neither liability nor responsibility for errors or omissions, or for damages resulting from the use of the information contained herein. All terms mentioned that are known to be trademarks have been appropriately capitalized. Use of the a trademark does not affect the validity of any trademark or service mark. Links to third-party Web sites are provided for convenience. The ispark Group, Inc. is not responsible for any content contained in the third-party Web sites. Comments about this documentation may be sent to <doc@billmax.com>. Table of Contents General Overview... 3 Installation Gateway Requirements

2 Step by Step Configuration Instructions... 4 Usage Commands

3 General Overview BillMax Ticketing Starting with the BillMax 2012 Q4 release, BillMax includes a new module (hereafter referred to as 'Ticketing' for trouble or issue tracking. This module is intended as a replacement for Calltrack. While similar to Calltrack, Ticketing includes many improvements and will continue to see development based on user feedback. Calltrack will remain in BillMax for now but will eventually be removed. When that is done, conversion tools will be provided to migrate the data between modules. Ticketing is comprised of these components: Queues Teams Tickets Messages Queues provide a means to segregate issues based on the nature of the issue and help to ensure that the issue is directed to appropriate individuals in your organization. You may define as many Queues as needed. Examples of Queues include: technical support, billing, and sales. Teams are composed of Customer Service Representatives (CSRs) or technicians. Each Queue has an associated Team. You may define as many Teams as needed and CSRs may be members of multiple Teams. Each Queue contains rules which may limit activity to the associated Team. Tickets represent specific issues or problems. Tickets are typically associated with a particular Customer (user) in BillMax, though this is not a requirement. A Ticket holds time and date, author, subject, queue, and state (Open, Closed, etc.) information. Tickets are also comprised of Messages. A Message in BillMax almost always represents some correspondence between a CSR and a customer. The message may be internal in origin or it may have been derived via BillMax's Ticketing Gateway. Messages also may include attachments. Ticketing interfaces, at present, include the BillMax staff interface and . A interface for the Customer Portal is planned for the next release. Installation Ticketing is included in the standard BillMax instance. However, after installing BillMax (described in the document titled Installing BillMax 2014.) there are some additional steps required if you wish to use Ticketing. In addition, if you choose to use the Gateway, additional requirements apply (see next section). Gateway Requirements 1. An external box (address) is needed for each Queue that uses the Gateway. The preferred protocol is IMAP. 2. Sendmail based outbound capability from your BillMax server. Note that this requirement is no different than that required to send statements in . Also note that this requirement usually requires specific DNS setup (SPF records) or the use of a smart host relay. 3

4 3. Each CSR must have a unique address (defined in Administer->Security->Authorized Users) and the address must not be present as a address in the BillMax user table (user. ). Step by Step Configuration Instructions 1. As the 'root' user, execute the setup_ticketing script. This script installs several files needed for the Gateway and also configures MySQL to handle large binary large objects. Even if you do not choose to use the Gateway, you should run this script to ensure that large messages can be stored in BillMax. cd /usr/local/billmax/bin./setup_ticketing This script requires no prompts and if successful should produce no output messages. 2. In the Billmax staff interface, define one or more Teams as needed. You will need a Team for each Queue, however, Teams may be associated with more than one Queue. To create Teams, go to Correspondence->Teams. First create the Team via the 'NEW' button. Then add CSRs (users) to the Team. At present a CSR may be defined as a normal member or as a Supervisor. Supervisors have special additional rights (see Queue setup for details). 3. In the BillMax staff interface, define one or more Queues. To create Queues, go to Correspondence- >Queues. Use the 'NEW' button and complete the form to create a Queue. The following describes each of the form fields. Name: The name of the Queue shown to CSRs and Customers (in the Customer Portal when that interface is available) Description: Description of Queue's purpose or use, shown to CSRs and Customers (in the Customer Portal when that interface is available) Team: The Team responsible for this Queue's Tickets. Assign Mode: Determines how Tickets are assigned to CSRs. Supervisor: Only a supervisor can assign Tickets. Self: CSR can assign Ticket to himself Queue: All Tickets are assigned to the CSR defined in the Queue. See the next form setting below. Team: Tickets are assigned automatically from Team members on a "round robin" basis. Post Mode: Determines who can author a Message for a ticket. Team Only: Team members are allowed to post a Message to a ticket. Assigned Only: Only the person to whom the ticket is assigned may author a message for a ticket. All: Any BillMax CSR may author a message for a ticket. Assigned To: The CSR responsible for this Queue's Tickets. Applicable only if Assign Mode is 'Queue' 4

5 Acknowledge New: Used only if Gateway is enabled. If YES, a will be sent to the customer stating that his post has been received. Acknowledge Close: Used only if Gateway is enabled. If YES, a will be sent to the customer stating that the ticket was closed. Virtual Company: BillMax Virtual Company associated with Queue. Presently only used for Customer searches (what user authored Ticket) Anonymous User: BillMax user (number) used for Ticket/user association. If 0, unknown posts remain not associated. If -1, unknown posts are rejected. If positive, message will be associated with that BillMax user. Forward Tickets to CSR/Team. Used only if Gateway is enabled. If YES, messages from customers are forwarded (as ) to the appropriate Team members. BCC CSR response to Team: Used only if Gateway is enabled. If YES, Team members are BCC-ed on message replies from CSR. Bounce To: If set, in the event of a bounced (see Anonymous User setting), send reject to this address. If not set and anonymous posts are not allowed then send reject to author. Use Gateway: If YES, message_hook is enabled and the remaining options in this form determine the Gateway settings for this Queue. Gateway Address: This is the public address associated with this Queue. Example: <support@example.com> Gateway Server: The name for the mail server where mail for 'Gateway Address' terminates. Example: mail.example.com Gateway User Name: The account name associated with the 'Gateway Address' Typically this is the same as user portion of the address. Example: support Gateway User Password: The password used to gain access to the for the 'Gateway User' Gateway Server protocol: The type of server. Gateway Server Options: Optional SERVER settings for Fetchmail. See for details. Gateway User Options: Optional USER settings for Fetchmail. See for details. Example: SSL 4. Assuming the Gateway will be used, the next step is to configure the fetchmail daemon so that it will be started on system reboots and start it. As the 'root' user, execute the following: /sbin/chkconfig.add bx_fetchmail /sbin/service bx_fetchmail start 5. At this point, you may test the Gateway by sending an to a configured address. Click on the Tickets link in the header. After several minutes, you should see a new Ticket from your test . If you do not receive the , there are a number of areas where things may have failed. First check in /usr/local/billmax/logs/fetchmail.log. You should see receipt of the message here, or 5

6 Usage BillMax Ticketing if there is an error in setup, you may see error messages. Assuming receipt of message, next check the /usr/local/billmax/tmp directory. You should see a directory with the form msgload.yyyy- MM-DD_HR:MN:SE_NNNNN. In this directory you should find the , attachments (if any), a info file and a log file. Examine the log file for errors messages. Lastly as 'root' you may wish to review the /var/log/maillog file. Contact <support@billmax.com> if you are unable to resolve the error or determine why the gateway is not working. Please be prepared to supply the contents of the fetchmail.log and the contents of the./tmp/msgload... directory when doing so. This section deals with the use of the Gateway. The Gateway provides a powerful, but at times, somewhat perplexing, way in which to communicate with your customers. The Gateway does not rely on any content within the message itself to identify a Queue or Ticket. Instead it uses the 'To' or 'Cc' header fields to identify the Queue. For follow up or CSR reply messages, the 'Message-Id' header field is used to associate a new message with an existing Ticket and to place the message in the appropriate place within a thread. All correspondence is meant to be accomplished through the Ticketing system. This is only possible if the appropriate 'To' 'Cc' and 'Reply-To' addresses are used. The following describes the basic flow. 1. Customers post message to Queue by sending a message via . He optionally Cc others. 2. Message is received and held at mail server. 3. The fetchmail daemon downloads the message. 4. BillMax loads the message into the database as a new Ticket and Message. 5. If forwarding is enabled the Message is forwarded to the appropriate Team. 6. CSR(s) reply to message. 'Reply-To' is utilized, ensuring the is sent back through BillMax. 7. Reply message is received and held at mail server. 8. BillMax loads the reply message into the database as a new Message. 9. BillMax sends the reply to the customer (and any others Cc on the original ). 10.This process is repeated... Most replies from a CSR will go to the Customer assuming a Customer post can be found within the appropriate thread. If the thread contains only posts among CSRs then the reply will sent to the appropriate CSR only. Given the above, here are some CSRs rules: Do not use 'Reply All' Only 'Reply' when responding to a customer post. Using 'Reply All' will result in the customer receiving multiple copies of your reply. Be careful using CC in any reply. Don't CC team members unless the Queue is not configured to BCC team members. Also be aware that some CSRs may not be able to post a message to the thread (because they are not member of the appropriate Team or because only the assigned member can post). 6

7 Commands The Gateway supports some short cut actions that are initiated by commands embedded within a message. Presently the following actions are supported. Forward (forwards to the CSR directly to queue),./f To use this the CSR uses his client's forwarding feature to forward the to the appropriate Queue. He includes the command in the text of his added message. The message will be received and processed in BillMax as though it was sent directly to the Queue. The message must be forwarded as an attachment. In-line message forwarding is not possible. New Ticket (creates Ticket on behalf of customer),./r/<customer address>,./c/<other address>,<other address>... Use of the 'c' command above is optional. It specifies a list of Cc-ed addresses. If used, this list supersedes any CC in the header. New Thread (creates new thread in existing Ticket),./t/<ticket #> Delete Ticket (deletes Ticket associated with message),./d Assign Ticket (assigns Ticket to CSR that is replying),./a 7