faq

Frequently Asked Question on Speed Post KPIs

P a g e | 1

Index: Speed Post KPIs

Contents/ Questions/ Clarifications/ Issues Page No

1. Missorts KPI Calculation 2

2. Mismatch between Delivery scan compliance and its details 3

3. Mismatch between Inbound Operational Performance and its details 5

4. Why is the Articles with full scans Report on KPI web page is 7

not backed up by the raw data catered from CEPT?

5. Calculation logic of Missing PIN Code 8

6. Calculation logic of report – Delivery Scan Compliance 9

7. Does remarks other than “Final Delivery” impacts the KPI – Delivery

Information Upload 10

8. Does the NTD Missort Articles impact the Inbound Operational

Performance? 10

9. Will the BOs or non-computerized offices appear in the drop-down

menu? If a particular office does not appear, what do we do? 11

10. What‟s the provision of Intercepting Station Articles in SpeedNet? 12

11. Do prescribed number of scans for TD Full Scan Compliance KPI

also apply for Station articles 16

12. Number of TD-NTD Missort/Scans/Delayed articles reflecting in

Transit Analysis Tool does not match with data available on KPI webpage 16

13. How is delivery information upload efficiency KPI calculated 16

14. Why the delivery information upload efficiency shows the SO Name

only, however the delivery has actually happened through the BOs 17

15. Whether all the Speed Post articles are taken while calculating the

TD/NTD transit time or not 17

16. What is reason behind the difference in delivery data reflecting in

Speed net MIS and on KPI webpage 17

17. Why less scans are reflecting in raw data whereas track and trace report

is showing all the mandatory scans? 18

18. Why does the Leg level transit time for TD/ NTD do not sum up to the

average D+x numbers 20

19. Why is the D+x numbers different from D+x number in Transit

Analysis Tool 22

20. What does the leg code in the Rawdata means? 22

21.What is the calculation Logic of „Delivery PO Efficiency Report‟ ? 24

P a g e | 2

1. How is Missorts KPI Calculated?

Basic Assumptions:

UID Articles are discarded RGI and EPP Articles are discarded Return to Sender (RTS) articles are discarded New Calculation is applicable from 25

th Feb, 2012 and onwards for

all sorting hubs TD Missorts:

Consider all the articles delivered under the catchment area of a Sorting hub, (being booked in the same sorting hub) on a specific date.

Check the delivery office and corresponding PIN Code of the

delivery office Also, look for the bag closing data, and get the office to which the article

was sent from the Sorting Hub for delivery – There could be three possibilities:

o A Bag has been closed for the Sorting Hub

o A Bag has been closed for the Nodal Delivery Office o A Bag has been closed for the delivery office

If the PIN code of the delivery office is not Mapped to either of the

three possibilities in the previous step, i.e. o If the PIN code of the delivery office is not the part of the

catchment area of the IC Hub

o If the PIN code of the delivery office is not mapped to the Nodal Delivery Office

o If the PIN code of the delivery office is not same to that of the Bag sent Office‟s PIN code

then the article is considered Missent NTD Missorts:

Consider all the articles delivered outside the catchment area of a Sorting hub of booking, on a specific date.

Check the delivery office and corresponding PIN Code of the

delivery office

Find the delivery Sorting Hub based on the PIN code of the delivery office and all the IC Hubs of the circle of the origin sorting hub

Find the destination Sorting hub to which the bag was closed for that

particular article

In case the destination sorting hub and delivery sorting hub are not the same or to the IC Hubs then it‟s a missent.

P a g e | 3

2. Why the Delivery Scan Compliance report not backed up by it‟s linked details?

Basic Assumption

UID Articles are Discarded

RGI and EPP Articles are discarded

Only TD articles are considered

The Summary report (The First screen) is calculated as part of the regular KPI calculation every night and de-facto is information is stored for any time reference purposes, however, the linked details are not static and whenever the report is evoked, a fresh query is run to display the current snapshot.

While calculating the KPI, we are based on the D-1 snapshot, whereas while seeking the details, we get 1 more day of refreshed data, which may lead to mismatch, in case there is more delivery information uploaded during the day.

ILLUSTRATIVE EXAMPLE

PAB : 60 articles delivered PBD: 10 articles delivered P>D: Report viewed

B

A C D

A:= 100 articles were booked on D-6

PAB:= 60 Articles were delivered in Next 5 working days till D-1

B:= Data is loaded for KPI calculation for D-1

C:= KPI is calculated on D-1 snapshot of the data and stored with 40% of the TD articles not having delivery information which is displayed on the summary (first) screen of this report

PBD:= 10 more articles are delivered out of those 100 booked D-6

D:= Data is loaded on D snapshot for reference and future KPI calculations

P>D:= Report is viewed for the first time, which shows 40% missing scans on

Summary but only 30 Articles in details – mismatch is noticed.

P a g e | 4

For Day schedule example for Delivery scan compliance. The gazette

holidays and Sundays are excluded when calculating the dates.

Report Date Day

01/11/2012 01/11/2012 31/10/2012 30/10/2012 29/10/2012 28/10/2012 27/10/2012 26/10/2012 25/10/2012

Day 5 Day 4 Day 3 Day 2 Sunday Id Ul Fitar Day 1 Booking Day

02/11/2012 02/11/2012 01/11/2012 31/10/2012 30/10/2012 29/10/2012 28/10/2012 27/10/2012 26/10/2012

Day 5 Day 4 Day 3 Day 2 Day 1 Sunday Id Ul Fitar Booking Day

03/11/2012 03/11/2012 02/11/2012 01/11/2012 31/10/2012 30/10/2012 29/10/2012

Day 5 Day 4 Day 3 Day 2 Day 1 Booking Day

04/11/2012 04/11/2012 03/11/2012 02/11/2012 01/11/2012 31/10/2012 30/10/2012 29/10/2012

Sunday Day 5 Day 4 Day 3 Day 2 Day 1 Booking Day

05/11/2012 05/11/2012 04/11/2012 03/11/2012 02/11/2012 01/11/2012 31/10/2012 30/10/2012

Day 5 Sunday Day 4 Day 3 Day 2 Day 1 Booking Day

06/11/2012 06/11/2012 05/11/2012 04/11/2012 03/11/2012 02/11/2012 01/11/2012 31/10/2012

Day 5 Day 4 Sunday Day 3 Day 2 Day 1 Booking Day

07/11/2012 07/11/2012 06/11/2012 05/11/2012 04/11/2012 03/11/2012 02/11/2012 01/11/2012

Day 5 Day 4 Day 3 Sunday Day 2 Day 1 Booking Day

12/11/2012 12/11/2012 11/11/2012 10/11/2012 09/11/2012 08/11/2012 07/11/2012 06/11/2012

Day 5 Sunday Day 4 Day 3 Day 2 Day 1 Booking Day

13/11/2012 13/11/2012 12/11/2012 11/11/2012 10/11/2012 09/11/2012 08/11/2012 07/11/2012 06/11/2012

Diwali Day 5 Sunday Day 4 Day 3 Day 2 Day 1 Booking Day

18/11/2012 18/11/2012 17/11/2012 16/11/2012 15/11/2012 14/11/2012 13/11/2012 12/11/2012 11/11/2012

Sunday Day 5 Day 4 Day 3 Day 2 Diwali Day 1 Booking Day

19/11/2012 19/11/2012 18/11/2012 17/11/2012 16/11/2012 15/11/2012 14/11/2012 13/11/2012 12/11/2012

Day 5 Sunday Day 4 Day 3 Day 2 Day 1 Diwali Booking Day

20/11/2012 20/11/2012 19/11/2012 18/11/2012 17/11/2012 16/11/2012 15/11/2012 14/11/2012

Day 5 Day 4 Sunday Day 3 Day 2 Day 1 Booking Day

P a g e | 5

3. Why is the Inbound Operational Performance Report on KPI web page is not backed up by the raw data catered from CEPT?

Basic Assumption



Only Inbound TD articles are considered

Articles which are made RTS after receipt by the hub or any office under the hub are excluded.

The said report is calculated as part of the regular KPI calculation every night and de-facto information is stored for any time reference purposes, however, the raw data is extracted always on a refreshed set of data.

While calculating the KPI, we are based on the D-4 snapshot, whereas while generating the raw data, we get at least 1 more day of refreshed data, which may lead to mismatch, in case there is more delivery information uploaded during the day. Articles which are made RTS after receipt by the hub or any office under the hub is not taken in to count.

ILLUSTRATIVE EXAMPLE

PBD: Delivery info of

PAB : 80 articles delivered remaining 20 articles is

uploaded in historic date

P>D: Report

viewed & raw data is extracted

A PAB : 60 article‟s B C D

delivery info is uploaded

A:= 100 articles were received during the cutoff Period of D-4

PAB:= 80 Articles were delivered in Next possible delivery round however information for

only 60 articles were being uploaded and communicated to the central server. B:= Data is loaded for KPI calculation for D-4; only for 60 articles has the delivery information on D-4

C:= KPI is calculated on D-4 snapshot of the data and stored with 60% of the Inbound Operational Performance and remains available on web page

PBD:= Delivery information for remaining 20 articles are uploaded on D-3 or later;

delivered through either BO or some non computerized office is uploaded on historical date/ communication glitch from the delivery office is resolved and the delivery date remains D-4

P a g e | 6

D:= Data is loaded on D-3 snapshot for reference and future KPI calculations

P>D:= Raw data is extracted and those articles loaded in Step C shows up as mismatch,

however bearing the delivery date of D-4 only. Hence the Report shows 60% only, the track and trace as well as the raw data would suggest 20 more articles were delivered in time.

P a g e | 7

4. Why is the Articles with full scans Report on KPI web page is not backed up by the raw data catered from CEPT?

Basic Assumption



The said report is calculated as part of the regular KPI calculation every night and de-facto information is stored for any time reference purposes, however, the raw data is extracted always on a refreshed set of data.

While calculating the KPI, we are based on the D-4 snapshot, whereas while generating the raw data, we get at least 1 more day of refreshed data, which may lead to mismatch, in case there is more delivery information uploaded during the day. ILLUSTRATIVE EXAMPLE

PBD: Delivery info of

PAB : 80 articles delivered remaining 20 articles is

uploaded in historic date

P>D: Report

viewed & raw data is extracted

A PAB : 60 article‟s B C D delivery info is uploaded

A:= 100 articles were received during the cutoff Period of D-4

PAB:= 80 Articles were delivered in Next possible delivery round however information for

only 60 articles were being uploaded and communicated to the central server. B:= Data is loaded for KPI calculation for D-4; only for 60 articles has the delivery information and full scans information on D-4

C:= KPI is calculated on D-4 snapshot of the data and stored with 60% of the articles having full scans and remains available on web page

PBD:= Delivery information and scans information for remaining 20 articles are uploaded

on D-3 or later; delivered through either BO or some non computerized office is uploaded on historical date/ communication glitch from the delivery office is resolved and the delivery date remains D-4

D:= Data is loaded on D-3 snapshot for reference and future KPI calculations

P>D:= Raw data is extracted and those articles loaded in Step C shows up as mismatch,

however bearing the delivery date of D-4 only. Hence the Report shows 60% only, the track and trace as well as the raw data would suggest 20 more articles with full scan and delivered in time

P a g e | 8

5. Calculation logic of Missing PIN KPI Basic Assumption:

UID Articles are discarded


Articles having bag closing scan at the Hub, booked under the catchment area of the Hub is considered for the KPI Calculations

For the said KPI, all articles having the bag closing scan at the hub, being booked under the same hub formulates the denominator of the KPI. Out of these articles, those without 6 digits, non numeric PIN Code formulates the numerator of the KPI. ILLUSTRATIVE EXAMPLE: Say, 100 articles have the bag closing scan from a hub X on a particular day D. Say out of these 100 Articles, there‟s 2 articles which either does not have the Numeric PIN Code or does not have the 6 digit PIN Code.

Share of Missing PIN Code =

(Articles with without 6 digit non numeric PIN Code) X 100

(Total number of articles having bag closing scan at the hub)

P a g e | 9

6. Calculation logic of report – Delivery Scan Compliance (Share of articles without delivery scans after 5 days of booking) Basic Assumption: UID articles are excluded


Articles meant to be delivered in India only is considered

Sundays and gazette holidays are not considered

Only TD Articles are considered

For the said KPI, for any day calculation of the KPI, booking of all the articles on 5 working days back is considered from the same hub and for all those articles, date of delivery is checked. If date of delivery is not available or is more than the date of KPI calculation then the share of articles without delivery scans after 5 days of booking is calculated as Total articles with missing delivery information or greater than the KPI date

X 100

Total articles booked on D-5 of the KPI date

ILLUSTRATIVE EXAMPLE:

KPI Date: 25th

July, 2012

KPI Calculation Date: 29th

July, 2012

Considered Date of booking of articles for the KPI:19th

July, 2012

Thu D-5

Fri D-4

Sat D-3

Sun D-3

Mon D-2

Tue D-1

Wed

19-07-2012 20-07-2012 21-07-2012 22-07-2012 23-07-2012 24-07-2012 25-07-2012

Say 100 Articles were booked on 19th

July, 2012 so for the KPI of 25th

July, 2012. For share of articles not having delivery information after 5 days of

booking, all articles having no delivery information till 25th

July or delivery done

after 25th

July, will be considered for the KPI. Say, 10 articles were delivered

after 25th

and 5 articles out of these 100 do not have the delivery information yet, then the KPI will show (10 + 5) = 15%

P a g e | 10

7. Does remarks other than „Final Delivery‟ impacts the KPI – Delivery Information Upload

Only the final delivery information is counted as valid delivery information upload for the KPI. Any other non-delivery remarks are not considered for this KPI. 8. Does the NTD Missort articles impact the Inbound Operational performance of the receiving Hub? No. Articles which are made RTS after receipt by the hub or any office under the hub are excluded Basic Assumption:

UID articles are excluded



Sundays and gazette holidays are not considered

▪ Only Inbound TD Articles are considered

P a g e | 11

9. Will the BOs or non-computerized offices appear in the drop-down menu? If a particular office does not appear, what do we do? Normally, a linked BO or non-computerized office should be visible in the drop-down menu at the delivery PO (HO/SO) and the desired office can be selected. However, if a particular office does not appear in the drop-down menu, it means such an Office is not linked. There may be following reasons for the same:

1. Latest Circle Data file for Offices has not been updated into local DB. Update the same and then check the status.

2. Or else, such office might not be appearing due to the fact that: a) Such an Office exists in the Office Master but it is not having the Linked “To

Office” information, or b) Such an Office exists in the Office Master but it is Linked to some Other

Office, or c) Such an office does not exist

In this case, the System Administrator can send a list of such Offices which are not appearing even after updating the Circle Data of Offices under the “Other Office Invoice” option to [email protected]. The status of a particular office may be known through the following:

System Administrator can know the status of the Office at SPC Site under the

option -Linked Office -> Modify OfficeName. He should type the pin code of

the office which is not appearing and fetch to get the details of the Office.

If the Office Name exists there, then please copy the OfficeID, Office Name , Linked Office Name into an Excel Sheet. This excel sheet may be sent to ptcdesk@gmail through Division Head/RO/Circle Office .

Excel Sheet may have the following columns: OfficeID / Office Name / SPCto

which linked / SPC to which it is to be Linked

Note: If the Office name does not exist in the SPC site, then give the Office name with status of the Article as “Does not Exist” in the Excel Sheet. On checking the data received through Excel File, PTC helpdesk will update the Office data and will advise the office to down load the circle data for update at local DB.

mailto:[email protected]

P a g e | 12

10. Under the new network, all booking offices are required to send Speed Post articles to the concerned Sorting hub. However, an exemption was given in case of articles booked in an office and to be delivered from the same office (generally known as “Station Articles”). Does Speed Net have a provision for intercepting such articles? Yes, the provision exists in Speed Net to intercept such articles. Please follow the steps given below:

Articles to be Delivered – Locally (From same office and BO)

1. Invoicing Station Articles to be delivered locally:

Articles would have been collected through BNPL Booking / POS Booking – which are station Articles meant for Local Delivery.

There is a provision to directly invoice those articles into Delivery Invoicing option.

Note: There is no change in the process of Invoice / Returns to Station

Articles – is same as those other office articles received through Bag

for delivery at the office.

Operator->Delivery->Invoicing->SpeedPost Articles or Express Parcels->Articles for Delivery. The following invoice Screen appears. Scan the Article to the concerned beat of your office.

P a g e | 13

To take the Returns – use the following option.

2. Invoicing Articles to be delivered at Other Office to Other Office Articles ( Including BO) Option in Speed Net: Operator->Delivery->Invoicing->SpeedPost Articles or Express Parcels-> Articles or Parcels to Other Office.

P a g e | 14

Invoice the Articles in the following option:

The Offices Combo Box is shown open to see the Offices therein. Return Remarks entry for Articles sent out for Delivery to Other Offices / BOs. Operator ->Delivery->Remarks from Other Offices option.

P a g e | 15

The following screen appears for Remarks from Other Office:

Here you may fetch the Articles for the offices by selecting the invoice date

Give the Delivery Remarks

Select the Delivery Date as remarks Date. This date can be the actual Date at which the Article is delivered at BO or other office.

And save it.

Delivery Remarks Message will be created for that Article and sent to Central Server.

P a g e | 16

11. Do prescribed number of scans for TD Full Scan Compliance KPI also apply for Station articles which are booked and delivered from the same office and which do not travel to the Sorting Hub? Are these excluded from TD full scan compliance scores shown in the VC?

As these articles do not travel to the Sorting hub, 8 scans are not mandatory for these articles. However, they are not excluded from the TD scan compliance scores as of now. This is because the system has to check every article whether it is a station article in order to exclude such article from TD scan compliance which puts a lot of strain on the system and the process becomes too lengthy to be manageable. To overcome this, the maximum target for TD scan compliance for a city would be 90% assuming that not more than 10% article would fall under this category.

12. Number of TD-NTD Missort/Scans/Delayed articles reflecting in Transit Analysis Tool does not match with data available on KPI webpage Excel based Transit Analysis Tool works on the sample data of particular day to just reflect the problem area. Circles can request the raw data for further analysis.

13. How is Delivery Information Upload KPI calculated? Basic Assumption




KPI once calculated does not refresh again for rectified communication failures/ delayed communications with the central speed net server

This KPI aggregates the number of articles sent as well as number of articles for which the delivery information for the articles have been uploaded on a particular day over a PIN Code. I.e. for each PIN code in catchment area of a Sorting Hub, this KPI reports the number of articles sent on a day as well as total number of articles for which the delivery information has been uploaded. While counting the two numbers, the KPI does not necessitate the commonality of the articles; I.e. the KPI counts independently the set of two articles for reporting. Further the KPI, displays the delivery office against each PIN code.

P a g e | 17

14. Why the delivery information upload efficiency shows the SO Name only, however the delivery has actually happened through the BOs? According to the new Mail Network, every PIN code can only have one delivery office. However the actual delivery may be done through some branch offices. The shown names in the KPI/ report are actually those one Delivery Office Names which is associated with the specific PIN code. 15. Whether all the Speed Post articles are taken while calculating the TD/NTD transit time or not. All the Speed Post article (excluding UID and International) are taken in count while calculating the TD/NTD transit time. 16. What is reason behind the difference in delivery data reflecting in Speed net MIS and on KPI webpage? Speed net articles delivery is a continuous process and the communication of the delivered articles keeps happening to the central server as per availability of the data and communication channels from the fields. There are three reasons for the differences:

1. Types of articles considered for MIS vs KPIs

2. Instance of KPI/ report processing 3. Availability of the reports

Types of articles considered KPI system only considers Speed net articles – excluding UIDs and International Articles; however MIS considers all Speed net articles

Instance of KPI/ report processing The KPIs are calculated every night for D-4 and once calculated for a day, it never refreshes the numbers again. Whereas the communication of an article delivered in past may get communicated to the central server.

The MIS runs on the live server‟s data and always reflects all the activities recorded till the point of time of fetching the report whereas KPIs are calculated at one instance and is never refreshed again a/c to the changes in the central server‟s data. Availability of reports KPI reports are available since October, 2010 and will remain available for ever as it‟s once calculated and stored, however the MIS can‟t be fetched beyond 90 days in past.

P a g e | 18

It is observed that typically the numbers in MIS is higher than the numbers on the KPIs but in cases when the barcodes are re-used/ duplicated then there could be a case when the KPI numbers may go up than MIS.

17. Why less scans are reflecting in raw data whereas track and trace report is showing all the mandatory scans? Please see the below examples Case 1: Article Number: EN042322942IN: It has two scans missing according to the mail which is evident into the track and trace. The first scans which is missing is booking office dispatch scan as is being done by some other office and not from the same office. Second scan which is missing is the Dispatch scan from the Visakhapatnam which closes the bag but fails to put dispatch scan .

P a g e | 19

Case 2: Article number: EN042323231IN: It has got 11 scans reported by hub even and the only missing scan is due to Dispatch of articles from different office than that of the booking office.

P a g e | 20

18. Why does the Leg level transit time for TD/ NTD do not sum up to the average D+x numbers? Core reason of these two numbers never summing up is the way it‟s being calculated. Example: Let us consider just one TD article being booked on Saturday, 18 August 2012 at 10:50 AM in a Post office and delivered on Monday 20 August 2012 by 1:30 PM and the delivery information is uploaded for the same at 5:30 PM. Hence the information recorded against this article is as follows:

ArticleNumber Booking Date DateDelivered D+X (days)

XYZ 8/18/12 10:50 8/20/12 0:00 1

Calculating the D+X for this Article, We‟d get 1 day as there was a Sunday in between

which is a non-working day hence discounted from D+X calculations.

Now let us see the movement of this article from Booking till Delivery and convert the scenario into Leg wise transit time

Date Time Status At Status

8/18/2012 10:50:00 Booking PO Item booked

8/18/2012 14:57:28 Booking PO Item bagged for Hub

8/18/2012 15:22:26 Booking PO Bag Dispatched to Hub

8/18/2012 19:28:00 Sorting Hub Bag Received

8/18/2012 19:28:14 Sorting Hub Bag Opened

8/18/2012 19:28:14 Sorting Hub Item Received

8/19/2012 4:55:24 Sorting Hub Item Bagged For Delivery BO

8/19/2012 4:55:35 Sorting Hub Bag Dispatched to Delivery BO

8/20/2012 8:16:55 Delivery SO Bag received

8/20/2012 8:35:54 Delivery SO Bag Opened

8/20/2012 8:35:54 Delivery SO Item Received

8/20/2012 0:00:00 Delivery BO Item Delivered

Now the Calculation of leg level transit time is calculated as difference in Minutes between successive scans and then convert that minute difference into Days to finally display this on report. Highlighted scans are considered for the leg level transit time calculations:

P a g e | 21

Transit Leg Difference (Minutes) time(Days)

Booking PO Booking to Dispatch 272 0.19

Booking PO Dispatch to Hub Received 246 0.17

Hub Bag receive to Hub Bag open 0 0.00

Hub Bag open to Hub Bag Close 567 0.39

Hub Bag Close to Hub Dispatch 0 0.00

Hub Dispatch to Delivery Office Receive 201 0.14

Delivery office receive to Bag Open 19 0.01

Delivery Office bag Open to Final Delivery 564 0.39

Due to a fault in common practice while loading the delivery info for any article of Not selecting the current time the time of delivery is always loaded as 00:00:00 hours and to factor that effect, the delivery time is taken by default as 6 PM (18:00:00). If we sum up the D+X in the days in this example, it comes out to be 1.3 Days. Few Important points to be noted are, which makes leg level transit time impossible to sum up to D+X: 1. While calculating leg level transit analysis – scan time is considered however while calculating D+x only the days of booking and delivery is considered irrespective of their booking and delivery time stamps. 2. While calculating transit time the operations running over the weekends and even gazette holidays are considered however these are discounted while calculating the D+x numbers.

P a g e | 22

19. Why is the D+x numbers different from D+x number in Transit Analysis Tool?

Basic Assumption


Excel Based Transit Analysis Tool is designed to quickly provide diagnostics of speed post articles and related operations. Only a sample of articles is extracted for this toolkit hence the numbers in Transit Analysis Tool is just the representative; calculated based on the sample set of articles extracted. The KPI on web page considers all the articles for calculating the KPI. Given the case where in unequal number of articles are processed in two different tool kits, there‟s a difference in the numbers of D+x.

20.What does the leg code in the raw data means ? These are the description for the leg codes appearing in the raw data. An article should have following mandatory scans for NTD/TD articles.

FOR PO NTD ARTICLES 111 booking scan

112 dispatch scan 113 bag receiving scan at sorting hub

114 bag opening scan at sorting hub 115 bag closing scan at sorting hub 116 bag dispatch scan at sorting hub

117 bag receiving scan at destination sorting hub 118 bag opening scan at destination sorting hub

119 bag closing scan at destination sorting hub 120 bag dispatch scan at destination sorting hub

121 bag receiving scan at delivery PO 122 final delivery scan

FOR PO TD ARTICLES

110 booking scan 111 dispatch scan 112 bag receiving scan at sorting hub

113 bag opening scan at sorting hub

P a g e | 23

114 bag closing scan at sorting hub

115 bag dispatch scan at sorting hub 120 bag receiving scan at delivery PO

121 final delivery scan

FOR BNPL NTD ARTICLES 111 booking scan

112 dispatch scan 115 bag dispatch scan at sorting hub

116 bag receiving scan at destination sorting hub 117 bag opening scan at destination sorting hub 118 bag closing scan at destination sorting hub

119 bag dispatch scan at destination sorting hub 120 bag receiving scan at delivery PO


FOR BNPL TD ARTICLES 111 booking scan

112 dispatch scan 115 bag dispatch scan at sorting hub 120 bag receiving scan at delivery PO


P a g e | 24

21.What is the calculation Logic of „Delivery PO Efficiency Report‟ ?

Basic Assumption



Articles booked and meant to be delivered in India only are considered

Articles which don‟t have booking information or have been booked before

45 days will not be counted.

Articles having both bag closing and bag dispatch scan from the Sorting

HUB, will only be counted.

Bags despatched from Sorting Hub between 00:00 to 24:00 hours are taken

into account for the calculation of a day/date

Articles sent from a Sorting Hub to a delivery Post Office are taken into

account for calculation of this report

KPI once calculated does not refresh again for rectified communication

failures/ delayed communications with the central speed net server

This KPI aggregates the number of articles dispatched on a particular day as well as number of articles for which the delivery information/delivery attempt/RTS have been uploaded .Also the report takes into account the number of days taken from the receipt to delivery/ delivery attempt/RTS and booking to delivery /delivery attempt/RTS for the articles. D+X split is provided for receipt to delivery/ delivery attempt/RTS for each delivery office. National holidays and Sundays will not be counted for D+X values. If the delivery office is using old or incorrect office code for receiving and delivery information, updation will not be reflected in the report.

faq

Documents