Mirus Restaurant Solutions
Blog Demo Login

Restaurant SaaS: Client's Rights

Posted by Dave Bennett on 7/2/18 9:57 AM

RestaurantSaaSCustomerRights

Treating Customers Right

Restaurant operators are great customers; however, there are some Software-as-a-Service (SaaS) vendors that are notorious for not treating them well. Change is accelerating in the restaurant business, as well as in the software solutions used by restaurants. Over the past decade, the way operators buy and access their software has changed.

Previously, a perpetual license model was used where the operator paid upfront for the software and had to keep it up and running themselves. Today, a subscription model is used where the software is hosted in the cloud and the operator pays one monthly fee for both the access to the software and the costs for keeping it running.

The impact of these changes is significant, as are the benefits to both the operator and the SaaS vendor. However, it forces a closer relationship between the operator and vendor as the vendor takes on the day-to-day duties of keeping the software and its associated data available.

The restaurant operator needs new protections in this closer relationship, protections that are designed to maintain the balance of power between the operator and vendor. Restaurant operators are smart people and will eventually demand a set of terms from the vendors that give them the protections they feel are necessary. In the meantime, we are proposing a starting point by listing the terms we feel vendors and operators should embrace - a client bill of rights.

Client Bill of Rights

At Mirus, we have developed this Bill of Rights for restaurant operators to document the expectations and obligations of operators and SaaS vendors. If you are a SaaS vendor, are you willing to commit to these rights and make sure your clients receive them?

  1. Monthly invoices should be simple to read and transparent for the client. No one should have to deal with the complexity of your average phone bill. It should be clear what services the client is paying for, and how much each service costs.
  2. Contracts should be easy to sign on, and easy to sign off. A client should able to terminate a contract for convenience with a 60-day notice. No restaurant operator should be forced to use a vendor they do not want to continue to use.
  3. Clients own their data, period.
    1. Clients should have a free, or near-free, way to download their data at any time. Some vendors have blurred the lines on who owns the data, and have held the data hostage for ransom to be paid by the client. Every vendor should provide a reasonable way for a client to collect their data if they want to move to another solution.
    2. Data generated and captured while running a restaurant belongs to the restaurant operator, and not the vendor. We call this “Customer Data.” Examples include punch-in and punch-out data, the details of each guest check, etc.
    3. Data generated and captured while providing a service to the restaurant operator belongs to the vendor. We call this “Provider Data.” Examples include the number of logins, the number of reports executed, etc.
    4. Data that is adequately de-identified or aggregated to protect the identity of the restaurant operator’s location and the brand name is up for negotiation between the operator and the vendor. We call this “Aggregated or De-identified Data”. Examples include the guest check detail where the restaurant number and menu items are disguised to prevent identification to a location or a brand.
  4. Vendors should be supportive when clients ask two vendors to coordinate services such as sharing data to the benefit of the restaurant operator. A client can often create real value for themselves by integrating two or more systems. Vendors should actively support this and not actively work against the client's objectives. Reasonable fees should be paid to the vendor for project work, but not punitive fees designed to discourage the client.
  5. API access should be toll-free. Charging for access to an API is the same as holding the data hostage. If vendors do not provide for simple and free data flow, the potential client value of mashing up apps is blocked. This doesn't mean the vendor should be expected to absorb one-off project costs, but when a project is necessary, it should be reasonably priced.

Thoughts?

Are you currently using SaaS vendors or providing SaaS to restaurants? If so, could you share your thoughts on its effectiveness?

About Mirus:

Mirus provides services in data management and solutions in custom reporting for the restaurant industry. We integrate and organize any data from any system for multi-unit restaurants. Since 1999, Mirus has helped measure and improve business performance.

Watch Mirus reporting demonstrations and client reviews on our YouTube Channel

If you enjoyed this blog, please share by using the social buttons at the top of the page and make sure to leave your thoughts in the comment section below.

Restaurant Data Ownership

Topics: Restaurant IT

Search

Subscribe to Blog

Recent Posts

Top Restaurant Blog
Hot Companies In Houston