GCSS

Operational Guide

1. Introduction

The standard solution for the communication between Customer Service departments/call centers in PRIME is the IPC Global Customer Service System (GCSS), available through the Internet. There are 3 separate modules for PRIME in GCSS:

  • Exprès
  • Registered
  • Insured

Each module enables CS agents to exchange inquiries for the respective product through a specific workflow. This workflow consists of requests and replies, and is subject to a formalized set of parameters based on competitive response targets, with a strong focus on quality (e.g. observing pro-active approach, exchanging relevant information, and providing conclusive replies). Various tools in the workflow help agents to adhere to these quality levels.

Although workflows may slightly vary from product to product (or module to module), the generic lay out and workflow set up in GCSS allow agents/users to easily switch between modules without much training. This document goes through all aspects of PRIME Customer Services, describing different steps in the workflow and the corresponding activities to perform, from the perspective of the requesting partner and the replying partner.

Note that GCSS is the dedicated communication tool for PRIME members’ Customer Service departments: e-mail, phone and fax should only be used in case of emergency.

PRIME Customer Services is supported at IPC by a helpdesk, assisting users in case of technical or operational issues. The helpdesk also creates and distributes several GCSS reports on a monthly basis.

More information on the functionalities and workflow in GCSS can be found in the GCSS User Manual (available on-line).

Note

It is highly recommended that CS agents keep the PRIME CS Operational Guide and GCSS User Manual handy when performing their daily tasks!


2. Quality

GCSS revolves around the process of providing excellent quality to the customer. Achieving this however, takes more than a system alone: real quality is made by Customer Service agents.

Nevertheless, GCSS provides a variety of functionalities and tools that can help in the process of providing excellence:

  • A workflow based on quality-friendly messages and competitive response times
  • Specific messages to report incompliance of requests and replies
  • Messages to provide intermediate updates or expected reply times
  • Specific messages to provide pro-active information on item status

Reports and KPI’s are/will be defined around the system’s quality aspects: CS managers should therefore pay close attention to proper application of CS procedures and GCSS workflow functionalities.

Consult the GCSS User Manual for more information on quality aspects of the system, and annex 1 to this document for an overview of PRIME system parameters such as reply times.

3. Availability of GCSS

All PRIME Customer Service Centres have to be opened from 10:00 to 17:00 hrs, from Monday to Friday (local time). These days are called “working days”; the hours are considered “system hours”. GCSS uses these system hours (i.e. 8 consecutive hours per day) to determine reply times in the workflow.

Non-working days (e.g. weekends and National Holidays) are not considered in the process of calculating reply times. Before November 30th all PRIME Operators must enter their non-working days for the following year in the “Holiday Entry” functionality of GCSS. After validation by IPC these days are displayed under “Call centre info” in the system, and will be appropriately applied in the calculation process.

All dates and times in GCSS are displayed in local time. The reply time calculation process therefore uses time zones and daylight saving time (DST) when determining reply times (due dates).

System hours do not necessarily equal the actual Customer Services’ daily working hours; Customer Services may be open as long as preferred. In case a request is created outside system hours, the reply time calculation process starts at the first system hour at destination (i.e. 09:00 hrs next working day). In other words: due dates for reply will never be set outside the standardized working hours.

4. Helpdesk

IPC provides assistance via the Global Customer Service Helpdesk. This department is available during business hours (09:00 – 17:00) in Belgium (UTC+1; UTC+2 when DST).

E-mail: cs@ipc.be

Telephone: +32 2 724 7123

Consult the GCSS User Manual, on-line in GCSS, for more information on problem resolution and provision of details when contacting the helpdesk.

5. Tracking and Tracing

Tracking and tracing is required for excellent customer service. In PRIME this consists of item level tracking (i.e. EMSEVT) and CAPE tracking (i.e. messages covering international transport, on despatch level). Both sets are retrieved by GCSS and clearly listed, in chronological order, when tracking an item.

A full overview of tracking events and messages, with short descriptions, can be found in the GCSS User Manual. The most important tracking events on item level however, are listed hereunder:

  • EMA: posting/collection
  • EMC: departure from outward Office of Exchange
  • EMD: arrival at inward Office of Exchange
  • EMH: unsuccessful (physical) delivery
  • EMI: final delivery

Note that event EMH should contain “action and reason codes”, explaining the circumstances around the unsuccessful delivery attempt.

The tracking history is incorporated in every inquiry (requests and replies). After having tracked an item ID and escalating to a Level 1 Request (see PRIME workflow activities), the retrieved tracking information also pre-populates a number of elements in the request (e.g. destination Operator/country, weight, name of recipient etc.). Tracking information is continuously updated in GCSS.

It is the responsibility of CS agents to always verify the latest status of inquired items: before lodging an inquiry as well as during the period an inquiry is outstanding in GCSS. Note that GCSS automatically retrieves events that were received after an inquiry was created, and shows these in the message folders. Checking tracking regularly helps avoiding premature or redundant inquiries (which can be recalled if necessary).

Note that EMSEVT v3, a new set of tracking events, is being rolled out throughout the Postal networks. This implies the availability of more tracking events, containing more detailed information.

6. Written Proof of Delivery (WPOD)

A Written Proof of Delivery is mandatory in Registered and Insured, and can be either a hard copy or electronic record (e.g. available in local system or on Track & Trace website).

The request for a copy of a WPOD is made to the CS of the country of destination via GCSS (Level 1 Request, with type of request “WPOD). The copy should be returned to origin either by fax or as attachment to the Level 1 Reply in GCSS.

The minimum period for which a WPOD should be stored is 6 months, in line with the UPU standard.

7. PRIME Customer Service workflow

The PRIME workflow in GCSS consists of an escalation process, including several possibilities to provide or request additional information or updates.

Each activity in the workflow process requires specific Customer Service activities to be carried out and specific information to be provided. This is described in section 8.

Note that inquiries have to be submitted in the appropriate GCSS module: Exprès items in the EXPRES module, Registered items in the REGISTERED module and Insured items in the INSURED module. Most of the PRIME workflow functionalities and activities described in this section apply to all products/modules. In case of differences however, a clear indication is provided.

7.1 GCSS workflow set up

There are three elements in every workflow:

1. Main workflow messages Level 1 Request and Reply (L1Q & L1R) and Level 2 Request and Reply (L2Q & L2R)

2. Update messages Quality Update Messages (QUM) and Status Update Messages (SUM)

3. Notifications

7.1.1 Main workflow messages

Main workflow messages belong to the 2-tier inquiry process, each consisting of a request and a reply and are designed to convey specific information about the inquired item. Each request is subject to fixed response times, depending on the selected “type of request”.

Every main workflow starts with a Level 1 Request (L1Q). This is the message to convey all relevant information on an item inquired by a customer to the Operator that performs the actual investigation. In case the Level 1 Reply (L1R) is not conclusive the workflow can be escalated to a Level 2 Request (L2Q).

7.1.2 Update messages

In the QUM/SUM tracker (small table placed above the main menu), the update messages allow immediate follow up on workflows:

  • Quality Update Messages and –replies (QUM and QUM-Reply)
  • Status Update Messages (SUM)

Update messages are a means of communication during the workflow, to help coming to conclusive replies.

A Quality Update Message (QUM) can be created by the destination Operator to report an incompliant/unclear L1Q/L2Q in their To Do. The origin Operator, can provide the required further information by replying to the QUM (sending a QUMR). Only one QUM per request can be sent.

Status Update Messages (SUM) can be created by both Operators, to convey additional information (origin) or intermediate updates (destination). There is no limitation on the amount that can be sent, but can only be created between L1Q and L1R or L2Q and L2R. One further SUM can be created after a L1R or L2R by the destination Operator (to convey additional information just after a reply).

Note

Update messages are crucial in the process of providing excellence!

Main workflow set up including update messages:

GCSS Operational Guide

7.1.3 Notifications

Notifications are messages designed to convey pro-active information on item level, and are therefore mostly used by a destination Operator to report a problem to origin (e.g. “item found undeliverable” (i.e. requesting a better address), “item damaged” or “item delayed” (i.e. origin may reach out to customer for further escalation). Notifications can be either replied or ignored. Reply times are not applied.

Note

Notifications play an important role in the process of being pro-active. It is therefore highly recommended to create Notifications in case of issues around delivery, and follow up with the customer (mostly the sender) when possible.

A Notification can also be sent by the CS at origin, in case pro-active information is requested on an item. Note that a Level 1 Request is allowed to be created after a Notification, but a Notification is not allowed after a Level 1 Request.

7.2 Type of Request

Level 1 and Level 2 Requests require the selection of a “type of request”, corresponding to the nature of the inquiry (e.g. WPOD, Customs etc.). The type of request drives the following throughout the workflow:

  • Appearance and optionality of data elements in L1Q and L2Q, as such ensuring the provision of relevant information
  • The allocation of ample response times (some types of request require more time to solve than others!)
  • Available reply types. This implies that a specific, and relevant, set of reply types is available for selection in L1R and L2R, depending on the type of request selected in the corresponding request.

The type of request may change when escalating from L1R to L2Q, depending on the outcome of the investigation or the status of the item. Note also that not all types of request are available in both request levels: this set up follows the PRIME workflow logic, which dictates a certain order in the use of types of request, or the finalization of particular workflows in only one level (i.e. Level 1).

Types of request are clearly indicated in the message lists/folders (including their respective due dates), helping agents to organize their work accordingly.

Notes:

  • More details about the workflow set up and specific parameters (i.e. what can and cannot be done) can be found in the GCSS User Manual
  • Specific parameters used in the PRIME workflow (e.g. types of request, reply times) are listed in Annex 1 to this guide.

8. PRIME workflow activities

In general it is expected that the CS receiving an inquiry does its utmost to locate an inquired item, in particular when receiving a Level 2 Request. This includes searches in (local) Track & Trace databases, at the Office of Exchange, sorting centers, delivery networks, depot for mail-without-address etc., and requires therefore a good cooperation with other departments/business units (e.g. Transport, Operations, Sorting & Delivery, IT etc.).

In case no delivery information is available, but event EMC or PREDES are received (or further events), it is highly recommended, again in particular when receiving a L2Q, to send out a CN18 to the addressee in order to obtain final confirmation.

The workflow activities described in the following sections are based on inquiries lodged by the sender of the item. GCSS however, also provides the possibility to exchange inquiries (and claims) lodged by the addressee. For liability and indemnity in case of inquiries submitted by addressees please consult the UPU Letter Post Manual - Article 24 - Payment of indemnity Ref. par. 2.

8.1 Tracking and item ID

Every inquiry starts with item tracking. GCSS contains the latest tracking information, including CAPE messages (often not available on Track & Trace websites), which may lead to the provision of sufficient information to convey back to the customer. Examples thereof are a recently received EMI event, or CAPE messages showing that the item has arrived at destination and will be delivered soon.

Note

Important: before lodging an inquiry on GCSS agents will have to make sure not to send premature messages. This should be done by consulting the tracking events (available in GCSS) and by consulting operational information about transit times and delivery schedule. No inquiries should be created before the item is scheduled for delivery at destination!

In case the tracking information is not sufficient, and the inquiry is not premature, the CS representative continues with the creation of a Level 1 Request.

8.2 Level 1 Request and Reply

8.2.1 Creating Level 1 Request

All inquiries start with a Level 1 Request (L1Q). Before launching this request through GCSS however, it is of crucial importance that the CS representative gathers as much information as possible from the customer. Although this may vary depending on the type of request, it is recommended to anticipate on upcoming escalation and liability cases, thus providing detailed descriptions of contents, physical description, value (including evidence) and indemnity amount. This avoids having to contact the customer again in case the L1R is escalated to L2Q.

Note

The more information provided, the higher the chance to receive a conclusive L1R!

The remarks section is mandatory, and allows the agent to clearly specify the request, explain the particular circumstances around the inquiry and clarify incomplete or inconsistent tracking information. Add attachments (e.g. item label) whenever appropriate.

Status Update Messages (SUM) can be sent should relevant additional information be received from the customer after having sent the L1Q.

8.2.2 From Level 1 Request to Level 1 Reply

Upon receiving a L1Q the destination CS opens the message without delay, so to ensure using as much time as possible for the actual search. Reply times for L1Q depend on the type of request selected.

In case the L1Q is incompliant, incomplete or unclear, a Quality Update Message (QUM) should be sent without delay. Note that sending a QUM does not exempt destination from investigating the case! A reply to the QUM is optional, but may help the search whenever provided. Upon receiving a QUM, as origin Operator, it is therefore of crucial importance to act as quick as possible, providing the missing information or clarifying the request in the QUM Reply.

The activities to perform in order to solve a L1Q may vary, but the following should be considered when providing the final reply:

  • Selection of a relevant reply type (selection based on type of request)
  • Provision of as many fixed details as possible (e.g. location of delivery or collection, despatch information in case of return, verification note when an item is lost or damaged etc.)
  • Provision of elaborate remarks: specification of the investigation (e.g. what exactly has been done), anomalies around the item (e.g. reason for delay or misdelivery etc.) and clarification of incomplete or inconsistent tracking information
  • Add attachments (e.g. WPOD) whenever appropriate
  • Authorization code and indemnity amount authorized in case the inquired item is deemed damaged or lost and subject to liability at destination (only applies to Registered and Insured)

The more conclusive information provided, the higher the chance not to cause further escalation. In case no conclusive information is obtained around the due date of the request, but likely to become available soon after, the destination CS should send a SUM, explaining the situation and providing an expected reply date and time.

Note

It’s better to send a SUM before due date, followed by a delayed conclusive reply, than an inconclusive on-time reply that requires further escalation!

8.3 Level 2 Request and Reply

8.3.1 From Level 1 Reply to Level 2 Request

Upon receiving a L1R the origin CS opens the message without delay. This allows immediate feedback to the customer, especially in case of a conclusive reply. If the reply is not conclusive it is recommended to inform the customer of the expected reply date to the following L2Q

In case the L1R is incompliant, incomplete or unclear (note: in L1R this does not necessarily mean inconclusive!), the agent should use the Reply Rating tool, flagging the reply as such.

Hereafter a Level 2 Request (L2Q) should be sent, as soon as possible (i.e. preferably within 2 days). If necessary, the type of request can be changed. If not, all information from the L1Q is retained in the L2Q.

Remarks are also mandatory in L2Q, allowing an update on request specifications. Additional attachments can be added when appropriate and SUM’s can be sent whenever necessary.

8.3.2 From Level 2 Request to Level 2 Reply

A Level 2 Reply should, under most circumstances, be the final message in the PRIME workflow. Upon receiving a L2Q the destination CS opens the message without delay, so to ensure using as much time as possible for the actual search (in particular when a CN18 has to be sent). Reply times for L2Q are standardized to 10 working days, as such allowing for the process of determining liability.

Update messages QUM and SUM can be used similar to the Level 1 process, although a “courtesy SUM” (i.e. keeping CS at origin posted on progress) will be appreciated given the 10 days reply time in level 2.

The activities to perform in order to solve a L2Q may vary, but the following should be considered when providing the final reply:

  • Selection of a relevant reply type (selection based on type of request)
  • Provision of as many fixed details as possible (e.g. location of delivery or collection, despatch information in case of return, verification note when an item is lost or damaged etc.)
  • Provision of elaborate remarks: specification of the investigation (e.g. what exactly has been done), anomalies around the item (e.g. reason for delay or misdelivery etc.) and clarification of incomplete or inconsistent tracking information
  • Add attachments (e.g. WPOD, CN18) whenever appropriate
  • Authorization code and indemnity amount authorized in case the inquired item is deemed damaged or lost and subject to liability at destination (only applies to Registered and Insured)
Note

A Level 2 Reply must be conclusive! This implies that either the inquired is located, or liability undisputedly determined. See determination of liability for more information.

Upon receiving a L2R the origin CS opens the message without delay. This allows immediate feedback to the customer (who should have been informed of the expected reply date). In case of incompliancy (in case of L2R this includes inconclusiveness!) the Reply Rating tool should be used.

8.4 Reactivation

Upon receiving an inconclusive L2R, the CS at origin may decide to reactivate the inquiry. Doing so “restarts” the workflow at L1Q, with all previously submitted information retained. It is important to enter clear remarks (explaining the reactivation) and add relevant attachments if needed. There is no further difference with a regular workflow: escalation to L2Q is possible, and update messages and reply rating can be used.

Reactivation should only be performed in exceptional cases: incompliancy in L2R (e.g. no liability accepted whereas it should have been), or following a special request from the customer.

There is no limit to the number of reactivations of a workflow, but every time it happens GCSS flags the inquiry as such for reporting purposes.

9. Broadcast message

A Broadcast message is created in order to advise other Operators on situations that could have impact on them, operationally, or from a CS point of view. These situations could be “general” or “country/Operator specific”, and can as such be sent to one, multiple or all Operator(s).

Examples are strikes, weather conditions preventing regular transport or delivery, announcing track & trace issues. Broadcast messages should not be used for item related requests (e.g. address corrections), request for holding inquiries, etc.

10. Validity period of inquiries

Customers are allowed to submit inquires for a period of 6 months starting from the day after posting. In case the 6 months period is exceeded, handling of the inquiry is up to the willingness of the destination CS, but liability does not have to be accepted.

11. Liability & Indemnity

Only Registered and Insured items are subject to the liability procedure and subsequent payment of indemnity. This procedure is undertaken in either the Level 1 Reply or Level 2 Reply (the latter being the most likely option).

The following liability amounts apply:

  • For Registered the maximum possible indemnity is set to 30 SDR
  • For Insured it is mandatory to fill in the insured value of the item in the appropriate box in the Level 1 and/or Level 2 Requests

The section on liability and indemnity is divided in 4 parts:

1. General information on liability details per product
2. General information on liability in the GCSS workflow

3. Lost items: determination of liability in case of lost items

4. Damaged items: determination of liability in case of damaged items

11.1 General Information on liability (per product)

Note

Please refer to the Letter Post regulations (Letter Post Manual), as amended, for details on liability and indemnity. Amendments are made from time to time by Postal Operations Council of the UPU, so please check you are referring to the most recent copy.

Determination of final liability is depending on scan events (lost items) and the provision of documents (damaged items). This is specified in the corresponding sections 11.3 & 11.4 hereunder.

EXPRES:
It is the Origin Operator’s responsibility whether it offers compensation for Exprès to their customers (i.e. senders). The Destination Operator has no liability.

REGISTERED:
If a destination Operator loses or (partly) violates a Registered item a liability procedure applies. Independently of the sending Operator’s liability to its customers, the receiving Operator’s liability to the sending Operator is limited to a maximum of 30 SDR as per RL155.4. The indemnity for the loss of, total theft from or total damage to a registered M bag shall be 150 SDR.

Charges and fees paid by the sender for posting the item, with the exception of the registration charge, shall be added to these values to determine the total compensation payable. (Note: Indemnities in general, for Registers and Insured items, are covered by article 21 Convention – also RL155, Article 22 also RL156, Article 23 RL157 and Article 24 RL158, 159, 160, 161. Article 25 and its regulations may also apply).

INSURED:
If a destination Operator loses or (partly) violates an Insured item a liability procedure applies. The limit for Insured varies from Operator to Operator but is subject to the maximum amount published by the destination Operator. This can be up to 4000 SDR per item but is related to that Operator’s domestic rates. Refer to the relevant articles in the convention listed above and to any other regulations regarding insured items. Please note that some Operators have reservations listed in the regulations. See also article RL134 of the Letter Post Manual.

The amount to be paid in case of indemnity (i.e. for both registered and Insured) is subject to the provision of suitable documentary evidence proving the value of the content of the damaged or lost item as well as the postage paid. This evidence is sent from the sending customer to the CS in the country of origin. The latter must include the value of the lost or damaged item in the appropriate field of the Level 1 and/or Level 2 Request.

The Accounting department deals with financial settlement of damaged and lost items, using the UPU document CN48. This document should contain the information supplied by the destination CS, such as authorization code, country of origin, item ID, and the amount claimed. See 11.3 & 11.4 for further details. IPC can supply a monthly printout of all authorizations given and received by a designated operator.

Note

Important: Article 24 - Payment of indemnity Ref. par. 2

The sender may waive his rights to the indemnity in favour of the addressee. Conversely, the addressee may waive his rights in favour of the sender. The sender or the addressee may authorise a third party to receive the indemnity if internal legislation allows this. Refer to this article when handling an addressee claim!

11.2 General Information on liability in GCSS workflow

Communication on indemnity should be done only via GCSS. When the destination Operator has determined that liability is at their end (see par. 11.3.1. & 11.4.1 below for the process of determining liability) an authorization code is provided in the Level 1 or Level 2 Reply. For lost items authorization is likely to be provided in the Level 2 Reply, given that destination Operators would prefer to use the maximum reply times for their investigations. Authorization for damaged items may be given earlier (i.e. in Level 1 Reply), in particular when damage was already reported by the recipient and documented on a CN24.

The authorization code provided by the destination CS, using the Level 1 or Level 2 Reply, has no specific format (the Operator at destination is free to choose, e.g. using origin country code, date, item barcode number, etc.).

11.3 Lost Items

11.3.1 Liability in country of destination

If the last scanning point in the process was an EMD or later event (EME, EMF, EMG, EMH, EMI), and there is no record of the item being returned to sender, the item is deemed to be lost in the destination country. In this case the CS agent at destination has to provide the authorization to the CS of the origin country in order to start the indemnity procedure. The authorization is provided by means of filling in an authorization code in the relevant box in the Level 1 Reply or, more likely, the Level 2 Reply.

Subsequently the CS agent at destination informs their Accounting department of the outcome of the inquiry, providing the authorization code, the country of origin, the item ID, and the amount claimed (which was already provided by origin CS in the Level 1 or 2 Request).

After having paid indemnity to the sender, the origin Operator will claim the amount in the periodical accounting on document CN48, which contains the authorization code from the closed GCSS inquiry. The Accounting departments of both the origin and destination partners will carry out this activity.

Important note: for waiving of rights in favour of the addressee please see section 11.1.

11.3.2 Liability in country of origin

If the last scanning point in the process was an EMC or an earlier event (EMA or EMB), and there is no record of the item being delivered to the addressee (written POD; CN18), the item is deemed to be lost at origin. In this case there is no need to provide an authorization code. The CS in the origin country will apply their internal procedure with regard to indemnity to its customer.

11.4 Damaged Items

11.4.1 Liability in country of destination

It is the responsibility of each Office of Exchange (OE) to check the condition of all incoming items. When the Track and Trace system shows that a item has been EMD scanned, and in the absence of a verification note (CP78) drawn up prior to the EMD scan, the destination Operator is responsible for any damage subsequently reported to have occurred to the item on its way to the addressee. When an item is found damaged within the PRIME network, a damage report (CN24 or similar) must be drawn up by the Operational Staff and sent to their Customer Services. This report should contain the following details:

  • Item number
  • Despatch number and despatch date
  • Weight according to document and observed weight
  • Addressee’s and sender’s name and address
  • Brief description of the damage
  • Location
  • Details of what has been done to the item i.e. forwarded on for delivery, disposed etc.

The CS at destination country informs their counterparts at origin of the damage and the subsequent actions taken. This should be done through a Notification in GCSS (in case no inquiry was yet submitted by origin). It is recommended to attach an actual copy of the report to the GCSS message and provide as much relevant information as possible.

In case an inquiry already exists, and the damage is recorded in the course of the investigation, the CS at destination reports this in the Level 1 or 2 Reply (depending on the status of the inquiry). Also here it is recommended to attach an actual copy of the report to the GCSS reply and provide as much relevant information as possible.

Provided that the Operator at destination is liable for the damage, an authorization code is included in the Level 1 or Level 2 Reply. Subsequently the CS agent at destination informs their Accounting department of the outcome of the inquiry, providing the authorization code, the country of origin, the item ID, and the amount claimed (which was already provided by origin CS in the Level 1 or 2 Request).

After having paid indemnity to the sender, the origin Operator will claim the amount in the periodical accounting on document CN48, which contains the authorization code from the closed GCSS inquiry. The Accounting departments of both the origin and destination partners will carry out this activity.

Important note: for waiving of rights in favour of the addressee please see section 11.1.

11.4.2 Liability in country of origin

When an item is found damaged in the exporting country, a report (CN24 or similar) must be drawn up by the Operational Staff and sent to their Customer Service, which contacts the customer and asks for instructions.

Indemnity to the sender should be handled and paid by the origin partner, based on domestic regulations.

If the content of the item has not been damaged or partially lost, but only the item packaging has been damaged, the sending partner should repair and secure it and inform its CS, prior to forwarding it to the destination country. A dedicated label should be put on the item indicating that it was repaired at origin.

A report should also be added. This report should contain the following details:

  • Item number
  • Real Weight
  • Addressee’s and sender’s name and address
  • Location
  • Details of what has been done to the item

Important note: for waiving of rights in favour of the addressee please see section 11.1.

11.4.3 Item damaged after EMC event and prior to EMD event

In case a item was found damaged at the destination OE, prior to be EMD scanned, a report (CP78 or similar) must be drawn up by the Operational Staff and sent to their Customer Services within 24 hours after the EMD event was scanned at the OE. The CS at destination immediately forwards this report to the CS in the origin country. The report should contain the following details:

  • Item number
  • Despatch number and despatch date
  • Weight according to document and observed weight
  • Addressee’s and sender’s name and address
  • Brief description of the damage
  • Location
  • Details of what has been done to the item i.e. forwarded on for delivery, disposed etc.

The CS at destination country informs their counterparts at origin of the damage and the subsequent actions taken. This should be done through a Notification in GCSS (in case no inquiry was yet submitted by origin). It is recommended to attach an actual copy of the report to the GCSS message and provide as much relevant information as possible.

In case an inquiry already exists, and the damage is recorded in the course of the investigation, the CS at destination reports this in the Level 1 or 2 Reply (depending on the status of the inquiry). Also here it is recommended to attach an actual copy of the report to the GCSS reply and provide as much relevant information as possible.

Items damaged after EMC event and prior to EMD event (i.e. it cannot be determined which Operator is responsible for the damage) are subject to shared liability, i.e. on a 50/50 basis.

Provided that the liability for the damage is shared, an authorization code is included in the Level 1 or Level 2 Reply, reflecting 50% of the amount provided by the origin CS in the Level 1 or 2 Request. Subsequently, the CS agent at destination informs their Accounting department of the outcome of the inquiry, providing the authorization code, the country of origin, the item ID, and the amount claimed (i.e. 50% of the amount already provided by origin CS in the Level 1 or 2 Request).

After having paid indemnity to the sender, the origin Operator will claim the amount in the periodical accounting on document CN48, which contains the authorization code from the closed GCSS inquiry. The Accounting departments of both the origin and destination partners will carry out this activity.

Important note: for waiving of rights in favour of the addressee please see section 11.1.