Projects:Service-and-Support-Management
Contents |
Service and Support - Functional Specifications
This document holds the functional requirements and design for the functionality called Service and Support management (SSM) in Openbravo.
Overview
In its current state, this document is intended to serve as a base of discussions over the final scope.
Purpose
Service or Support requests are part of the after-sales process. How service requests are handled, determine in many ways how a customer perceives the friendlyness and efficiency of the store or brand. The sales process itself, including the definition of the product behavior in terms of relation to physical product(s), the pricing and quantity is already being handled in a different project.
Scope
The scope of this project is the handling of Service and Support requests. This includes the following:
- A request for service(service call or call) is the recording of a request(what), related to a previous purchase(sale), by the customer(who) on a specific moment(when).
- A call can be a claim on a faulty product. There could be (or not) a warranty on this product. This claim can be in- or out the warranty.
- A call can be a request for a (payable) service, f.i. the anual maintenance of the airconditioning system. In this type of call, there are
- costs (material usage, labor and expenses)
- revenues (invoiced amount). Either a one-off or according to a service contract.
- Service contracts can be left out of scope.
- The management of the calls should be intergrated with the sales, logistics, planning and financials of Openbravo.
- A service request can be related to any sale and should be verified by the sales ticket.
- It should be possible to create calls through any channel, digital or physical.
- A sale for a serial#/lot# controlled product should also be verified in the Installed Base of Products(ISP).
- A workflow should be integrated in order to route the call internally.
- A request should have several codes to facilitate this workflow, for instance:
- Severity (influences the workflow in timing, priority)
- Expertise (influences the workflow in routing)
- Status (f.i. new, to be investigated, investigated, to be accepted, accepted, to be assigned, assigned, planned, rejected, canceled, etceteras.
- Type (f.i.: preventive, repair, installation, information, ...)
- ...
- It should be possible to define engineers, each with a set of expertises.
- It should be possible to manage inventory (move, count, use) for each of the engineers.
- It should be possible to plan these engineers to assist on the requests
- It should be possible to define warranty-levels in terms of
- coverage of material usage (%),
- coverage of labor usage (%),
- coverage of expenses (%).
- It should be possible to assign any costs and revenues to specific GL-accounts to facilitate financial analysis separated from the normal sales flow.
- It should be possible to define warranty duration in terms of months after initial sales.
- It should be possible to assign a warranty (code) to a product group and to a single product. In the latter case it would overwrite the group-level warranty code.
Process flow
When selling a serial#-controlled item, either via WebPOS or via backoffice sales, the serial# of the picked product is to be entered (scan, manual).
The goods-issue will create an Installed Base (IB) record with the warranty details (product, serial, date, customer, warranty code, etceteras.). This IB record is to be consulted when a Request for Service (RfS) is created and determined if the service is under warranty or if a quotation is to be created, awaiting customer approval.
Goods receipts of a serial#-controlled item will open a window to enter (scan, manual) the received serial#.
References
Design Considerations
Assumptions
Dependencies
Dependencies should be to Core Module only ( including reservation functions)