Yesterday, we landed a new customer who ordered via our trade store however we had to get back to them saying we could not fulfil the order because the order contained 1 keg and 2 cases, the weight being 64kg. The delivery charge shown was £22.50, which would be that if the order of that weight was only cases, which we send through APC, however, because it included one keg we would have to send it via palletways which starts for £50-£60, a significant jump. We had to alter the order and risked losing this newly gained customer, we’re still unsure whether they will reorder because of this customer experience. Could there please be a way to set this up BOH that if an order contains a particular product, ie. a keg it charges X.
I raised this when we first set up our delivery structures but it was dismissed and it’s been a frustrating issue ever since, I’m sure we’re not the only brewery that would benefit from this.
It also takes a lot of manual work to edit delivery charges (ie. prices going up) if this could be streamlined that would be fantastic.
Thanks for posting this suggestion here. This is the perfect place for suggestions like this. I remember the previous conversation that you are referring to and I’m sorry you felt that this suggestion was originally dismissed. That’s never our intention and we do absolutely want to help solve this, in order to make Breww work better for you.
Part of the difficulty of this suggestion is how to fit it into the existing structure, adding in as much flexibility as possible, but without making it all so complicated (or lengthy) that it’s too difficult to create delivery charge structures in the first place. We would really value your feedback and ideas on how this could be implemented.
Simply adding a new field named something like “Alternative price to charge if the order contains a keg”, feels too specific to your use-case, and if we go down this route, over time there’ll end up being huge numbers of extra fields and the whole feature will become to complex.
I’m thinking this could be implemented with something along the lines of:
- On a delivery charge structure, you can add some “rejection rules” and pick another delivery charge structure to use if any of the rules match. An example of a rule could be “At least [x] products of [container type list]” are in the order (in your case “At least 1 product of keg container type”). There could be other rules too, such as “At least 3 products have the ‘Core’ tag”, or “Total weight of order over 30kg”.
- If any of the rules applied, we would switch to instead use the alternative “fallback” delivery charge structure. This fallback delivery charge structure would have to have already been created in order to be chosen.
- You could add rules and a fallback delivery charge structure to the fallback delivery charge structure too, which would allow you to keep “falling down” through different structures until one matches. Ultimately, if none of the structures match, the delivery would be free.
At the moment delivery charge structures, can be picked on the customer/customer group/type/etc level and the above suggestion would mean that this was still the case, you’d just want to pick the one at the “top of the tree”.
What are your thoughts on this proposal? Do you think this would work for your use case, and wouldn’t be too complex to use? If you have any alternative suggestions, please do put them forward, as we want to build something that works well for you.
I’m also linking this to Deliveries By Weight as the two could be implemented concurrently, as they’re very related.
Thanks for raising this moonwake, this is something we’ve been looking at recently, and trying to figure a way to use the automated delivery charges within breww, but find it tricky to do so due to some of the issues described above.
Luke -
We have a similar experience with kegs, with one of our couriers we can send lightweight non-returnable kegs (e.g. keykeg/polykeg), but cannot send metal kegs (e.g. kegstar), and these then have to go onto a pallet which is a different cost structure. Sorting this by weight doesn’t work as say 5 cases may weigh more than one metal keg.
At the moment we are managing delivery costs as Service Products, but would like to move away from this if possible as things can be missed.
Also, geographically there is generally a pricing difference, such as sending goods into London, or internationally, and there does not seem to be a way to automatically do this. (I think there might be a thread on this elsewhere, but I can’t seem to find it)
Being able to implement rules as you’ve described above should work. I think we would need to be able to implement rules around:
- Container Type
- Number of Items
- Location (Outward Code maybe?)
- Whether or not it is international/export
- Courier (e.g. is this DHL or APC, and if so use X pricing structure)
Also, something that sort of falls into this area - Do Not instructions can be difficult to manage - e.g. if a customer could not accept pallet deliveries due to access issues, but managed to formulate an order that would require a pallet, it doesn’t flag up until dispatch stage (e.g. showing up on the Delivery Note/Pick List.etc), potentially resulting in a further call to the customer down the line to resolve.
1 Like
Hi Luke, thank you for getting back to us on this. I think that could work. Would it work automatically when a customer ordered via the trade store or us putting it in manually?
We have a different structure for every palletways area
2 Likes
Up to 150kg it’s APC pricing, then palletways pricing (this does allow for small keg orders to slip through as I described above but hopefully we’re getting a solution)
1 Like
Presumably you’re manually choosing the zone?
Yes, we allocate the zone when we set them up as a customer, before giving them access to the trade store or putting in their order
2 Likes
Thanks everyone for your comments on this, it’s all really useful insight.
Given the number of options here and the number of delivery charge strictures that have been set up already to try to cover all the bases (manually), I’m not quite sure if my above-proposed solution will be manageable. I fear it might be too complex to be readily usable. We’re going to have a brainstorm on this as a team and get back to you with our thoughts.
Thanks again for all the input, this is exactly what we need to build the best possible solution 
