7. Customer Service Configuration

Created by Migration Bot, Modified on Fri, 23 Oct at 2:31 PM by Migration Bot

Originally written by John Hardwick, last updated Nov 03, 2025, on the Swan Retail knowledge base (FRS).

Part of: Implementation Guide

This document details how to configure the customer service features within SwanFRS

Considerations

There are two forms of customer service – notational and controlled.

Notational service uses the notes system to record Dairy, Actions and Worksheets – effectively customer service is handled outside SwanFRS with the notes feature being used to record actions for future reference. This is a great way of introducing service to a new team and can lead to a controlled service system.
A controlled service system uses SwanFRS’s privileges to control which events are used and who can use them.

The following points are suggestions to consider when building customer service.

Location	Customer services can be raised at any location – they do not need to be at the originating sales order branch – this means that it is possible to have a separate (department if you wish) handling support. Creating a location allows service address which can be used on printed literature / purchase orders etc. It is possible to have a different Cost Centre for service actions. Separate alerts can be created specifically for the service location. The service location can be linked to the default warehouse / distribution links to ensure stock is visible to the service department.
Events	There are several actions pre-built into SwanFRS however more will be required. Most operator specific events created will fall into one of the following Event Groups. Diary – This is a note added to the system which is effectively completed as it is created, and therefore there are no follow-ups other than reading the message. – sending the diary as a note will require the recipient to close / cancel the note – effectively this is a read receipt Action Required – Are Diary notes which stay open until processed / closed Worksheets – Are Action Required Events with the option to collect additional data which can be used to populate worksheets or process documents. In many instances, an Event is a mini workflow requiring the operator to complete the action (or series of actions) before the event can be closed. When creating / amending an event, consider how long it is expected for the action to be completed – this should for the Review days.
Chained events	Chained events, sometimes referred to as workflows, are simply a series of events which when added to a service remind the owner to do something. The event must exist before the chained event can be created.
Products	There are 5 events requiring an SKU to be able to make the event active. It is suggested that a service product group be created for these SKUs. When one of these events is added to a service, a new line is added to the sales order to ensure the finances on the order remain in balance. Creating a product group allows analysis and keeps these items ring-fenced. It is suggested that SKUs linked to the service event are marked as discontinued to stop use outside of service.
Access	Almost every customer service action has its own user privilege. If a specific event isn’t required, ensuring the operator doesn’t have that role removes the button from the service menu – for example, if loan stock isn’t required, omit all SERVICE_LOAN privileges. If in doubt, start with one or two service events and add / turn on as required.

Configuration

The following settings, privilege and routines are used to configure the SwanFRS customer service system.

Application Controls

Menu Location: System Admin > Set Up Application Parameters

See Set Up Application Parameters

The following parameters affect the way SwanFRS handles service actions.

Parameter	Comments
HEAD_OFFICE	Specify the location ID of the location deemed to be the ‘head office’. This location will be used to record internal service calls. It is STRONGLY recommended that this location cannot sell. Where left blank internal service calls cannot be generated.
INTERNAL_CUSTOMER	Specify the customer ID to be used when generating internal service calls. If location specific customers are in operation the head office location must have visibility of this customer. Where left blank internal service calls cannot be generated.
SERVICE_ANALYSIS_STRUCTURE	Tick to maintain analysis code using a hierarchical structure, un-ticked each of the 3 codes work independently.
SERVICE_ATTACHMENT_PAGE_SIZE	Specify the number of attachments to show on a single page. Recommend 5. Set to 0 to turn this feature off – I.e., show all attachments for the event on a single page.
SERVICE_FIND_DEFAULT	The service routine will begin with a table of service statistics or the search options.
SERVICE_FORCE_ANALYSIS_CODES	Tick to force the operator to ensure analysis codes are set before the service can be closed.
SERVICE_HIST_DEFAULT	Specify the default display when viewing customer service data. Choose from Active selected, dates not ticked All selected with dates ticked Active selected with dates not ticked All selected with dates ticked
SERVICE_NOTES_CLEAR_ONFOCUS	Tick to clear the default service notes on entering the notes box when creating a new event.
SERVICE_NOTES_LIST_LENGTH	Specify the number of characters to display when displaying service notes in a list. Choose from Not set (unlimited) 50 80 100 150 ·200 Larger numbers may result in the screen display showing horizontal scroll bars when displaying notes. If this occurs reduce the number of characters to display. Hovering over the note presents the full note in a message window.
SERVICE_REPLACE_OWNER	If ticked SwanFRS will automatically replace the overall service owner with the owner of the next due action. If unticked the owner of the overall service will only change when manually amended.
SERVICE_REVIEW_WARNING_DAYS	Specify the number of days (0 to 10) before an event review date the system will show the yellow warning icon.
SERVICE_REVISE_ATTACHMENT	Tick to allow attachments assigned to a note to be amended / revised

User Privileges

Menu Location: System admin > Security > Set up Roles

See Set Up Roles

Please refer to the Set Up Roles document when reviewing controls to ensure all suitable roles are allocated to the service operative and not just those specifically linked to service related actions.

Privilege	Control
ADMIN_CUSTOMER_SERVICE	Can perform administration activities within service.
CAN_EDIT_NOTES	The operator can edit notes.
CAN_EDIT_CLOSED_NOTES	The operator can make changes to note linked to closed events.
SEARCH_ALL_SERVICE_REQUESTS	Can search all service requests.
SERVICE_ACTION_REQUIRED	Can create action events.
SERVICE_AUTHORISE_ALLOWANCES	Can authorise allowances.
SERVICE_AUTHORISE_ALTERNATIVES	Can authorise alternative items.
SERVICE_AUTHORISE_LOANS	Can authorise loan goods.
SERVICE_AUTHORISE_PARTS	Can authorise parts.
SERVICE_AUTHORISE_REPLACEMENTS	Can authorise replacements.
SERVICE_CANCEL_CHAINED_EVENT	Can cancel a chained event.
SERVICE_CHANGE_CALL_OWNER	Can change the service call owner.
SERVICE_CHANGE_CALL_TYPE	Can change the service call type.
SERVICE_CHANGE_LINKED_TO	Can change the ‘linked to’ service call.
SERVICE_CLOSE_SERVICE	Can close service calls.
SERVICE_COSTS	Can add service costs.
SERVICE_CREATE_INTERNAL_SERVIC	Can create internal service calls.
SERVICE_DIARY_EDIT	Can edit the diary event. The ability to edit the narrative entered by another operative on the service. (Anyone can add a diary event to the service and edit their own messages, only operators possessing this privilege can edit a message created by another)
SERVICE_EDIT_ESCALATIONS	Can edit the escalations
SERVICE_EDIT_CLOSED_NOTES	Can edit notes for closed service events.
SERVICE_EVENT_EDIT_NOTES	Can edit event notes.
SERVICE_EVENT_EDIT_OWNER	Can edit event owners.
SERVICE_EVENT_EDIT_REVIEW_DATE	Can edit the review date.
SERVICE_EVENTS_CANCEL_ALL	Can cancel all events on a service call.
SERVICE_EVENTS_CLOSE_ALL	Can close all events on a service call.
SERVICE_ITEM_ADD	Can add an item to the service.
SERVICE_ITEM_ADD_ALTERNATIVE	Can add alternative items to the service.
SERVICE_ITEM_ADD_LOAN	Can add a loan item to the service.
SERVICE_ITEM_ADD_PARTS	Can add parts to the service.
SERVICE_ITEM_ADD_REPLACEMENT	Can add replacement items.
SERVICE_ITEM_DELIVERY	Can arrange item delivery via service.
SERVICE_ITEM_RETURN	Can arrange item returns (retailer collections) via service.
SERVICE_ITEM_RETURN_CREDIT	Can process a return for credit.
SERVICE_ITEM_RETURN_REPAIR	Can process a return for repair.
SERVICE_MANAGER	Is a service manager.
SERVICE_ORDER_ADJUST_ALLOWANCE	Can adjust a service allowance.
SERVICE_ORDER_ADJUST_CHARGE	Can adjust a service charge.
SERVICE_ORDER_ADJUSTMENT	Can create a service adjustment.
SERVICE_REOPEN_SERVICE	Can reopen closed services.
SERVICE_SUPPLIER_INV_DEBIT	Can process a supplier debit.
SERVICE_SUPPLIER_INV_INVOICE	Can process a supplier invoice.
SERVICE_SUPPLIER_INVOICE	Can create a supplier invoice.
SERVICE_TECHNICIAN	Is a service technician.
SERVICE_WORKSHEET	Can generate a worksheet.
VIEW_SERVICE	Can view the service call and its event history.

Users

Menu Location: System Admin > Security > Set Up Users

See Set Up Roles

Ticking hte service operator allows the operator to be visible in ‘action’ pick lists when processing service related activities.

All actvie operators will show in Diary, Action and Workflow events.

Locations

Menu Location: System Admin > Sales > Set Up Locations

See Set Up Locations

To switch escalations on for the specified location the operator must choose an escalation owner from the list of available users. This list will only contain operators possessing the SERVICE_MANAGER user privilege.

Field	Comments
Service escalation level 1 owner	Specify the person where overdue service events are to be escalated. The user list will show all users with the Service Operator has been ticked To turn off level 1 escalation set this field to ‘not selected’ If ‘service owner’ is selected the system will send the escalation notice to the current owner of the service call for pending overdue events.
Service escalation level 2 owner	Specify the person where overdue service events are to be escalated if not resolved once escalated to the level 1 owner. The user list will show all users with the Service Operator has been ticked. To turn off level 2 escalation set this field to ‘not selected’ If ‘service owner’ is selected the system will send the escalation notice to the current owner of the service call for pending overdue events.
Default service owner	Specify the person to be used as the default service call owner. The user list will show all users with the Service Operator has been ticked. Where set to ‘not selected’ the system will set the operator as the call owner unless the operator isn’t a service operator in which case the system will require the operator to specify a service operator. If ‘service owner’ is selected the system will send the escalation notice to the current owner of the service call for pending overdue events.
Internal service customer	Specify a customer account to be used if service calls are to be created for in-sold stock items. I.e., internal service calls. Customers with sales orders, payments etc. cannot be set as the internal customer. This field cannot be changed once one or more internal service calls has been linked to this account. The customer merge feature will not allow the internal customer to be merged with another. A different internal service customer is required for each location. This feature is not currently operatioanal.

Service Events

Menu Location: System Admin > Customer Service > Set Up Service Events

See Set Up Service Events

This routine holds a list of events used by SwanFRS to progress the service call.

Several pre-defined service events are provided as standard however additional event may be added as required.

It is recommended that you review the standard events and create a list of actions regularly taken by the service team. Once distilled to required actions create them using hte subject filter to define the action type. Consider the length of time each action is ‘expected’ to take as this provides a means of tracking events to ensure they are progressed in acceptable timescales.

If you do not wish to control a ‘standard event' within SwanFRS, it is possible to turn off the event, for exmaple if you are not logging service invoices, by turning the ‘standard’ invoice event off, you effectively turn off this feature.

Events can be linked to templates, effectively standard documents with merge tags which are generated as the event is processed.

Certain events financially affect the sales order’s balance and therefore need to be linked to SKUs. These SKUs are ideally set as ‘service’ classed units and once linked to an event turned off to stop the sales teams for selling them.

The standard events shipped with the base database are listed below.

Events List

Group name (Event)	Type	General purpose
Action required	Action required	General message requiring a follow up action.
Close service	Close service	Used to complete the entire service call
Costs	Costs	Operators with this feature can create a cost record event. Requires a SKU before it can be made active.
Diary message	Diary message	The ability to edit the narrative entered by another operative on the service. (Anyone can add a diary event to the service and edit their own messages, only operators possessing this privilege can edit a message created by another)
Email	Email	This event records the issuing of an email.
Escalation	Escalation	Escalation event.
Item addition	Alternative	Operators can begin the process of selecting an alternative item.
	Loan	Operators can begin the process of selecting a loan item
	Parts	Operators can begin the process of adding a part to the service.
	Replacement	Operators can begin the process of selecting a like-for-like replacement item.
Item delivery	Item delivery	Operators with this control can schedule items linked to the service to be delivered to the customer.
Item Return	Credit	Operators can begin the process of collecting goods back for credit.
Item Return	Repair	Operators can begin the process of collecting goods back for repair.
Order adjustment	Allowance	Operators can begin the process of creating an order allowance. Requires a SKU before it can be made active.
Order adjustment	Charge	Operators can begin the process of creating an order charge. Requires a SKU before it can be made active.
Reopen service	Reopen service	Only operators with this privilege can reopen a closed service call.
Supplier invoice	Debit	Operators can begin the process of raising a debit note. Requires a SKU before it can be made active.
Supplier invoice	Invoice	Operators can begin the process of raising a supplier invoice. Requires a SKU before it can be made active.
Worksheet	Worksheet	Used to generate a document used to progress the service call – for example an inspection visit.

The system uses the following events. These cannot be replicated or deleted by the operator. It is possible however to change the review and escalation dates.

Event & Type	Subject
Costs	Service cost record Requires a SKU before it can be made active.
Email	Email received
Escalation	Overdue action – Escalation status 1
Escalation	Overdue action – Escalation status 2
Message	Diary message
New service	New service call
System event	Delivery confirmed
System event	Delivery rejected
System event	Delivery schedule – amended
System event	Delivery schedule – removed
System event	Delivery schedule – rescheduled
System event	Delivery scheduled
System event	System message

Analysis Codes

Menu Location: System Admin > Customer Service > Set Up Analysis Codes

See Set Up Analysis Codes

Analysis codes are used when generating / updating service requests providing the ability to analyse the types of problem being recorded.

The operation of the routine will be controlled via the SERVICE_ANALYSIS_STRUCTURE application parameter.

The codes are split into primary / secondary and tertiary codes. Any code can be used in any level or restricted to a single layer. Codes may be used to identify the type of problem or resolution. It is suggested that consideration be given to the codes used prior to defining on the system.

When set to force analysis codes, it is not possible to complete service calls without analysis codes.

It is possible to filter the list of analysis codes using the filters in the header bar. Using a filter reduces the number of codes presented in the data grid.

Flat Operation

When operating with flat the maintenance the screen will be as shown below –

The routine will allow the operator to create and edit analysis codes and to set which of the three tiers the description relates to.

Setting the description within a primary, secondary and or tertiary is via a tick box. It is possible to have the same description for more than one level using this setting.

Hierarchical Operation

This feature is currently not available.

When operating with hierarchical structure the screen will be like that shown below -

When creating or editing codes the system will offer the following fields.

Field	Description
Description	Free format text describing the service analysis code. This may be a description, or a code followed by a description if desired.
Primary code	The system will offer a drop down of all analysis codes already set as primary. The operator may elect to leave this field blank indicating the code is to become a primary grouped analysis code or make a choice from the list, thus indicating the code is to become a secondary or tertiary grouped code. If the primary group is blank the update will be rejected if a secondary group is defined. Blank primary groups indicate the description is to become a primary analysis code.
Secondary code	The system will offer a drop down of all analysis codes already set as secondary groups. The operator may elect to leave this field blank indicating the code is to become a secondary grouped analysis code or make a choice from the list, indicating the code is to become a tertiary code. If the primary group is blank the update will be rejected if a secondary group is defined. Blank secondary groups indicate the description is to become a secondary analysis code. Choosing a secondary group indicates the description is to become a tertiary analysis code.
Tertiary code	The system will offer a drop down of all analysis codes already set as Tertiary groups. The operator may elect to leave this field blank indicating the code is to become a tertiary grouped analysis code or make a choice from the list. If the primary or secondary group is blank the update will be rejected if a tertiary group is defined.
Active	Tick if this analysis code is in use.

Workflows / Chained Events

Menu Location: System Admin > Customer Service > Set Up Chained Events

See Set Up Chained Events

Chained events are effectively a series of linked events forming a workflow or process sequence.

This routine holds a list of chained events (workflows) designed to guide an operator through a series of tasks related to a service call.

When selected from the menu the routine offers the ability to select an event to view related workflows or to create a chain event sequence for. This is referenced as the master event in this document.

The TOGGLE button changes the display, alternating between a single line per master event or a detailed list of all chained events for a specific master event.

The NEW button allows the operator to create a chained event or edit the composition of an existing master event.

Chained Events

Having identified the master event (or by clicking the icon the routine allows a series of chained events to be added to the master event.

Loan Stock

The Loan stock tick box when ticked prohibits the stock from being sold on a sales order.

It is only possible to set the loan indicator for unique items, measured goods (further cuts are prohibited) and accessory items with a unit quantity of 1.

The item must have a zero markdown price and a markdown reason selected.

Loan stock is excluded from the catalogue search results (as per the existing ‘available to sell’ field). I.e., the operator cannot sell loan stock or see it in the available stock lists.

When searching for stock via the stock management or search stock the category tab the operator may to choose whether to show only, exclude loan stock.

Ticking loan stock automatically un-ticks the ‘available to sell’ field and it is not possible to tick the ‘available to sell’ for loan goods.

The loan indicator cannot be changed if the item is allocated to a sales order.

It is not possible to set measured or service items goods as loan items.

Sold stock and goods on purchase order cannot be marked as loan stock.

The system identifies loan stock with the icon.

The system will allow the allocation of loan goods to the sales order via the loan service action. They cannot be amended outside of service but can be re-scheduled for delivery / collection but not removed from a delivery run without being scheduled on another.

Loan items flagged as ‘not available for sale’ cannot be allocated to sales orders.

Loan stock is automatically marked down to zero. i.e., they have no selling value.

All loan stock added to the sales order will be added at zero cost to the customer irrespective of the current prevailing promotional selling price.

Once the item has the ‘loan’ indicator removed it will revert to being ‘saleable’ however the stock audit will show the dates the item became and ceased to be a loan item.

When viewing the stock list, it is possible to make group changes to the selected stock’s status via the Modify option.

If there is one or more stock item with the loan stock set and the operator attempts to set the available to sell flag a warning message will be produced, and the action blocked.

Loan stock status will not change if the item is allocated to a sales order.

If there is one or more stock item with the available to sell control set or allocated to a sales order and the operator attempts to set the available to sell flag a warning message will be produced, and the action blocked.

Service Templates

Menu Location: System Admin > Customer Service > Set Up Service Templates

See Set Up Service Templates

Service templates are used to generate base document which can be used by the system when issuing messages to the customer in respect of a service action.

Service Email Addresses

Menu Location: System Admin > Customer Service > Set Up Service Email Addresses

See Set Up Service Email Addresses

SwanFRS uses a seperate set of ‘issuing’ email addresses to the sales engine.

Anyone in customer services issuing emails needs defining unless you use a generic customer service email address when issuing communications to customers and suppliers from within customer service.