The Works Services-as-a-Subscription Model Update

Back in May, I wrote a post describing a completely new Services model we call "The Works from Forceworks". It is a Services-as-a-Subscription model that is unique in the industry. I also promised to follow up with our learnings from this new model, so today I will do just that.

The Works

First, I'll remind you of what the offer is. Thanks to advances in low-code/no-code for Dynamics 365 and the Power Platform we decided it was finally time to launch a completely new services model. An all-inclusive, unlimited service that included not just support, but also deployments and customizations, along with several other things. You can see what we included here. Based on our analysis of recent customer history, "The Works" will cover 100% of the requirements for about 90% of the customers.

How's it Going?

Customers are eating it up. Almost all of our existing customers have converted. I am thinking we may have left some money on the table. But now is not the time to maximize the revenue, rather now is the time to flesh this out. We wanted this to be as "turn-key" as possible starting with getting a quote that can be done right on the website. This meant "standardizing" the pricing. Today there is a Fixed Base cost, plus an additional fixed cost for certain combinations, like Dynamics for Marketing for example, and then a Per User cost.

Part of the thinking was that the number of users would be a good measure of the work our team would need to perform. But in reality, while a good general rule, there are exceptions. For example, a simple deployment with basic needs, but a large number of users, versus a highly complex deployment with only a handful of users. For the former, the price is too high and for the latter, the price is too low. We are still thinking about the best solution to this.

Pro-Active

Almost all services offered by Partners to Customers are "reactive", responding to customer requests. This makes sense in an hourly model as it is not the Partner's job to decide how to spend the customer's money. But in an unlimited subscription model, we are able to be "pro-active" since it does not affect the customers' cost. A simple example may be once a week checking to see if all Flows are running properly or checking capacity. One of the primary differences in a Subscription model is that it is very important that the customer renews at the end of the term. Customers will scrutinize that monthly charge and compare the value they received each month. If at renewal time, they didn't see the value, they will not renew. Over a twelve-month term there will be months that are more active than others. But you cannot allow a month to go by with no activity, and this is where pro-active services fill the gaps. We are continuing to add to the list of things that we can do pro-actively to bring value and building tools to try and automate that as much as possible.

User Support

We were initially thinking this might be a big item, and for some it is. We had this idea that all users would be added to a Team or Distribution List that our team were also members of to communicate and resolve issues. Some customers loved the idea and added all users. Others preferred to keep that group small. We built a solution that we install on each customer environment that adds a life ring icon in the top navigation. This opens a form modal where a user can report an error, ask a question or suggest an improvement which via Flow is added to the Team or Distribution list. I am pretty happy with the result having seen many improvement ideas coming directly from the trenches.

Deployments

The service includes unlimited deployments. This was a dicey one, but I insisted that we include it. The easiest thing to do is to specifically exclude things from an unlimited service to reduce your risk. But you would quickly get to a point were "Unlimited" did not mean anything. This is also a key point at which an unlimited service makes extra sense. For a deployment month, you know your needs will be higher than usual. When comparing to hours you could easily spend as much in a deployment month than the entire annual subscription cost. We have not been doing this that long, but I can already see that we will go underwater during deployment months for a customer. Fortunately, deployments do not happen very often.

Customizations

This service also includes unlimited customizations, and by extension, to do those properly, unlimited Solution Architecting. If low-code/no-code were not where it is today, this would not be feasible. Where deployments are typically a one-time big bang, customizations are continuous. Although the amount varies from month to month. So far this is averaging out okay.

Exclusions

We tried really hard to include as much as possible on an unlimited basis, but developers are expensive, and development can often take a lot of time. So "development" is excluded and offered on our traditional hours model. This is the one area that some customers get suspicious about. Looking for the "gotcha" they expect that every time they ask for anything we will cry "development". But again, tracking with our earlier research, many customers never hear the word "development". It does seem that the more sophisticated the customer the more they look for sophisticated solutions which can often require some development. There is some grey area here and we are likely to do something one-off that might meet the technical definition of development within the service rather than bring up the need for development hours, because again the goal is renewal.

Are We Making Money Yet?

It is still too early to tell, but probably not. However, this is not unusual for a new subscription service as it builds scale. We are also still building the tooling to make this more efficient. As of now, we do have one customer that I can see we will consistently lose money on every month. This is the reason I added the right for us to terminate for any reason in our Terms and Conditions. We still need to figure out the best way to handle that.

Summary

Was this a good idea? I was not sure when we launched this, but now I can see it was indeed a good idea. There is a tipping point of profitability based on the number of subscribers that we have not reached yet, but I am confident that we will. My next update will be when we reach that tipping point, hopefully in the not too distant future.