Our friends at ALTA Consulting recently posted a blog called “12 Key Benefits of Service Package Productization for Growth”. You can read it here. The blog identifies key benefits to productized service offerings for software companies. These include:
- Increased Sales
- Time Efficiency
- Smarter and Easier Hiring
- Measurable Performance
The value of Productizing your Service Offering
Productized services are very relevant for software companies today. You can’t lose new customer deals because of service price objections; but also, you can’t afford to give away services. That team needs to generate cash or at least run breakeven. Most importantly, your customers need to be getting value from your product well before the renewal date which underscores the importance of building on-boarding service packages. Think about these points:
- Customer on-boarding is a growth barrier to most businesses. Getting faster and better at on-boarding will allow you to increase the rate of customer acquisition which increases recurring revenue.
- Reducing the cost of on-boarding gives you an opportunity to transfer services dollars into recurring revenue which is higher value revenue and repeating revenue.
- Predictable and well defined implementations make onboarding new employees infinitely easier and also reduce the customer support burden.
- Customers want these packages more than ever. They want immediate value from their tech investment, they want prescriptive implementations, they want low risk and cost assurance. By presenting a packaged offering you give them a path to change management and adoption, and they buy with confidence. It will inevitably result in higher win rates. Low win rates is what kills technology companies.
Where to start with Productized Service Offerings
Step 1: Create a killer offering
This is the easiest of the three steps and there are two ways to go about it.
A) Do a full market analysis interviewing customers, lost prospects, and competitive offerings. Figuring out the minimum product customers value most, and what they would pay for it.
B) Skip all that, and just take the last successful proposal that you’d be happy to repeat, and build out an offering from that.
There is value to both approaches. But being the pragmatic type that we are, our recommendation is the second approach. It will save you a month of work and you can iterate the offering as you gain experience. Just make sure you can answer these questions.
Scope & Effort
- Where did the customer get the most and least value from the experience?
- What scope could they live without?
- How many hours did it take to deliver the project?
- If you had to deliver the project with 25% less effort, what would you change?
Set a Price
When setting a price, it needs to be set somewhere between not losing your shirt, and the maximum amount that doesn’t impact win rates. Remember your services pricing will impact adoption of the software you are trying to sell. Setting prices too high drags on other revenue. Our recommendation. Set the price somewhere between your actual Cost + 40% gross margin and the first year’s ARR.
Example. If your average ARR is $20,000 the maximum package price should be that. Any bigger than that you should probably have a look at your software pricing model as it will be a red flag to buyers. So in this example, If your labor cost to implement the package is $5000, the minimum price is about $7,000. There is good reason for this range that we could go into at another point. Of course if you have infinite cash, you could do away with the minimum but that is just poor management.
Creating T-Shirt Size offerings
If your goal is to sell this offering on 80% of the transactions, you need to present a smaller package option, and larger option. This gives your sales team a release valve for when the question comes up in the buying process. “Oh, Mrs Prospect, you don’t have $10,000 budget to implement? No problem, we have a $5,000 option for you as well”. And on the other end, you don’t cut yourself out of opportunities where the buyer has very specific requirements or perceives their needs to be unique.
TekStack employs its own T-Shirt approach you can check out here. If you want to see how these packages translate into our PSA and CRM tool, we can always give you a demo.
Step 2: Manage with Intent
The next equally important step in providing productized service offerings for software companies is to rethink how your services team is managed, and how you manage projects. You’re effectively running your business as a fixed price shop. This transfers all the risk on to your organization, changes how your invoice, how you record revenue. You also need to provide your project team with very clearly defined SOW documents, tools to manage change, and providing coaching so they can get out of sticky conversations. You might need to rethink compensation.
Work from a single project plan template
When the sales team quotes this service product or ‘SKU’ they should have a standard project plan, and statement of work they can share with the customer. This is the same project plan your project team should inherit. The team shouldn’t be creating a new one each time. Doing this messes with the cost structure, budgeted hours by role, and scope. It also sets a poor expectation with the customer who already okayed the SOW as part of the agreement.
There are two types of changes. Changes that result from internal problems. Ex. bugs that force rework, or resources that need a skills rampup, or perhaps the project plan was just too aggressive in the first place. Regardless, the reason for this type of change needs to be tracked. Second type of change is scope change. This is where the customer wants more than was included in the proposal. If you charge for this change or now, the customer should be subject to a change request procedure, even if it’s a zero dollar change request. It sets a signal to the customer that you are serious about this stuff, and allows you to bank some goodwill that you can use down the line.
Give your team the tools to manage projects
This means getting rid of broken processes, and all spreadsheets!
Tracking project efforts
Dump your T&M metrics and start thinking in terms of project metrics that the team can actually control. The people that are doing the work can’t control revenue, but they can control effort and time. Measure the effort in hours, not days. At a task level they need to see budget, actual, estimate at completion, and variance. This information should be easily accessible to resources and project managers at all times.
At maximum, this should be done weekly, at best, it should be captured daily. Human memory wanes over time. Put controls in place to capture time.
Feedback on progress
In fixed price worlds, you need to know the actual effort, but also need to know if anything is at risk of completing within the budgeted amount. And you need that feedback early.
In addition to managing projects perfectly, you also need to make sure you are getting the most from your team. This means knowing what work is scheduled, what their availability is. Their roles and skills are important to track so that you can assign the right work. As project timelines change, this opens up availability pockets, or can drag on other projects. You want this information at your finger tips.
In a fixed price world, revenue recognition is a different beast. Invoicing is tied to milestones in the project, revenue recognition is based on the project progress. We’ll talk more on this another time, but it needs to be managed entirely differently so you don’t get caught writing off past revenue.
Step 3: Measuring your success
With good data comes great insights, or something like that. But seriously, timely data is critical to your business success. Spend time actioning the information versus finding the information. Here are the metrics we think you should care about most:
|Expressed as a %, at project and project task level
|Track budgeted, actual, proposed, and estimate at completion.
|Track budgeted, actual, proposed, and estimate at completion.
|Gross Margin, taken at baseline, and showing actual.
|Project Tasks requiring more time
|A list of tasks requiring more time than budgeted, with reasons
|New tasks, scope change.
|Amounts, status, how they are broken out, if they are conditional on customer approval
|What is the total value of the project, how much has been invoiced, what is the invoice status
|Expressed as a %, ideally in line to progress %
|What is the customer thinking? Tie NPS survey results to the project. Identify survey results based on customer’s role.
|The number of hours contracted (approved) but not yet assigned to a resource. Should be broken out by project, by role, and by project type.
|What is the planned revenue? Should only include work that is assigned to resources.
|Team Gross Margin
|Earned Value over Actual Labor Costs. Can be expressed as a %. Should be compared against planned revenue and expected costs. Compare this against the financial statement gross margin.
|How much work was completed in a period of time by the team? How does that progress translate into revenue?
|Ideally the same as Earned Value but building conservatism into revenue recognition is important in case you get behind on invoicing or projects are at risk.
|What was the utilization, represented as a %? Utilization is the amount worked on projects over the total capacity of the resource. Ideally you can look at this by role, by team, or at a resource level. How did the utilization booked compare against actual? What is my booked utilization in future periods?
|Upcoming Billing Milestones
|What billing milestones are coming up? How are those projects fairing? Billing Milestones drive invoice and cash collection, they don’t impact revenue recognition, but its good to make sure everything lines up.
|Are your customers happy? What is the NPS per project? How does that break out by customer team role (ex. Exec sponsors, project manager, user)? Is my customer NPS going up or down post implementation? Is my general trend positive over time?
|Accounting for the annual recurring revenue, what is the cost of supporting a customer post-go-live?
|Late & At-Risk Projects
|Simply a ready list of projects that are at-risk, late, or over-budget (actual effort variance)
|Task Category Variance
|Which task categories does my team struggle with? (ex. Analysis, configuration, testing, UAT, go-live support, project management)
|Which resources are habitually over budget on assigned tasks? How do they compare against like resources?
|Impact of Internal Projects
|What impact do other internal projects have on my team’s utilization? (ex. Customer events, sales, etc)
|Impact of Support Tasks
|What impact does customer support task assignment have on my team’s utilization?
Productized service offerings for software companies will result in increased win rates, increase customer satisfaction and stickiness therefore increasing retention and churn performance, they will also make more money in services, and be able to ramp up resources faster. It’s a good thing.
If you’d like to learn more about how TekStack can help, contact us today. Our software product gives you all the tools you need to do everything in this blog. If not, hopefully this blog gives you some tips that you can implement today.