Spoonity Generation 3
  • Preamble
  • Company
    • Product Strategy
      • Sales and Marketing
      • Support
    • Onboarding
    • Development
    • Partnerships
    • Summary
  • Tools
    • Ingestion Services
      • Point of Sales
      • Importing Tool
    • OnScreen
    • Dashboard
    • Widgets
    • Summary
  • Product
    • Cache
    • Delphi
    • Drachmae
    • Lydia
    • Hermes
  • Architecture
    • Events
      • The Nexus
    • Cloud
    • Multi-Tenancy
    • Spoonity Apps
      • Technical Overview
  • Case Studies
    • Large Bubble Tea Chain
    • Sports Apparel Retail
    • Family-Owned Grocer
    • Neighbourhood Dentist Office
Powered by GitBook
On this page
  • Core Functionality
  • Configuration
  • Deployment and Installation
  1. Tools
  2. Ingestion Services

Point of Sales

PreviousIngestion ServicesNextImporting Tool

Last updated 4 years ago

Core Functionality

All our point of sale plugins revolve around the primary goal of taking in order-level input on behalf of a client. This data is also typically segmented by a particular physical location or sub-brand.

Additionally, these tools normally offer functionality related to customer onboarding, customer profile retrieval, and reporting and administrative functions for the store.

One of the primary goals of this process will be to standardize our POS plugins to behave and function as similarly as possible within the constraints of the POS environment.

Each of our plugins at minimum should support the following functionality:

  • submit orders to Spoonity API

  • create new customers

  • retrieve customer data

  • load gift cards

  • authorize Spoonity

Configuration

Currently configuration of POS plugins is separated into many different places.

There is loyalty configuration, which can be compiled at POS level as part of the plugin, part of the backoffice, or embedded within the rewards program itself.

Plugin configuration should be handled completely separately from rewards configuration.

There is also behavioural, networking, and other device configurations which are typically managed within configuration files that live on the in-store POS terminals.

As we look to standardize our POS plugin behaviour, a single, unified configuration system should be adopted that would allow the dynamic management of each install. This interface would be embedded into the POS plugin itself, and act as a management beachhead where an IT team could see and manage all of a brand's Spoonity installs.

This backend would support all of our POS plugins and provide a controlled look-and-feel that would be easier to support and maintain.

Deployment and Installation

Similar to our goals for configuration and management, installation and deployment should be made as simple as possible.

This installer should be system-agnostic, and support all of our existing POS plugins.

The installer should go through the following steps:

  • ask the user to select which POS they use.

  • retrieve POS-specific configuration like install directory and any other values we need to include.

  • install the POS plugin.

  • depending on the POS plugin chosen, walk the user through the most common configuration steps (networking, naming, etc).

  • ask the user for their Spoonity vendor ID.

From this point, the user would then complete any additional optional configuration steps (look and feel, adding users, etc), and be able to enter API keys.

The configuration manager that comes bundled with the POS plugin installer should support the ability to manage the configuration for all installations simultaneously.

Users should be able to download and run an installer on their own through our that will guide them through the process of adding a particular Spoonity POS plugin to their system, and then walk them through the initial configuration steps.

payments
Dashboard