A possible bug in the new Feb 20, 2024 release of Square for Restaurants

[brian_a]

I would like to share an issue I found in the new Feb 20, 2024 release of Square for Restaurants in case others have found workaround for it. If not, at least you are aware of it and can cope with it with no surprise.

Issue Summary
A Modifier created with 'Customer can only select one modifier' checked and customized to have a pre-selected choice will produce a confusing message on Square KDS ticket and receipt when another choice is selected.

In short, modifier pre-selection feature in the customize screen it broken. The pre-selected option, even if unselected, will continue to show up with a prefix 'No' on the receipt and the kitchen ticket.

I have confirmed that the older (current) version of POS does not have this problem. I only see this problem when I enabled the Feb 20 version. Once I reverted to the old version, the problem goes away.

The only workaround I have found is to NOT set a pre-selected modifier. This adds unnecessary friction to the customer experience.

Steps to reproduce:
1. Create a Modifier in Square Dashboard
Name: Spicy Level
Choices: Not spicy at all, Spicy Level 1, Spicy Level 2, Spicy Level 3
Check the 'Customer can only select one modifier'

Leave the 'Use Conversational Modifiers on POS' unchecked.

2. Add this modifier to an item (e.g. fried rice.) Then customize the modifier attached to this item to pre-select the 'Not spicy at all' option.

3. Add the fried rice to a transaction on Square for Restaurants. The 'Not spicy at all' option is pre-selected as expected.

4. Tap another choice (e.g., Spicy Level 1.') The new Square for Restaurants will now show two choices:
[No Not Spicy at all x] [Spicy Level 1 x]

The 'Not Spicy at all' choice that is now unwanted is still shown in red with the prefix 'No.' Both choices have a little x mark next to them but you can't remove the first one. If you touch the first one, it will come back to being selected and the second one will disappear. If you touch the second one, it will disappear but the first one will still be left in red (unselected.) The system will ask you to 'Choose 1' still.

The KDS ticket and the customer receipt (electronic or printed) will show:

Fried Rice
No Not Spicy at all
Spicy Level 1

The 'No [label of the now unwanted choice]' is very confusing to the kitchen staff. Asking them to simply disregard it is not an effective option and may result in wrong orders being made.

Expected behavior (as in the current version:)
Tapping another choice remove the pre-selected choice completely on the screen and printed ticket/receipt.

[Donnie-M]

@brian_a I would try just adding the modifier set and not checking the box "customer can select only 1" under the modifier creation.

I would then go to the item and click the three dots to the right and "customize" the modifier and select minimum 1 choice and maximum 1 choice and this will do away with the pre-selected first modifier and should eliminate the "NO" showing up.

[brian_a]

@Donnie-MThanks for your suggestion. I tried it and still have the problem. I also tested a couple more scenarios and came to a conclusion that pre-selection of modifier is simply broken. If you have any modifier customized as pre-selected, unselecting it will leave it on the ticket with the 'No' prefix. It doesn't matter how many choices you have set as pre-selected or the min/max number of modifiers allowed on the item.

Steps to reproduce:
1. Create a Modifier in Square Dashboard
Name: Toppings
Choices: A, B, C, D (for simplicity of this demonstration)
Check or uncheck the 'Customer can only select one modifier' (it actually doesn't matter to the issue being discussed here.)

Leave the 'Use Conversational Modifiers on POS' unchecked. (I didn't test turning this on as we don't use this feature. It is also irrelevant to the issue being discussed here.)

2. Add this modifier to an item (e.g. ice cream.) Then customize the modifier attached to this item to have:
Required Modifiers = 0

Maximum Modifier = 2
pre-selected is checked on choice A and B.

3. Add the ice cream to a transaction on Square for Restaurants. Choice A and B are pre-selected as expected.

4. Try changing the default toppings A and B to C and D.

The kitchen ticket will print as:
1 x Ice Cream

      No A

      No B

      C

      D

There is no way to remove the default option A and B without having them printed with the prefix 'No.'

The above ticket may seem acceptable and easy (enough) to understand. But imagine this ticket:

1 x Ice Cream

      No No Nut

      With Nut

Where the 'No Nut' is the default choice that is now not selected. It takes a bit more cognitive cycle of the kitchen staff to make sense with the order. Imagine you have 20 of these on your ticket rail.

I hope someone from Square read this and help fix this bug, as it doesn't exist in the current version that will be with us 2 more days.

[JJ_]

Hey there @brian_a 

I am sorry to hear about this experience. I went ahead and escalated this over to our Restaurants Team. As you may know, it is a holiday weekend, so I hope to hear something by Tuesday.

[brian_a]

Thank you so much JJ_. I hope they can find a solution quickly and that the solution benefits others too.

[brian_a]

FYI to those who use a similar set up; Square has moved the forced update date out to March 5. So at least I can stay with the current version for a bit longer and hope that Square fix this impactful bug in time.

[JJ_]

Hello there @brian_a

I got a response from our team, and I'm sharing it here for the visibility of everyone affected by this behavior. 

"This is working as expected, but we'll think about feedback and how we could incorporate it. We can't change this behavior now though because many sellers have come to expect the No prefix to get added when pre-selected modifiers are removed (e.g. if you say "no cheese" on a cheeseburger). For the seller's examples, like No No Nut, we'd recommend using Conversational Modifiers rather than having a modifier called No Nut and With Nut."

I hope this information is helpful, and you're welcome to provide any additional feedback here!

[brian_a]

@JJ_Thanks for following up on this matter. A point I would like to emphasize is that this 'bug' doesn't exist in the current version (I am using 3.36.2 on iPad.) So, I am not sure when your team said that many sellers have come to expect the 'No' prefix as a feature, did they mean these sellers have just learned to use it with this brand-new UX or they referred to the existing version. I ask because this 'No' prefix behaves differently between the two versions. Let me elaborate to ensure that this behavior change is intended by your team and not a bug.

In the current version, if a modifier list has choice A pre-selected, and the list is set to only allow 1 selection, when I select choice B, B will completely replace A (A is gone from the POS screen, KDS, and printed ticket.) But if I intentionally unselect A (by tapping it) before selecting B, the 'No' prefix will show up on A. So I will now have [No A] [B] on the screen, which is not what I want. With that, I have trained my team members to not unselect A first. Since that is a shorter flow (one tap vs two,) it feels natural to users to follow that instruction.

In the new version, when I select B to replace A without explicitly unselecting A first, the [No A] will show up regardless. This is the key difference between the two versions. There is no workaround or an alternative flow I can train my staff to avoid the [No A]. So, for sellers relying on this 'No' prefix as a feature, I am pointing out that its behavior has now changed and it might impact them too.

My ask here is for Square to make this 'No' prefix feature works the same way as it does now, unless there is a new business reason or new use case(s) that call for this behavior change. If that is the case, I'd like to learn more about them so I might adapt to the new flow as intended by your design and/or engineering team.

As for the suggestion on Conversational Modifiers, I opted not to use it as it doesn't allow me to set different prices between the no, with, and extra choices.

To give you a better context for my real use case, I have a modifier set called 'Egg Options' with the following choices
- With Egg -> Pre-selected
- No Egg

- Extra Egg (+$1.00)

I pre-select the first one because 90% of my customer will select it. So I save a click/tap (both on POS and Square Online.) If this new 'No' prefix behavior is to stay, a workaround is for me to not to use the pre-selection feature at all. But that will add friction that doesn't exist today.

I hope this helps me and others on the Square platform.

[brian_a]

I did some more testing today on the current version of the app (not the upcoming new UX) and would like to provide an additional observation in case it helps Square team.

- The 'selecting B will completely replace A' behavior described above would only happen if the modifier list is configured to allow and require exactly one selection (either with the 'Customer can only select one modifier' set to true OR the modifier attached to an item is customized with both the Required Modifiers and Maximum Modifiers set to 1.)

- If you set this min/max number to any other values and also have some choices pre-selected, the 'No' prefix behavior will happen to the pre-selected choice(s.)

I can still live with the current behavior as described above if Square would be so kind to bring it over to the new UX version coming on March 5.

My suggestion to Square for the long-term fix, without breaking the sellers that have come to depend on this 'No' prefix, is to add a configuration option to allow each seller to choose the behavior.

For example:
'Pre-selected modifiers will show up with a 'No' prefix when unselected' [Yes/No, defaulted to Yes]

This way it doesn't matter how many choices I have pre-selected. I can choose to either have them removed totally when unselected, or to be kept on the screen/ticket with the 'No' prefix.

I hope this helps.

[JJ_ · Accepted solution]

Hello again @brian_a. I hope your day/week is going great!

I just heard back from the Restaurants team, and I am happy to tell you that they have decided that your feedback was very much needed to understand the behavior, and they will make sure to correct this in an upcoming update (don't have a concrete timeline). 

Thank you for your great feedback here. I will also make sure to pass on the most current feedback as well. 

[brian_a]

Thank you @JJ_ This is good news. I will wait for the fix then.

[brian_a]

I figure I close the loop on this in case someone read this later and wonder what actually happened. The fix that @JJ_ mentioned above finally showed up on Square for Restaurants and also the app on mobile POS (used on Square Terminal) as well. So now the modifier behavior is the same as that of the previous versions I referred to in the original post. Thx Square for the fix.