Tag Archives: cloud

Posted on Mon, Nov 20, 2017 @ 4:00 pm

You have a cloud solution. Congratulations! Now, how do you sell it?

After you built your cloud solution, your next key decision is choosing the right go-to-market (GTM) strategy. There are many factors you’ll need to consider here, including subscriptions, pricing, and sales channel.

When crafting the GTM strategy for a cloud-based solution, you need to look at the subscriptions or offerings you will provide to your customers. Remember that customers like having options from which to choose, but too many options actually can deter them from making a decision. That’s why most cloud solution providers settle on three or four subscription options.  How these subscriptions are structured depends on the solution provided. Some solutions lend themselves to a feature-based subscription model, e.g., the Silver subscription has 10 features, the Gold has 20, and the Platinum has all of them. On the other hand, some solutions lend themselves to a usage-based subscription model, e.g., the Silver subscription provides up to 1,000 transactions a month, the Gold provides 5,000, and the Platinum provides 10,000.  Defining usage-based subscriptions should be done with operating and transactional costs in mind. Defining feature-based subscriptions can be a bit more confusing.

When considering a feature-based subscription model (one of the most common), an important thing to keep in mind is this question: What are the fire breaks between each subscription level?  Why would a customer want to purchase a higher cost subscription level rather than a lower cost one?  What are the “carrots” you can use to entice a customer to move up to a higher subscription? There are many ways to think about this, but there are often two major lines of thinking. One is to place entire features in only one subscription level, e.g., reporting is only in the Platinum subscription level. The second way to think about this is to spread out a feature over multiple subscriptions, e.g., canned reporting is available in the Silver package, basic report configuration in the Gold, and customized report wizards in the Platinum. The idea here is to whet their appetites with a feature in a lower subscription, knowing that once they see it they will want more, when they ask for more you have the perfect answer…upgrade to the next subscription level, and you can have it.

So, now that you have your subscription levels defined, you have to figure out how to price each level. Pricing is an art and has many components to it in order to get it right. Some factors to consider when defining pricing for a cloud-based solution are the length of your costs, license term, revenue recognition and generally accepted accounting principles (GAAP), and the value of building a stream revenue base.

When thinking about pricing, the first thing to consider is your cost. Building, delivering and hosting a cloud-based solution is free for your customers, but certainly not for you. One of the most difficult things to understand is how much it will cost to host and maintain a new cloud-based solution. Work with your cloud provider to estimate compute and storage cost. Doing so on a “per transaction” basis often can help. Then, you can estimate how many transactions each subscription level might generate per month, and you can include this in your pricing model. The next step is to think about the license term. Most smaller, less expensive solutions choose a month-to-month subscription, which give the customer the option to exit every 30 days without penalty. For larger solutions with higher costs for onboarding a customer, some will choose a quarterly or even annual license model. It all depends on the investment made in onboarding on both sides of the table.

One of the most important things to consider when defining the pricing model for a new cloud-based solution is GAAP and revenue recognition. Many companies trying to make the move to providing on-premise monolithic software solutions are used to recognizing all of the revenue from that sale up front. However, revenue can only be recognized on a monthly basis when you’re selling a cloud-based solution, regardless of how you price it. Revenue is based on how your product is consumed. This changes the revenue recognition model, which can affect any factor within an organization, such as profitability, sales channel, and sales model to name a few.  An organization launching a cloud-based solution has to be prepared to build a stream revenue model business instead of an up-front, license revenue model business.

Cloud-based solutions are often billed monthly or quarterly (depending on the size and complexity of the solution), and because of this, they typically have a lower billable price point.  Due to low initial revenue streams, it often does not make financial sense to use traditional sales channels to sell these solutions. It is difficult and often cost prohibitive to pay a sales rep commission on a monthly service. Consequently, the price point and resulting compensation is so low that most field sales reps won’t even want to sell the solution. Because of this, most companies that offer cloud-based solutions use a sales channel other than field sales. Some will use inside sales reps and others will use digital sales channels, using products like Salesforce’s Marketing Cloud to market and sell online solutions to customers. While the GTM channel is an important choice to make, regardless of the outcome of that choice, enabling the customer to see and use the solution before they purchase it is a key component to success.

Free trials are key to a successful launch of any cloud-based solution. For one thing, people have come to expect a free trial, so not having one will be a major strike one in any cloud solution launch. Secondly, customers have a need to see the solution before they purchase it, so they can understand how it works and ensure the solution fits their needs. Remember, cloud-based solutions typically have no customization (custom coding) and minimal configuration (settings). Enabling a free trial will allow your customers to see the value your solution can bring out of the box. A few notes to ensure your free trial is a successful one:

  1. Full Features – Regardless of the subscription model chosen above, the free trial should ideally contain the full feature set and no usage restrictions to enable the customer to get the full experience of the solution.
  2. Nurturing Programs – Many forget that a free trial is great, but it is just that: Free. What often happens with free stuff? It’s free, so it has little to no value. Users often forget about free trials and don’t use them. Nurturing programs are essential to converting as many free trial users to paying customers as possible. Here are some major components for a successful nurturing program:
    • Welcome emails
    • “Did you know?” emails, in which features and use cases are outlined
    • “We noticed you haven’t logged in. Can we help?” emails

Nurturing programs should not stop after the free trial is over and should continue after a purchasing decision is made. Never forget that you could potentially lose every customer every month in the cloud model. Because of this, you need to keep in touch with your customers to ensure they know you are there. Do you have a new feature? Did you just learn about a new development or trend in the market? Let your customers know about these important updates, because this shows them you are a partner and not just a solutions provider.

We hope you enjoyed our 3-part blog series on cloud solutions! If you didn’t catch the first two in the series, click here to get started. If you would like to set up a time to learn more about how we can help you build an effective cloud solution, contact us here.

About the Author

Abdul Rafay Mansoor is a technical architect at ObjectFrontier, Inc., and his work primarily involves presales consulting. Abdul has been a developer for more than a decade, and he began taking on presales consulting roles a few years ago. Abdul’s area of interest is cloud native development, and you often will find him passionately advocating cloud adoption to our clients.

Please follow and like us:
0
Posted on Thu, Nov 2, 2017 @ 7:51 am

SaaS. Public Clouds. Private Clouds. If you’re in the software industry, chances are you hear these terms pretty much every day. From your boss to your colleagues to the software industry gurus you follow on Twitter, cloud solutions are what everyone is talking about right now. But with so much noise out there, you may be asking these questions:

“What exactly are cloud solutions?”

“How relevant are they to my industry?”

“Why should I build my next solution in the cloud?”

These are very good questions we hear from many of our clients, too. As we move into an era of solutions that include Google Docs, Office 365, Mint.com and many others, it’s important to understand what these cloud solutions are and what they aren’t, as well as how customers interact with them. In this blog series, we not only want to answer your questions, but we also want to give you ideas for how you can build successful cloud solutions that speak to your customers’ needs.

To ensure we’re on the same page as you are when you read this series, it’s a good idea to start with a clear working definition of the cloud. The cloud is nothing new. In fact, the cloud has been around since ARPAnet first linked two computers together in 1969. Up until recently, the cloud consisted mostly of web and file servers hosted on different Internet-connected networks and really didn’t have too much more to offer. It remained “the Internet” for years. However, once companies started to build and deliver applications and complete solutions on the Internet, they decided to rename the Internet as “the cloud” to breathe new life into the same infrastructure. The Internet was a network of connected computers and web/file servers, and now it is a network of connected cloud solutions and cloud service providers.

While cloud solutions are very different from each other, they typically have a few common characteristics that define them as such. Cloud solutions often offer benefits such as instant provisioning of new customers and users. This requires scalability, which is provided by virtualized resources with the ability to expand and contract servers and compute power on the fly based on need. First, a cloud solution is typically deployed (installed/configured) on a group of servers hosted and maintained by a third party. With this model, the customer’s main benefit is that his or her IT department typically is not involved in the installation, configuration, or maintenance of the solution. Believe it or not, since budgets continue to shrink and more IT departments are outsourced, many IT departments are advocating for cloud-based solutions because they don’t have to be involved as much over the lifecycle of the solution. Overall, the total cost of ownership of a cloud-based solution is often much less than purchasing and maintaining a software solution in house. Secondly–and this might go without saying–cloud-based solutions are almost always accessed by people using a web browser through the Internet using standard web ports (e.g., 80 and 443) with little to no software installed locally to make the solution work. A good cloud solution will work from any network on any computer that has a modern web browser. Lastly, most cloud-based solutions are multi-tenant to achieve economies of scale for the provider.

There are two ways you can architect a multi-tenant solution, and it is extremely important to understand the difference between them. The first way to implement a multi-tenant solution is cheaper but less secure. You would have a single database that contains all data from all customers in the same tables. Naturally, this is easier to build and cheaper to run. However, this makes a lot of customers nervous because their data is commingled with their competitors’ data in the same table. The only thing separating one customer’s data from another is a customer ID field on each record. The second way to implement a multi-tenant solution is more expensive but also much more secure: Have a unique database for each customer who uses the solution.  Naturally, with one DB per customer, there is no commingling of data. Each DB can be encrypted with its own unique encryption key, and there is almost no chance one customer can gain access to another’s data.

Now that we have working definitions of the cloud and cloud-based solutions, let’s talk about the words public clouds, private clouds, and SaaS. The servers and data in a public cloud are hosted on a provider’s network intended for multiple customers to connect from any place with an Internet connection. In a private cloud, a solution and all of its data is hosted within the firewall of a single customer’s network and is only accessible by that one customer’s users.  Software-as-a-Service (SaaS) is nothing more than a deployment and a model (and sometimes a monetization method) and basically means that users access the hosted solution on demand, as they need it, with little to no installation required. SaaS is the opposite of an on-premise solution. Knowing this, you can see how certain industries would be pulled toward cloud solutions.

If you think about why customers are entertaining cloud-based solutions, it will become clear why most industries today are moving towards them. Costs are a driving factor for every business as they are all going up, like costs for personnel, health care, raw materials, and IT. At the same time, customers are demanding things to be built faster, delivered more quickly (increased costs again) and at a lower price. As a result of this and the current economic climate, most companies are seeing their department capital budgets going down, which means they have less money to invest in costly on-premise solutions. With that in mind, it is no surprise that cloud-based solutions are most relevant in industries that are being forced to operate on leaner budgets, such as higher education, facilities management, healthcare, and legal. Based on a quick review of publically available RFPs, you will find that even the federal government is moving to cloud-based solutions for some of its needs. These industries are moving to cloud-based solutions due to the tremendous cost savings as well as the other benefits they provide.

The benefits of cloud-based solutions are rather substantial for both the customer and the solution provider. Let’s look at why cloud solutions are important from both sides of this table.

The Customer. More customers are demanding services in the cloud for a number of reasons. First of all, many are becoming more cost-sensitive about large purchases and are moving from a CAP-EX operating model to an OP-EX model, meaning they don’t want to commit to purchasing a system for $50-$100k up front. Instead, these customers desire a low monthly payment with no commitment and quick onboarding. Secondly, internal IT costs are rising. We have been hearing from our customers that internal IT department chargebacks for hosting a new application are often just as much, or more, than the license of the application. Lastly, on the same point, IT departments themselves are asking for more cloud-based services since they are running “leaner” than they have in the past.

The Solution Provider. The number one reason you should be thinking about building your next solution in the cloud is simple: Your competition is already doing it. If you take a step back and think about it, the reasons become clear. In a world of cloud-based applications and agile development, you can provide new features and defect fixes every day if you want to, but in reality, the release schedule usually is once every two or three weeks. The point is when there are new features to be rolled out, all you have to do is update a single cluster of servers in a cloud instead of rolling out an update to each of your customers, getting it installed, and dealing with the support fallout of incorrectly applied upgrades and patches. Secondly, when all of your customers log into the same multi-tenant environment, you are able to accumulate all of their usage data in one place. Check out our blog on machine learning and data lakes to understand the benefits.

When all of your customer usage data is stored in one place, you can…

  • Understand usage patterns and see what features customers are and are not using
  • Perform A/B testing of new features/ideas in a real environment
  • Directly market and sell additional functionality (upsell) to specific sets of customers with specific usage patterns. For example, you can say, “We noticed you use feature X. Do you know that if you upgrade to the premium package, feature X is expanded in a way we think would be useful to you?”

Lastly, here’s what we consider the real value of a cloud-based solution: analytics. With cloud solutions and their no-commitment monthly payments comes the reality that you could lose every customer each month. They simply are not locked into any commitment, which is one of the main selling points to the customer in the first place. As a software industry, how have we retained customers in the on-premise world? Implement and release new features before the competition does. With cloud-based solutions, your competition can do that just as quickly as you. So, what is the new way to provide differentiated value to your customers? It’s through using insightful analytics and reporting.

To learn how you can select the right provider to help you build your cloud solution, stay tuned for next week’s blog, “What are Cloud Solutions Anyway? Part 2.” Or, contact us here to set up a time to talk with us about your questions and interest in implementing cloud solutions.

About the Author

Abdul Rafay Mansoor is a technical architect at ObjectFrontier, Inc., and his work primarily involves presales consulting. Abdul has been a developer for more than a decade, and he began taking on presales consulting roles a few years ago. Abdul’s area of interest is cloud native development, and you often will find him passionately advocating cloud adoption to our clients.

Please follow and like us:
0
Posted on Wed, Apr 13, 2016 @ 6:46 am

I’m an old ­­software warhorse and wrote my first program back in 1972. Everything certainly has changed since then, but some principles endure. For example, one of my early bosses used to remark that good software was like a good axe a lumberjack used for years. Yes, the head had been changed several times and the handle was replaced a few times too, but somehow, it was still the same axe. His point was that good code should be designed and separated into components, so that as one part wears out, it can be replaced without throwing away the entire code base. Even when all the components have been replaced over time, somehow the product is still the same.

That concept of separate components with well-defined interfaces is particularly relevant in today’s digital business. As we all rush headlong into the process of digital transformation, it’s important that we don’t get so wrapped up in the latest mobile, cloud, and IoT technologies that we forget the basic notion that it will all change again. (And, like a metaphorical Yoda in the software world, I’ve lived long enough to see it change many, many times!) We can prepare for that change by moving to an API model that encapsulates our important business logic, which doesn’t change as often, from the ever-changing ways we use that logic to drive our business.

You often hear about the API economy these days, and as a veteran from the early days, I think it’s great to see us reach that nirvana of re-use we had long hoped for years ago. You no longer need to know the details of where data is stored, how it is accessed, or all the rules pertaining to it. You just call the component with an agreed-to format (API) and you instantly get the data you need to incorporate into your own program’s needs. This has given cloud-based software a tremendous boost that allows us to quickly build new software that stands on the shoulders of software already written and tested by someone else.

That same concept applies to our internal business software. If we can componentize our business rules and database access and create a set of well-defined API calls to handle things like adding a customer, calculating a payment, or giving out the current inventory level of a specific product, we are setting up our own building blocks that enable us to assemble them in new and important ways during our digital transformation efforts. Put another way, if we expect to fully participate in the API economy with other businesses, we must build our own APIs for ourselves first.

For example, APIs that record and monitor a car rental can be used by the rental agency’s website for booking purposes, by the renter’s expense management system to get the receipt and charges, and by the car’s manufacturer to provide usage information for warranty coverage.

While all this would certainly help the customer on his journey and streamline the car rental agency’s processing, it requires a lot of effort. The agency first must simplify its backend systems by getting rid of duplicate systems of record that store rental information inherited from prior acquisitions.  However, it takes years to decommission old systems of record. In the meantime, it may be necessary to design and build lower-level APIs around each of the duplicate systems and then build higher-level APIs to hide the fact that some of the data is actually stored in different systems. Neither the renter, nor his expense management system, nor the car manufacturer care one bit about which internal system the agency is using to record the transactions they need. You need to have your APIs mask all that complexity so you can offer a single view into your company and a single way to do business. This is the essence of what APIs offer to both your external customers and your own developers.

While it might be nice to try to build APIs for all your corporate data, the reality is that even if you could do it, the time and cost required would be prohibitive. You have to focus on building your APIs over time, embedding the work to do them in each of the short-term projects that our business requires. This requires some real discipline, as it always takes longer to build some APIs first than it would to just bang out the code asked for by the business.

Also, it always seems that your own staff, who are building new APIs, are the last ones to use them. However, by incenting them through carrots and sticks (like authorship awards for new APIs or penalties for not using them), you’ll create the ability to change the axehead and handle of your systems while keeping the essence of them the same.

Please follow and like us:
0