Context
Many features in our platform require or benefit from a concept for grouping Stores, in order to enable Brands to more easily manage configurations, settings or entities across multiple stores.
With the introduction of the Management Center and the migration/rebuild of important features, such as Brand Menu Management and Dispatch, we wanted to reconsider the approaches we had to Stores grouping based on our learnings over the past few years and find the best approach for the future.
So what is it?
Long story short - it's a functionality that allows you to group your Stores (previously called Venues) into 'batches' because they all have something in common. For example - they may be using the same POS, so it would make sense to organize them into one centralized group from which you can manage them and the POS mapping easily. Another example would be Store type: lets say you have restaurants and express cafés - they will have 2 different Menus. In this case, you will need 2 separate Store Groups for them, to easily change the Menu applicable to one particular Store type.
Improvements - why Store Groups work better
There were some legacy challenges that we had with our previous approaches to store grouping. Both concepts will be retired through the introduction of Store Groups.
Chain
-
Chain could only have a single integration type, store one set of POS mappings (to a single POS database) and managed the Menu, meaning complex franchisee markets needed to manage multiple instances of the same Menu, since they have franchisees on different POS systems and different POS databases
-
Chain Managers could only be created by Administrators in the CMS, so they always had to be created by our Success Managers, rather than Brands being able to invite new Users themselves
Company
Since a Company mapped a legal entity and we stored receipt & legally relevant information at a Company level, here's what was difficult:
-
Store Managers could only be created at a Company level, but a single User account could only be part of one Company, which means that Area Managers (that were responsible for areas including multiple franchisees) needed to have multiple User accounts to access all of their Stores
-
Certain franchisees have independent legal entities for each one of their stores, creating the issue within franchisee organizations as well
Multi-Purpose Store Groups
Multi-Purpose Store Groups are store groups that can be created for multiple purposes (pre-defined and implemented in our platform), as imagined by the person that is creating them. They simplify the mapping and management of very complex Brand and/or restaurant organizations and they still keep simple organizations easy to be ran.
This is done by:
-
Giving complex organizations the possibility of creating many Store Groups with only a single purpose or a small set of purposes to map their use cases
-
Giving simple organizations (single franchisee markets, for example) the possibility of creating a one or very few Store Groups with many purposes assigned to them
How it works
-
The parent of a Store Group is the Brand
-
Store Groups can be created by Users with the certain permissions
-
Permissions exist by purpose, so a User may have permission to add Store Groups with one purpose, but not the other
-
-
When creating a Store Group, the User has the possibility of selecting one or more purposes for the Store Group
-
Purposes are “hardcoded” during development and cannot be dynamically created, since the platform needs to be developed to support them
-
-
Based on the purpose selected for the Store Groups, additional fields become required or optional to be provided by the User
-
For example, when the purpose Integration is selected, an integration type and integration fields need to be filled in
-
-
Based on the purposes selected, certain restrictions and validations apply when adding or removing Stores within the group
-
Users can move stores from one group to another
-
Users can add additional purposes to a Store Group after creation
-
A Default group exists at Brand creation, which contains all Stores, but does not have any purposes assigned
-
A Store Group can be empty (not have any Stores added)
-
Users can remove a purpose from a Store Group
-
Users can delete a Store Group
User Management & Permissions
-
A User needs to have necessary permissions in User Management to view, create and manage Store Groups
-
Users with Brand level permissions can see all Store Groups of the Brand
-
If a User has access to all of the stores within a Store Group and has the necessary permissions for all Store Groups or specific Store Group purposes, they have access to manage that Store Group
Purpose Restrictions
There are 2 restrictions that apply to a Store Group depending on the purposes that have been assigned to it:
Unique |
Defines that a Store cannot be part of multiple Groups of this purpose. For example, for Billing, it is important to make sure that a Store is not in multiple Billing Groups, since it would be charged multiple times otherwise.
|
Required |
Defines that a Store needs to be part of a Group of this purpose to be created. For example, for Integration, it is required to know the Store’s integration for the Store to be able to accept Orders.
|
Possible Purposes
User Management |
Used in User Management/Authentication service to give Users access to multiple Stores. When Stores are added or removed from the Group, they automatically gain or loose access to that store.
|
Integration |
Used to know which Integration the Store uses to send Orders and for store POS mapping.
|
Dispatch |
Used to manage Dispatch settings across multiple Stores and share a single driver pool.
|
Reporting |
Used to facilitate reporting in Statistics/Analytics sections of the Management Center.
|
Billing |
Used to know who should be billed for module usage of a Store and create a single invoice.
|
Menu Management |
Used to facilitate management of visibility (including Channels visibility) and prices propagation of Menu entities.
|
Payment |
Used to centralize common Payment settings (available payment methods and payment processor) across a Group of Stores.
|
Comments
0 comments
Please sign in to leave a comment.