RMCtv : Future of parcel tracking

[claretandblue]

No scanning at frames will mean later start times and longer delivery spans. First class will be sent to DOs as manual but don’t worry about the mail.

Has he ever been right about anything?

[TopperGas]

No scanning at frames will mean later start times and longer delivery spans. First class will be sent to DOs as manual but don’t worry about the mail.

I can't say I'd miss scanning at the frame if it ever occurs, plus if a parcel ever goes missing before it's delivered there would be zero proof it ever reached my frame!

[kazardaimenu]

Yes scanning the parcels and watching the pda wheel spin its cogs is one of the more tedious parts of the job.

[SpacePhoenix]

If anything RM will automate all aspects of MC work, replacing workers with robots and employees will have the option of dismissal or move a minimum of 200 miles to a DO where it will only be a matter of time before they have to work 9pm to 3pm delivering D2Ds 8 days a week including on Christmas Day.

If anything RM will have all delivery staff as owner-drivers with letters being delivered once week by agency. If RM do automate everything in MCs then delivery staff will be spending their WHOLE SHIFT out doing a delivery. Some shifts in MCs are already formed mostly of casuals and do you really think RM would want us in deliveries when they can get new staff on the newer contracts?

Yes scanning the parcels and watching the pda wheel spin its cogs is one of the more tedious parts of the job.

Reboot the PDA either when you collect it or when you head out the office to start your delivery. We get PDAs run slow sometimes, we just reboot them and it fixes it.

I can't say I'd miss scanning at the frame if it ever occurs, plus if a parcel ever goes missing before it's delivered there would be zero proof it ever reached my frame!

With the address encoded in the 2D barcodes, chances are the system will automatically allocate the relevant packets to your walk.

First class will be sent to DOs as manual but don’t worry about the mail.

If you mean mech letters, just 1C on it's own isn't worth starting the machines up, as there's so little 1C these days. A couple of months ago the DTS data got corrupted so ALL the 2C was getting deferred. 16 to 18 boxes worth of mail and we sent out 2 boxes of mail at most banded up.

[Acca Dacca]

I can't say I'd miss scanning at the frame if it ever occurs, plus if a parcel ever goes missing before it's delivered there would be zero proof it ever reached my frame!

With the address encoded in the 2D barcodes, chances are the system will automatically allocate the relevant packets to your walk.


Yeah but right now its scanned in by a logged in user on the PDA so the system can tell who the last person to scan the person was

This system wouldnt

[SpacePhoenix]

I can't say I'd miss scanning at the frame if it ever occurs, plus if a parcel ever goes missing before it's delivered there would be zero proof it ever reached my frame!

With the address encoded in the 2D barcodes, chances are the system will automatically allocate the relevant packets to your walk.


Yeah but right now its scanned in by a logged in user on the PDA so the system can tell who the last person to scan the person was

This system wouldnt

It can easily do it. When the york or sleeve of packets enters your DO, the system automatically flags all the packets scanned to that york or sleeve as having arrived at your DO. Doesn't take much to tweak the system to look at the data on Route Planner to determine which walk each packet is proper to and allocated the packet to that walk

[Acca Dacca]

But the parcel wont ever be confirmed to be physically in the postpersons hands

The system automatically scanning before the item gets to the frame can confirm that walk X SHOULD have it but it cant confirm they DID have it

Right now the system knows who the last person to manually scan the parcel is because the PDA is logged into the user when we scan to core route. This system wouldnt.

[yellowbelly]

But the parcel wont ever be confirmed to be physically in the postpersons hands

The system automatically scanning before the item gets to the frame can confirm that walk X SHOULD have it but it cant confirm they DID have it

Right now the system knows who the last person to manually scan the parcel is because the PDA is logged into the user when we scan to core route. This system wouldnt.

Also, in our office when we have a van route that covers the oversize for a walking route, the walking route OPG scans them to their PDA core route even though they're oversize and not going to be able to deliver them. The walking route OPG sees any in-flt's and actions them accordingly. The van driver then grabs those that are due out when they've bagged up their walk ready to go.

So who had the parcel last?

Also we've never been told if this is actually correct ie. that the walking route OPG scans them rather than the van driver for the oversize.

[Smoothbackground]

Containerisation has the potential to save lots of money.

One example where it could make efficiency. Packets and parcels could be sent to DOs already sorted down to walk level and scanned into a single container, York or Amazon-type tote for each walk so that they are ready for delivery without any further need to scan any of the contents. The postie would only have to scan one barcode on the York/container for the PDA to generate a delivery manifest for everything within the York. One competitor (and customer) has been doing this for years.

That would require every MC to have a packet sorting machine, it's not practical for that to be done manually. We've probably for 600-700 walks across all the DOs in our area. That's a lot for people to know where every road is and what walk that road is on for the whole area covered by the MC. I don't know if the packet sorting machines already in place in MCs would have enough outputs so it might mean that some packets would have to go through multiple times. The first time the outputs would be the busiest walks, the next time would be the next busiest walks and so on. You'd need all the packets to have arrived in the MC from the outward MCs and the hubs before you could run everything.

I don't know if the class of mail is encoded in the 2D barcodes on the packets but if it is, I wonder if they could compile that data from the outward MCs to create a list of delivery points due a packet for delivery. That data could be fed into the DTS system to release any mail for a delivery point which is due a packet delivery.

Anyone work at a MC that has a flat sorting machine? Do you do any sequencing on the flat sorting machine?

Yes, it would definitely have to be an automated process, like you say, as it would be impractical to do it manually.

[TopperGas]

But the parcel wont ever be confirmed to be physically in the postpersons hands

The system automatically scanning before the item gets to the frame can confirm that walk X SHOULD have it but it cant confirm they DID have it

Right now the system knows who the last person to manually scan the parcel is because the PDA is logged into the user when we scan to core route. This system wouldnt.

Also, in our office when we have a van route that covers the oversize for a walking route, the walking route OPG scans them to their PDA core route even though they're oversize and not going to be able to deliver them. The walking route OPG sees any in-flt's and actions them accordingly. The van driver then grabs those that are due out when they've bagged up their walk ready to go.

So who had the parcel last?

Also we've never been told if this is actually correct ie. that the walking route OPG scans them rather than the van driver for the oversize.

The company must surely be the van driver scans the parcels, otherwise the customer is getting a message to say it's being delivered within one time frame when it's being delivered in a different one?

[yellowbelly]

But the parcel wont ever be confirmed to be physically in the postpersons hands

The system automatically scanning before the item gets to the frame can confirm that walk X SHOULD have it but it cant confirm they DID have it

Right now the system knows who the last person to manually scan the parcel is because the PDA is logged into the user when we scan to core route. This system wouldnt.

Also, in our office when we have a van route that covers the oversize for a walking route, the walking route OPG scans them to their PDA core route even though they're oversize and not going to be able to deliver them. The walking route OPG sees any in-flt's and actions them accordingly. The van driver then grabs those that are due out when they've bagged up their walk ready to go.

So who had the parcel last?

Also we've never been told if this is actually correct ie. that the walking route OPG scans them rather than the van driver for the oversize.

The company must surely be the van driver scans the parcels, otherwise the customer is getting a message to say it's being delivered within one time frame when it's being delivered in a different one?

Even if the driver did scan them, some of the drivers do them all at the start (especially on a Saturday - catch more people sleeping in), others do them at the end (of their own walks), depending on what SD's they've got on their own walks too. The paired 'van with oversize' and HCT duties are totally separate unlike van share. No definitive guidance.

[Mr Rush]

otherwise the customer is getting a message to say it's being delivered within one time frame when it's being delivered in a different one?

We had four walks on a route header (long story) and the notifications going out for the last duty were declaring delivery times beyond LATs. Nothing was done about it for almost two years. There is a total disjoint between what emanates from the ivory tower and how things actually operate at the coalface.

[norris9]

Would be nice if we could just scan a barcode on a york with our duties parcels on it and it uploads all the parcels in one scan.

[SpacePhoenix]

Would be nice if we could just scan a barcode on a york with our duties parcels on it and it uploads all the parcels in one scan.

It should in theory be able to grab that data from the data generated by us scanning them to yorks in the MC. I just needs for all DOs to make sure that the data in Route Planner for all their walks has been updated and is kept up to date.

RM must be adding data for each walk for which day is the 2C delivery day, so the CSS machines will know on what days all 2C and by the looks of it most DSA will get deferred. If a DP has got a 1C item on a non-2C day I don't know if it will release it or hold it, there's the potential for a rapid build up of 2C. They've not yet told us what will happen if the built up 2C gets beyond what we've got the capacity to run during the shift, as it stands it'll probably reach a point where we'll have to send some out as manual as if it's not been deferred by the DTS system, we're not allowed to hold it.

[norris9]

Would be nice if we could just scan a barcode on a york with our duties parcels on it and it uploads all the parcels in one scan.

It should in theory be able to grab that data from the data generated by us scanning them to yorks in the MC. I just needs for all DOs to make sure that the data in Route Planner for all their walks has been updated and is kept up to date.

I know nothing about how Royal Mail's systems work, but that to me sounds like something basic...

I can only assume they do not do it because parcels can go missing between MC and DO. If I scan my walk and all my parcels that have been scanned at the MC appear, but some of those parcels are missing from my york, then Royal Mail are less likely to know where a missing parcel has got to, or might accuse the duty holder of losing the parcel....

I guess Royal Mail would have to weigh up how much time this would save a postie each day versus how many more parcels may disappear and be harder to locate.

On the face of it - with it saving ~5 minutes a day per postie nationwide...that's a lot of time saved, so surely it's worth doing, or at least trialling.