The speed in which Royal Mail Manifest filing is too slow. It takes up to three to five minutes to generate. It is not ideal when you are in a rush to print a manifest minutes before the collection driver comes.

We have used Veeqo before, and the time it takes to generate a manifest takes three SECONDS! I hope that Linnworks will take this feedback onboard to improve this, and learn how it can be possible to generate a manifest in a number of seconds, rather than minutes.

I understand that it is very much down to the API, but if Veeqo made it possible, perhaps there are other solutions in which Linnworks can also implement speeds as fast as that. I am not sure what parameters/variables are available in the API, but perhaps Veeqo do it by way of creating their own template and only relying the API on fetching unique details required in the manifest, saving time to generate the order.

I have spoken to a support agent and she said it depends on the amount of orders we attempt on generating. However, I just tried to manifest one single order after manifesting 30 orders and the difference in timing is the exact same.

Please get the generation of manifests down to seconds rather than minutes!

Whatever API access/permissions you have with Royal Mail should be the same as Veeqo's.

Any chance that you could look into how Veeqo manages to generate manifests in seconds?

There must be a way. Have fun problem-solving!

Hi Boris, 

Just to give a little more detail to what Anton has mentioned - 

There are a few other areas that cause a delay for this. Over the years our database has grown a considerable amount with the data we are storing. When processing the manifests it's necessary to search the data for the appropriate orders and information. Due to the vast volume of data we need to search through it causes a bottleneck of processing time. 

We're currently working on a solution to eradicate the delay from the data retrieval part of the process which is what we believe is causing the biggest delay which we are expecting to be in place towards the beginning of Q1 2020.

As part of doing our performance testing for this we'll also take a look at what other areas are causing slowdowns to see how we can improve those. 

I can appreciate that the delay must be a little frustrating especially coming from a product  where that delay was non-existent, but rest assured we're working on it as one of our priorities!