No two franchises are alike. Erply’s cloud-based franchising tools allow you to choose how much control your franchisees have over business processes, no matter how complex your setup is.
Centralized franchise management
Define franchise-wide rules from the master HQ account, including customer information, POs, loyalty points, store credit, promotions, discounts, and more.
Create in-depth reports and analytics for your entire franchise or for a few select locations. Reports can be set up to automatically sync from each franchise account to HQ.
An Erply franchise chain, in a nutshell, is a collection of individual Erply accounts.
Each account in this collection functions as a normal Erply account, and has the same feature set, settings, and permission structure.
Each account has a unique ID (account number), and separate login credentials.
When we set up a chain, we will designate one of these as the HQ (headquarters) account. This is owned by the franchisor (company headquarters) and it is used to manage the company-wide product catalog.
Other accounts will be "store accounts", owned by franchisees.
Finally, one account will be designated as the “reporting account”. Sales and other documents will be collected from individual stores to the reporting account, and this is where the franchisor sees the performance of stores and products across the whole company.
Our recommended setup is to have one account per franchisee.
Company-owned stores can be located either in a designated store account, or directly in HQ.
Sometimes we have also recommended to have one account per location, especially when:
- Franchisees occasionally trade or exhange the stores;
- Or if a store could change from company-owned to franchisee-owned, or vice versa;
- Or if the total number of stores is very large (hundreds or thousands of stores).
Erply offers a choice between two franchise models:
- Shared Data model;
- Synchronize from HQ model.
The whole chain has to use one or the other. It is not possible to mix the two approaches.
During onboarding, we clarify the requirements with you and help to identify which approach is the best for your company.
Taking product catalog as an example, the two models work as follows:
- If the product database is IDENTICAL in all stores (same prices, same suppliers, same tax rates), then we go with shared data.
- Shared data means that every franchisee sees the same records, and can also edit the records.
- The data does not "belong" to HQ in any way—the same dataset is visible for the HQ just like it is for any other account. There is no synchronization or data copying, all edits are made directly in the same database.
- Access limitations (eg. stores must not edit products) can be solved with user permissions.
- Variations in pricing can be solved with price lists. Some franchises are not specifying prices on product card at all — all pricing is managed with price lists.
- If there are variances that cannot be resolved (some fields on product cards need to have different values in different accounts), then we go with "syncing data down from HQ to stores".
- Each account has its own copy of the product database.
- HQ's changes and new products are "copied down" to all store accounts.
- Certain fields can be skipped from the copy. These are the fields that should be left editable for the stores.
- Store can edit other fields as well (we can't physically prevent that), but their changes might get overwritten by HQ at any time, so it's not recommended.
- Stores can add their own products, too. These products will not be visible for other stores.
- If this flexibility is not needed, then adding new products in stores can be disabled with user permissions.
- There is also the option of only copying new products (so that any changes to existing products will not be synced). After the product appears in a store, it can be modified by the store at will. However, HQ will be unable to make any subsequent edits to it.
Please note that the syncing is unidirectional: from HQ to stores only. There is no syncing up to HQ — or between the stores. This makes the model inappropriate, most importantly, for sharing customers. New customers are typically added, and customer records updated, at store level (from POS), not from HQ.
So customer database must either be fully "shared" between accounts, or each store must have its own individual customer database. Going with the “Synchronize from HQ” model means there will not be a centralized customer database.
Is there a limit on the number of accounts?
No, once the number of accounts needed is agreed upon dev and operations setup the customer so whatever resources required to support the customer size.
Can other Franchisee’s see other account reports?
No, the specified data is shared across accounts. Reporting is limited to the franchisee and what is synced to the HQ account.