Improve defining delivery area for Square Online

[mikemayfleets]

We need a better way to define delivery area in Square Online.

Our delivery areas don't work with radius since the areas are normal rectangular. A radius either cuts off service to the corners or, if we expand the radius to support the corners of the delivery area, the radius includes large areas where we don't what to deliver. 

Postal code sort of works.

The FSA (first three characters of a Canadian postal code) is too large and almost always generates more area where we don't want to deliver in, than our desired delivery area.

LDA (the full six character code) needs hundreds of LDA codes to define a service area. 

• The current postal code field does not allow a batch paste of postal codes, so it's extremely error prone and difficult to enter all of the  LDA codes needed to represent a delivery area. 
• Ideally, we can paste a CSV list into the field - but that does not work.
• Alternatively, a batch upload of a CSV file would be useful. ... but it does not exist either. 

What are the recommendations from the product expert to build a precise delivery area?

[isabelle]

Hey @mikemayfleets! ⚡️

Thank you so much for leaving this feedback. We are tracking insights related to the delivery radius (including the postal code) with our Product Teams. While I do not have any updates to share in regards to development or update releases, perhaps @Provision may have some insight or workarounds to share in the meantime? 

[Provision]

@mikemayfleets 

Thanks for the tag @isabelle . When we were using deliveries, the circle radius always worked for us but I do see where some businesses may not want to delivery to.

It's not ideal but you can always have an announcement, shipping FAQ page, or description stating you only deliver in certain area. If you get any orders other then the shipping area, you can always refund but I can also see the downfall to that as well.

[mikemayfleets]

Hi @Provision ,

Thanks for responding. 

Our ultimate priority is focused on order boundaries, not delivery boundaries. We want the system to only accept orders from a specific geography. 

Customers are hungry when they order from us. They review a menu and make food and drink choices. Nothing is worse than setting expectations and then calling them to say - we can't deliver. That does not build a good brand. 

Our service areas have "optimized" geography because we run mobile restaurants. there are areas that meet our household and business revenue/employee count criteria. Our routes look more like corridors with occasional larger service area - similar to a river/lake/river perspective.

So, we use our truck routing/management tool to generate polygons to represent service areas.

Radius might work in a "lake area" but event those are normally not symmetrical shapes.

Postal codes can approximate our service area, and our mapping tool will output all of the postal codes in a "territory" that we can draw using the polygon as the foundation layer. The mapping software generates a list of postal codes (at the LDA - 6 character level) but ... Weebly does not allow us to upload a list of postal codes.

So, within the current functionality - allowing us to upload a csv or some other formatted list of postal codes is a workable solution.

The better solution is to allow us to upload a geospatial polygon, which will give precise order geospatial boundaries.

I have built complex geospatial systems and working with polygons is very easy. An address is converted to a centroid (standard function) and the centroid is either in, not NOT in the polygon. Done - the simplest way to determine if a customer order can be taken with a promise to deliver. 

Hopefully the product management team sees this and can assess if the feature adds value. 

Feedback is gladly accepted.

Mike