Basic Functionality Missing

vinreapervinreaper Member Posts: 2

Basic Functionality Missing

SALES

1.      Quantity of items being sold - There should be a running quantity (total units) at the bottom of the sales window for a user ringing a sale. We should not have to count the items on the screen to be sure how many were entered.

 

2.      New Sale Button - A new sale should not automatically open. Within a sale window, there should be a 'New Sale' button to trigger a transaction window to be generated and a Transaction ID assigned, for all users. Currently, anytime a sales associate logs-in with a PIN, to even check inventory, a new sale is generated. The Button should be located on the same line as the ‘+New’ (New Customer Button), ‘Loyalty’ Button, ‘Misc’ Button and ‘Gift Card’ Button.

 

3.      Transaction ID - When a new sale is open, the Transaction ID number generated should appear at the top left of the sale window.

 

4.      Cancelling a Sale - When you cancel a sale, Lightspeed requires a PIN sign and then automatically creates a new sale. Would be fixed if 2nd item is rectified.

 

 

5.      Gift Card Purchasing or Using - Gift cards should generate cost, not just create a zero in and zero out. Please see Lightspeed ONSITE. Much more efficient way to tabulate and better for accounting purposes. A Gift Card is a product as well. Not just cash. A customer purchasing a gift card should be able to earn points for their purchase. The Recipient of the Gift card should not receive Loyalty Points from its use. They can sign up for the Loyalty program themselves once they purchase a product without a gift card. This would incentivize people to buy Gift Cards as gifts.

 

6.      Authorization Code Field – A Field for logging Credit Card Authorization Numbers from External Payment processing station should be within the payment window.

 

7.      Special Orders & Quotes - Again, as in ONSITE, Special Orders and Quotes are not included in DAILY TRANSACTIONS unless they have been Invoiced and Paid for on that day or have received a deposit on that specific day.

 

8.      Special Orders Designation – A Special Order Designation (e.g., SPO) should be shown next to any Item that is tied to a special order. It should be shown on the Inventory search page in a column next to the specific item as well as with the item’s page itself. It should be clickable to take you to that specific SPO and able to be edited or invoiced from there.

 

9.      Multiple Discount Fields for Items and Customer Types – Items should be able to qualify for multiple discount types and customers should be as well.

 

o  E.g. We have a First Responder Discount for multiple products.

§ First Responder Discount Wine 10%

§ First Responder Discount Spirits 5%

We are unable to add both to a customer profile since we are only allowed one entry.

 

INVENTORY

1.      Additional ‘Searchable’ Fields – We are a fine wine shop. The vintage and size of a particular product is crucial to us on a daily basis. There must be a field with each product that is fillable and searchable for these specific traits.

2.      Searchable Tags - All tags created must be searchable in the inventory search field of RETAIL and ECOM.

 

3.      Entering Tags – Tags should only be entered in the Tag Page (Inventory > Settings > Tags). Here is where tags should be created. It would be easier and more efficient. The Tags would not be in danger of duplication. After which, with in each individual product, the ‘Tag Field’ should be a drop-down window containing all Tags that were created on the Tag Page. The User could then choose all tags in this window that apply. If a tag did not exist, the drop-down window can have a ‘create new link’ button, which would take them to the Tags Page while simultaneously saving any data that was created in the new item before changing pages. These Tags would make it easier as well if they were propagated to the ECOM as well.

 

CUSTOMERS

1.      CUSTOMER TYPE - Again, like in ONSITE, I should be able to choose what type of customer they are "Individual" or "Corporation". Currently Corporate Accounts cannot be listed in main customer window.

 

2.      CUSTOMER ID - We need to be able to search by ‘CUSTOMER NUMBER or WORD’. Currently, after the Migration by DOOSYNC, the customer ID numbers from ONSITE transferred over into a field called ‘CUSTOM’ within its respective customer window. This number must be able to be cross populated to the Loyalty Program customer list for seamless access in any window be it RETAIL, ECOM or LOYALTY. This way a user can quickly find a customer solely by entering the specific code in any customer window. These codes can be any combination of any alphabet or numerical characters. (e.g., 1234, 1A2A, BSMITH1, ILUVWINE, or anything else)

a.      Customer ID numbers be should not be able be replicable. A prompt should occur stating that this CUSTOMER ID is already taken.

 

3.      CUSTOMER DATA - All data should propagate seamlessly between RETAIL, ECOM and LOYALTY. I should be able to access SPECIAL ORDERS, QUOTES, and all past and current TRANSACTION for any customer from any entry point.

LOYALTY

·        Question: Within Loyalty. (Loyalty > Edit Customer Information) there is a blank field at the top right of the individual customer’s screen. What is it for? Is this for, or could this be used for, the assigning of a CUSTOMER NUMBER or WORD as we discussed above.

 

I will continue to add to this list as I find more basic needs. We have only been using Lightspeed Retail for 2 days but have been using Lightspeed ONSITE for 11 years. There was a lot of concise functionality in ONSITE that should be transferred over to RETAIL. Especially when it comes to the back-end accounting.

 

3 comments

  • BEVVBEVV Member Posts: 27

    Why didn't anybody at Lightspeed respond to this post?

    We used Onsite for 13 years and have just finished our first year with Retail - a far inferior product to Onsite.

  • Xela_TXela_T Member, Lightspeed Staff Posts: 5 Lightspeed

    A post this detailed certainly deserves a reply, especially since there are some very good points being raised.

    Of note, Onsite and Retail are certainly different products with different advantages, but in some cases Onsite has a unique advantage of having all user data and computations be stored and performed on the device rather than in the cloud. That being said, here's how some of the feedback has and will influence our product in the coming years.

    1. Quantity of items being sold: Completely agree! Unlike the iOS app, the WebPOS doesn't have a handy unit calculator. Some users have created browser extensions to do this, but ultimately this should come from us. There is a lot of real estate in the register we can further leverage.
    2. New Sale Button: A lot of customer feedback centers around transactional speed and reducing clicks to checkout, which is the reason we start a new sale for the user.
    3. Transaction ID: Completely agree once more. We make this information visible in the service section of the app and have plenty of room to display a transaction ID.
    4. Cancelling a Sale: Same idea as #2. The PIN isn't required to cancel the sale, but rather to assign the employee to the next sale. User can cancel a sale and walk away to assist another user, and if a different employee walks up to the shared register, the PIN screen is available to identify them.
    5. Gift Card Purchasing or Using: Can't agree with you on this one here and have to align with common accounting practices. Gift Cards are an exchangeable payment option and not a sale, item or source of revenue, therefore we only recognize the collection of funds when purchasing a gift card, so that you may map the gift card to a liability account rather than a revenue account.
    6. Authorization Code Field: This one is a bit more difficult to do in a cloud system while maintaining compliance. One of the aforementioned advantages of an on-premise system, you are responsible for your own data. There have been quite a few requests to facilitate the storage of CC information and we are exploring different options that can provide this service while also protecting user data and privacy.
    7. Special Orders & Quotes: I'd have to dig into this one a little more to see if we can further provide visibility on Special Orders and Layaways. For Special Orders, we have a dedicated listing in Inventory / Special Orders. The transactions relating to those actions are captured in transaction reports, but deposit collection, similar to Gift Cards, cannot be recognized as revenue until complete (or redeemed) and the money collected cannot be confused with sources of revenue typically shown in the Totals or Lines reports.
    8. Special Orders Designation: I'll set this one aside for design to review and see if there is any additional visibility we can provide on Special Orders in a searchable listing. Currently, you can see that an item is on SO by either: Navigating to Inventory / Special Orders, or Navigating to the item details page and viewing the Special Order tab, or adding the item to a transaction and having the warning banner let you know this item is already reserved for another customer.
    9. Multiple Discount Fields for Items and Customer Types: We typically receive opposite customer feedback regarding discounting and protecting transactions from runaway discounting. That being said, while it would be significant lift development wise, I do agree that there should be increased flexibility discount wise, similar to how eCom platforms can usually accept a discount code in addition to a preplanned discount rule. We will consider this one to prioritize in the coming year.
    10. Additional ‘Searchable’ Fields: I completely agree with you on this one as well. While we technically can make every field searchable, in order to return results as quickly as possible, we do purposefully limit the extent of the search. I'd love to make custom fields searchable in order to unlock workflows we didn't preplan when creating the core searchable fields. Will discuss with engineering to prioritize in the coming year.
    11. Searchable Tags: Unlike Retail, these fields do not sync to eCom and as such are not searchable, which I agree is a missed opportunity. While I can speak for products other than Retail (R-Series), I do know this is a requirement for our new synchronization with Ecwid (E-Series) and may also be one day added to eCom (C-Series).
    12. Entering Tags: A hundred times yes! As a retailer myself (custom bike shop), we leveraged tags significantly to quickly find the right product for our customers. The only drawback was my partner and I had differently sized fingers it seemed and often duplicate tags were created and as such interesting variations on common words (steel, steal, steele, etc.). As such, we've taken this feedback along with many others and recently updated our tag field to specifically address these concerns, without having to navigate to a separate page. When you start typing a tag that already exist, we will allow you to auto-complete the entry without risking mistyping. Hope this helps!
    13. CUSTOMER TYPE: Another point we agree on! That being said, whether a checkbox like in Onsite is the solution remains to be determined, but in any case, being able to see the type of customer you are serving without navigating away from the register screen should be a priority in helping reduce checkout friction. Consider this added to our backlog to be prioritized.
    14. Searchable Customer ID: We usually abstract the custom ID as we create a sequential ID that is really only relevant to us and our database, however, should you want to record your own customer ID, or have one coming from a different system like Onsite, then the filed name CUSTOM is the perfect place to store that info as it is searchable. The professional sports teams that use Retail in their arenas/stadiums leverage this field in order to provide season ticket holders with a barcode they can present at any checkout counter to be scanned and quickly identified. As for the sync with Loyalty and eCom, I agree, and while the intent of the field isn't to necessarily record a customer ID, the more info the better. That being said, we cannot enforce data uniqueness as others may be using this field for different purposes.
    15. CUSTOMER DATA: Once again, I agree. I will argue that the information is never too far away (likely in the other browser tab), but anything we can do to save time and reduce friction, we should.


    Thank you so much for your post. It spawn great discussions with our engineering and design teams, and some of your feedback is either already on our roadmap or will be injected into our backlog to prioritize and refine.


    Alex - Product Manager

  • BEVVBEVV Member Posts: 27

    Hi Alex - do you know how soon this will be addressed? I look at it as a "loss prevention" issue - as the LS scanner will beep but not add an item to the sales window...so we have to count the number of items being put into a bag & then use our fingers to count the lines in the sales screen - very inefficient, time consuming & subject to error.


    "Quantity of items being sold: Completely agree! Unlike the iOS app, the WebPOS doesn't have a handy unit calculator. Some users have created browser extensions to do this, but ultimately this should come from us. There is a lot of real estate in the register we can further leverage."

Sign In or Register to comment.