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
  • The Sales Pitch
  • Pricing Models
  • Handling Custom Work
  • Marketing the Product
  1. Company
  2. Product Strategy

Sales and Marketing

PreviousProduct StrategyNextSupport

Last updated 4 years ago

The Sales Pitch

The initial approach to selling the Spoonity product line would need to change in order to accommodate the evolution of the product strategy.

Individual first party products like loyalty, payments, and marketing could either be sold individually, or used to up-sell additional functionality.

Alternatively, the could be attractive for businesses focused more on data and analytics, and who have less interest or are incompatible with loyalty.

The major benefit of this product evolution is flexibility. It allows us to target a much wider potential client base, while simultaneously making our services more attractive to all of them. We can selectively focus on and build individual environments that are tailor-made to each brand by layering individual product elements on top of each other.

Pricing Models

The introduction of multiple segmented products should be accompanied by changes to the pricing strategy of our services.

The current Sales and Onboarding costs of the product are very high, and contain a high-degree of risk when clients fail to launch.

Instead of front-loading our costs upfront for the total service package of loyalty, payments, and marketing, these products should be priced individually.

The product should include a lower starting cost, but with billing starting significantly sooner in the Onboarding process.

Additional product lines like , , etc would be sold as add-ons and be billed once they are in use.

If we look at a standard Spoonity base price (currently) of 150.00 CAD, we would charge 50.00 for the , 75.00 for , and 25.00 for (for example).

Billing would begin immediately for the Data Core, and at a later date for Loyalty and Payments once configured and API keys have been generated.

Handling Custom Work

A staple of our experience (especially working with larger clients) is a need to support custom initiatives and workflows that are not relevant or easily sold to other clients.

The structure of the current application does not adequately support this kind of work, and often weakens the overall product rather than improve it.

By branding "Spoonity Apps", we can isolate client-specific first party work, or engage the wider development community in a standardized and well-documented process.

When accepting this work internally, restructuring how we bill for custom work is also important. The recommended strategy would be to bill clients per sprint. We would set a "price" for each of our sprints, and sell them un units -- with each unit representing a five day work week.

Billing in sprints allows us to set a much more standardized number, and is easier to integrate into our existing work structure.

If we charge $3000.00 CAD per sprint, and we know a piece of work will take two sprints to complete, then we are in a better position to cover those actual costs.

Marketing the Product

Naturally, the product marketing strategy must change in lockstep with sales to highlight the evolution of the platform.

The primary goal of the product is to be flexible. This has an unfourtunate consequence of being difficult to market in a straightforward way.

The suggestion would be to center the marketing of the platform as a data-driven product (general), and then hone the focus into key market segments (specific).

In essence, we would market the Data Core product as being an essential part of digitizing a business, eligible for all brands and verticals. We would then guide users into more specific marketing materials for their individual business sector, be it retail, quick-service restaurants, etc.

The marketing conversation would go something like this:

"Understanding your data is essential for any business."

What are you looking to do with your data?

  • Engage customers to increase and promote loyalty.

  • Generate reports and perform detailed analysis.

or

  • Something custom-made for my business.

Marketing materials should start broad and direct users to more specific data-driven activities.

By defaulting the base of the product to the , we can create an underlying framework for each client that is far more forgiving to custom work, by creating an architecture for componentizing that work into unique feature packages.

Data Core
Data Core
Loyalty
Payments
Data Core
Loyalty
Payments
Data Core