AWS Partner Network (APN) Blog

Building a Next-Gen AWS MSP’s Engineering, Support, and Relationship Management Teams

By Adrian SanMiguel, Principal Partner Solutions Architect at AWS 

Editor’s note: This is the third part of a popular series for AWS MSP Partners. Read Part 1 >> Part 2 >> Part 4

AWS MSP Program-1In my series on building a next-generation AWS Managed Service Provider (MSP), we have discussed the foundational tenets of next-gen MSPs and how to shape your teams so that you can deliver a successful AWS-based MSP offering to customers.

This series is for AWS Partner Network (APN) Partners who deliver hands-on, proactive, consultant-level support for Amazon Web Services (AWS) customers. Your organization probably has an MSP practice already, or are in the process of building one to help enable your customers’ cloud adoption journey.

In this latest part of the series, I will focus on your MSP’s engineering, relationship management, and professional services teams. In restaurant parlance, these areas are considered the “heart of the house” and where most of the magic happens.

These are the folks whose job it is to delight your customers and help them grow their business without having to worry about building or managing infrastructure.

Sticking with the restaurant analogy, imagine the customer service is great and the wine is wonderful. But when it comes time to eat, your steak is cold, the potatoes are burnt, and the assistant manager offered you just 5 percent off the bill as recompense, rather than just giving you the food you were hoping to have for dinner.

If this happens to you, you’re probably not going to go back to that restaurant again. The same is true for cloud customers and prospects. You may have an additional chance or two to make things right, but repeated missteps will cost you in the long run.

Building Your Product Engineering Team

If your company does not have a formal product engineering team, stop what you’re doing and please build one. You cannot succeed as an AWS MSP without a group of engineers who construct, maintain, and create the overall MSP offering. This team is the engine that moves the MSP, possessing deep knowledge of the AWS platform.

For most of our successful next-gen AWS MSPs, any changes to the organization’s managed services offering will go through the product engineering team. These folks are constantly iterating upon the MSP offer to make sure it’s compelling enough for new customers to consider you for their MSP needs.

To do this effectively, product engineering should work closely with your sales, alliance, and marketing teams. This helps align stakeholders and solve problems, enabling your company to proactively identify customers with unique use cases. If you find a use case that’s not currently served through your present-day MSP offer, product engineering has the tools and the know-how to create those opportunities and deliver for customers.

A general rule of thumb is to refine your MSP offer 4-5 times annually, and deliver at least two new go-to-market (GTM) campaigns each year. I have worked extensively with AWS MSPs, and my recommendation is to ask your customers what they want to see and work towards building out those new offerings.

For example, if your customer surveys are littered with comments such as “We’d like support on Amazon Connect,” then you should support Amazon Connect at a minimum viable product (MVP) level. Furthermore, you should work with the customers who are asking for this and allow them to shape your GTM, rather than creating it from scratch.

If you offer customers the ability to influence your roadmap, they will love you for it. Many APN Partners offer alpha or beta customers free or reduced MSP services for the new offering in exchange for feedback and steering of what the final GTM will look like. These partners usually request that participants also provide a case study or public reference on how they worked together to build something new.

Finally, your product engineering team must maintain strong relationships and tight feedback loops with AWS service teams to remain abreast of forthcoming product and service releases. I have seen it happen numerous times where an AWS MSP is caught off guard by something they should have known about. This can be remedied by working with your APN representatives to set up occasional check-ins with AWS service teams.

Please make it a priority to ensure you are having regular syncs with AWS Business Development Managers (BDMs) and Product Managers (PMs) who are working on services relevant to your AWS MSP offering.

Specializing in AWS Support

AWS-Partner-Network-Teams-`The heart of most next-gen MSP’s offer is their AWS support team, which consists of subject matter experts with significant experience working on the AWS platform.

The AWS support team is responsible for the tier 1, 2, and 3 support cases their customers log, and in programs such as partner-led enterprise support, the expectation is that 90 percent of all customer support cases are triaged and resolved by the MSP directly. This does not mean, however, that your support team is logging into instances and troubleshooting every single alert that comes in.

Ideally, you have created automated artificial intelligence (AI) and machine learning (ML)-based workflows to triage common issues and pain points. If your support model has humans doing too much of this work, you need to examine the hours your experts are outright wasting in this type of support model.

In 2017-2018, I worked with 20+ partners that estimated an average net loss of 38+ hours per shift (average of 114+ hours a day) where someone needed to log in to a customer’s instance because monitoring wasn’t right, or because there was no better way to do something.

Your support team should not be logging into customer instances unless absolutely necessary. It’s intrusive, and there are better ways to support your customers instead of poking and prodding a running instance.

If you must log in, take note of the actions and build a runbook/automation workflow to do that same thing the next time there’s a similar issue. Your staff time is better served adding a proactive support value, such as isolating single points of failure and making architecture recommendations to further improve customers’ experience on AWS.

Another component of your support team is the concept of a dedicated or lead engineer who is the primary technical contact for the customer. Some MSPs may offer a bench of engineers, but your organization can differentiate at the support level by making this type of individual available as a default, or as an add-on to the base MSP offer.

The dedicated or lead engineer knows the inner-workings of the customer account and functions as both a support engineer and solutions architect. These individuals are capable of deep dives on the technical platform, solutioning, and all points in between.

If you have AWS Enterprise Support, your dedicated or lead engineer may have a direct line to your Technical Account Manager (TAM). They also have the technical context for quick and efficient AWS Support escalations.

Tapping an AWS Relationship Manager

The role of your AWS relationship manager is to white-glove the handling of customer concerns. They conduct routine case reviews, conduct and provide Amazon EC2 Reserved Instance (RI) recommendations and guidance, coordinate proactive workshops and bootcamp session scheduling, and are responsible for establishing and maintaining key relationships with customers.

They should be focused on light technical needs, such as explaining how services function, and are usually paired with a dedicated or lead engineer, as well as an AWS seller, to comprise the customer’s formal account team.

Above all, the relationship manager’s core function is to ensure that your customers are kept happy. Most customers will not have a dedicated relationship manager until they cross a spending or complexity tier that requires a constant owner of the account’s relationship.

The relationship manager may be paired to your TAM and AWS Concierge, who is a senior customer service agent assigned to your account when you subscribe to AWS Enterprise Support. This alignment allows technical- and business-related escalations and concerns to be addressed in a timely fashion, such as limit increases, refunds, concessions, and whitelisting MSP customers for new service releases.

Without this integration and alignment, your relationship manager has to work through cases and be subject to target response times for every ask, including simple questions. During a customer’s downtime, minutes count, and being able to connect with your TAM in the middle of the night is an invaluable tool to have.

Excelling at AWS Professional Services

AWS-Partner-Network-Teams-2Lastly, you must have a capable AWS Professional Services team that is focused on AWS in a major way. They should be comprised of platform and migration/transformation specialists that are the best of the best you have to offer.

Your ProServe team is often the first technical encounter with customers, through a build and migrate phase, initial scoping and requirement gathering, or a Migration Readiness Assessment (MRA) and the subsequent Statement of Work (SOW) to perform the work.

It’s imperative this first touch gets it right the first time. A missed opportunity here can directly impact your MSP’s ability to do follow-on work, such as refactoring the workload to be migrated 18-24 months down the road.

Some MSPs may position their ProServe team as a for-hire group that offers paid migration, strategic engagement, training, and standards building on a recurring or ad hoc basis. Your AWS Professional Services team will be closely aligned with their PSA, PDM, and Professional Services teams at AWS.

Expected deliverables for your ProServe team are the creation of packaged offerings, strategic workshops, and on-demand training endeavors to further educate and empower customers along their cloud adoption journey.

Your ProServe team is the lynchpin to your MSP’s overall strategy of capturing revenue from prospects and creating a self-contained pipeline of work through close engagements with customers.

Without a solid ProServe bench, there is no opportunity for your MSP to have the next workload remediation. If an initial project ran over budget, over time, or was sloppily done, for example, there will be no next time.

Finally, your ProServe team may offer a consultant “on loan” for strategic customer endeavors as an additional service. This enables your customers to have a local resource on-site during a key migration or engagement.

Responsibilities for this individual range from training the customer and being available for “can’t fail” portions of migrations. Many MSP customers tell us these resources are invaluable and can easily justify the additional cost of having an on-site resource.

Conclusion

I hope this guide on how to build your MSP teams has been insightful and helps your company grow as a successful next-generation AWS Managed Services Provider (MSP). Each of the posts in the series thus far have explored ways that successful partners in the AWS MSP Partner Program are doing to grow and scale their teams out.

It all starts with the product engineering, relationship management, and professional services teams that will shape your MSP offer and delight your customers.

As always, please do not hesitate to reach out to the AWS MSP Partner Program at aws-msp@amazon.com.

Next Steps

In my next and final installment in this series of blog posts, I will explore a similar concept with the individuals responsible for acquiring, scoping, and selling your managed services. These are your solutions architects, sales, and marketing teams.

Check out these other stories in my series for AWS MSPs:

Additional resources for MSPs: