---
title: "Runner"
canonical: "https://red-ant-documentation.refined.site/space/RET/34275329/Runner"
format: markdown
---
> Macro (toc)

## Overview

The “Runner” app is a tool that retailers can use to process orders or tasks through a number of statuses from “To Do” to “Complete” in a format that is simple, easy to use, and accessible for all team members and departments.

![image](media://2d5b7aae-27c3-4304-ada5-816f24678b4e)

The Runner app uses a KANBAN structure, which can be used to fulfil many purposes for order and task management including:

- Click and Collect
- Buy Online, Pick Up Instore
- Alterations and Repairs
- Customer Requests
- Stock Check
- Price Check
- Gap Fill

To allow retailers to enable this functionality for any of the above processes (or others), the Runner app is highly configurable. In this document, we detail exactly what and how the tool can be configured.

## How the tool works

**Step 1 : Creating an order/request**

This can be done in two ways:

- Sales associates creates a request in the RetailOS application via the basket, adds a note to the order if required, and can then view the order in the first column of the Runner app

![image](media://351c1026-94b8-420c-844a-a054af18a05f)

![image](media://d70384e1-ccfa-4d0f-91ec-680c576160ce)

![image](media://bcc68fe9-3d56-4a15-840a-c1b8df0e9588)

- RetailOS integrates with an automated system on the retailer's side which creates orders or requests and then sends these to RetailOS. This can be done via API or FTP and the order will automatically appear in the first column as shown above.


**Step 2 : The order/request can be processed by a sales associate**

Depending on what steps are required for each status, the retailer can configure the order view to prompt sales associate to mark products as received or picked, or tasks as completed and then move the ticket through the status' as required.

- Sales associates are required to mark items as available or unavailable, and then move the order to “Ready For Collection” and “Complete” at the appropriate time
- Sales associates can also cancel the order and view customer details from within the order view screen (shown below)

![image](media://7166721a-5511-48a0-b2b6-7d4a48b73dcd)

- As above, RetailOS could integrated with a retailer’s system (i.e. Order Management System) via API or FTP to receive or send status updates automatically.

 

**Step 3: Customer Emails and sales associate Notifications**

At pre-determined points across the flow, RetailOS can be set up for emails to be triggered to send to customers. Alongside this, the system can also send in-app notifications or emails to sales associates. 

This could include:

- Email notification notifying a customer that their order is ready for collection
- Email notification notifying a sales associate that a customer has booked an appointment
- In-app notification notifying a sales associate that there is a new order ready to be collected


![image](media://99d1e214-ee50-46d5-8819-f4bffbbdff95)

![image](media://902b2683-be98-4c21-8909-d73eb94cef47)

![image](media://e2b44bde-5ce6-4135-b391-7d6078a3241e)

## User Flow

The below diagram shows an example flow of how this works in reality for a ‘Pick from store’ use-case:

![image](media://a3c1bcf7-3b31-4849-92f3-b35f3953cce2)

## Functionality and configuration options

As detailed in the earlier sections of this document, the Runner app is highly configurable for a variety of retailer processes and needs. Essentially, it is a KANBAN board for retailers offering a wide range of functionality that can be adapted to meet the demands of any in-store process in a simple and effective UI.

Below is a detailed list of all of the functions available and how these can be configured:

|  |  |  |
| --- | --- | --- |
| **Functionality** | **Configurable** | **Details** |
| **Columns** |
| Column Title / Status | Y | Column titles are dictated by the relevant status for the column and can be updated the correct status name for the retailer |
| Number of Columns | Y | Retailers can determine the number of columns they required based on their process. However, we do not recommend more than 5 columns as this would begin to detract from the usability of the tool |
| Column Sort | Y | Retailers can sort columns by a specific order field (i.e. date) or by the amount of time spent under a specific status (i.e. >2days in “awaiting picking”) |
| Summary Card Data | Y | The following fields can be shown on the order summary card: order date, order time, number of products, staff member, customer, order reference, status, product id, product name |
| **Order Screen** |
| Order/Request Screen Data | Y | The following fields can be shown on the order screen: order date, order time, number of products, staff member, customer, order reference, status, product id, product name, product variant, product quantity, product cost, product status, order channel, store, delivery details |
| Order/Request Screen Actions | Y | Orders/requests can be moved forward and backwards in the KANBAN flow via actions (i.e. order picked, order cancelled, order collected) which are directly associated to statuses |
| Product/Task Pick or Completion | Y | The tick/cross functionality can be enabled or disabled depending on requirements |
| Add To Basket from Order | Y | The ability to add a product to basket from an order/request can be enabled or disabled depending on requirements |
| **Other** |
| Order/Request Type | Y | Retailers can name the order or request type to the relevant name for their process |
| Email Notification | Y | Retailers can decide enable email notifications to be sent to sales associates and/or customers when orders move across statuses. The email copy and design is also configurable |
| In-App Notification | Y | Retailers can decide enable in-app notifications to be sent to sales associates when orders move across statuses. The notification copy is also configurable |
| Auto-Refresh | Y | The system will automatically refresh cards and their statuses at a set interval determined by the retailer (i.e. 10 minutes) |
| Multi-Process Handling | Y | The system can be used to handle multiple processes in one flow if required, by allowing multiple order/request types |