Principle

From the customer form to the handled request

  1. The customer starts from their order

    From « My requests » or from an order's detail, they pick the line concerned. The module derives the request type: warranty for a product, support for a service, from the nature of the product sold.

  2. The form adapts

    A product asks for a reason, a description, photos and possibly a serial number; a service asks for the version concerned and, if you enabled it, the access details needed to intervene. The order date is compared with the coverage period: outside coverage, the request is still possible if you allow it, and the file says so.

  3. The request lives in the back office

    Every request has a status (new, waiting for your reply, in progress, under repair, refunded, closed…), a message thread with the customer, its attachments and its history. The statuses are yours: label, colour, type concerned, e-mail to the customer or not.

  4. Product return

    For a product request, a PDF return slip carries the return address and your packing instructions: the customer prints it and slips it into the parcel.

  5. Closing

    The chosen resolution (repair, replacement, refund, fix delivered…) closes the request. The confidential access details entrusted by the customer are erased, and an e-mail reminds you to delete any you noted elsewhere.

One single entry for the customer — other FreshApp modules can graft their own requests onto it (withdrawal, for instance): the customer keeps « My requests » as a single entry point.

Loading...
Back to top