Login  Sign up

June 2017 Release | Build 2.6.4


Lead Time Rules

ShopperKit understands that not all orders are created equal. Certain items that your customer’s order are inherently more complex to fulfill than others. A large catering order may require sourcing and advance preparation of items. Bakery items may require multiple preparation steps at specific prescribed times. Hot food items shouldn’t be picked until the last possible moment. Previously, these types of orders required a fair amount of manual intervention and oversight to effectively manage, which is why we’re pleased to announce the introduction of Lead Time Rules.

With the new Lead Time Rules functionality, you will be able to define specific monitoring rules that ShopperKit will use to alert users on based on several possible order item conditions to be evaluated at set number of minutes before the orders promise time (i.e. email the catering department and store manager of catering orders that are due in 48 hours).  


When defining rules, you will begin by defining the name and description of the rule as well as how you would like ShopperKit to alert you. You may choose to have ShopperKit proactively alert users by sending emails and/or text messages, and you may also choose a more passive alert and instruct ShopperKit to flag the order and items in the app with a custom Lead Time Rule alert color icon. For SMS alerts, you will define the message that you would like ShopperKit to send. For email alerts,


ShopperKit will send an email that lists the specific order items that triggered the alert.

Color alerts will be displayed (up to 3) on the Order and Prepared Order list views as well as on the individual order items in the Shopping, Preparation and View Order screens. Alerts will be displayed until the order item has been picked.


At minimum a Lead Time Rule must have one alert behavior (email, sms or color), a Minutes From Promise Time parameter (when to alert) and at least one rule evaluation criteria (Item Category, SKU, UPC and Location), though rules can also be made very granular by defining specific combinations of evaluation criteria.

Because it’s possible to define competing rules that impact a specific order item, all rules in ShopperKit must be sequenced, similar to how you define picking sequence for Sections and Shelves, by dragging and dropping the rule in the appropriate order. If an order item falls into more than one rule at a specific time, ShopperKit will run the rule with the highest sequence value.

White Labeled From Email Address

With this release, we are introducing the ability for you to define the email address that ShopperKit uses when sending emails to your customers (Order Summary) and employees (Lead Time Rule Alerts). From the App Attributes menu in the Client Portal, you will notice that there is a new ClientFromEmailAddress attribute. ShopperKit will use the value you define for this attribute for all emails that ShopperKit sends on your behalf. ShopperKit will continue to use system@shopperkit.com if you do not define a value for this attribute. To improve deliverability of emails coming from ShopperKit, it is highly recommended that you enable ShopperKit to send emails on behalf of your email address domain. To accomplish this, ShopperKit will provide you with custom CNAME entries that you will need to add to your DNS settings. If you do not enable white listing of your domain, ShopperKit will still be able to send emails using your customer defined address, though recipients will see that the email was sent from your address “via sendgrid.net”.

Print Test Label

To better aid in the setup and rollout of new ShopperKit rigs, we’ve added a simple Test Print function to the Devices Preferences screen. Using this, you’ll be able to quickly validate that your label printer is correctly setup and paired with the tablet.  


Order Queueing

In our ongoing efforts to optimize and harden the ShopperKit integration experience, we are introducing a new Order Import failsafe mechanism to the ShopperKit Order API. On very rare occasions, we have seen the ShopperKit Order API briefly lose the ability to connect to the backend system. The most common example of this being ShopperKit deployments. Previously when these errors occurred, the order was inserted into an error log and managed manually by ShopperKit support personnel. With the new order queuing solution, if the Order API encounters any sort of connectivity error or disruption while ingesting the order, the order payload will automatically be committed to a retry queue. Once in the retry queue, ShopperKit will replay the order import once the connectivity or resource availability issue has been resolved.


ShopperKit Status Page

As is the case with any internet application, sometimes when experiencing a service disruption, it can be hard to pinpoint the cause of the error. Is there a problem with connectivity on your local network, or is there a bigger problem at play? To help you better answer this question we're introducing the ShopperKit Status page.. This status page updates every 5 minutes and shows the status of the ShopperKit API and Client Portals. To help mitigate the risk of false positive reporting, the servers that are responsible for running the status page are located in a different region than our primary data center and are powered by an entirely service provider. You can view our status by visiting status.shopperkit.com.



  • Optimized and improved User management list in Client Portal.
  • Fixed issue where Delivery Driver user names were not showing up as an option in the Reserved filter on Order and Carryout list.
  • Fixed the Store management page so that Time zone and UPH attributes are editable.
  • Fixed issue that prevented EAN-13 barcodes from being understood correctly.
  • Fixed issue that caused some Type 2 price embedded barcodes to be interpreted as weight embedded barcodes.
  • Fixed issue that prevented the Force Label Scan attribute in User Management from accurately displaying the selected value for the user.
  • Fixed issue that prevented Prepared Item Workers from being assigned to Sections through the Enable Prepared Item Access button.