Contentstack executives had a wonderful time sharing an evening with our commercetools partner, catching up with friends in the retail industry and making new ones. The event, Headless Over Hell’s Kitchen, featured MACH-tails and a wine tasting assembled by Contentstack’s own COO, and certified sommelier, Matthew Baier.

MACH – Microservices, APIs, Cloud, and Headless – turned out to be a popular topic, and the penthouse suite overlooking New York City, was packed with industry experts, vendors, and brands considering or already embracing the new architecture, in this case for the retail industry. While the acronym, MACH, was new to some, the individual components – Microservices, APIs, Cloud, and Headless – were familiar terms and almost every visitor to the suite came with a point of view and some experience with the concepts.

Many conversations quickly turned into a discussion on how to implement MACH successfully: what use cases are good candidates, what are the best practices, what are some industry examples and comparisons, what is the vendor and partner landscape like, what skill set is needed to embrace MACH, and so on. Since the event was co-sponsored and attended by multiple vendors there was a refreshing mix of expert opinions representing multiple industries and market segments, which created active debates between retail brands and their agencies, technology vendors, and implementation partners.

All in all, it was an enjoyable evening, and a VIP alternative to other retail industry events happening in parallel, so thank you to everyone who joined us. And many thanks to our friends at commercetools for organizing the event and partnering with us to co-sponsor a wonderful and enlightening evening dedicated to the future of customer experience technology, MACH – Microservices, APIs, Cloud, and Headless.

Here is some recommended reading, if you’re interested in learning more about the impact MACH can have on the retail industry.

Your content is king. Yet, many enterprises find they are still searching for the best way to manage and optimize their content.

Whether you already have a CMS provider or are shopping around for a new one, take the strategic and smart move to evaluate your options. A CMS investment should be evaluated because it is exactly that – an investment. So it should be analyzed carefully, evaluated often, and questioned deliberately. For any platform handling your content, you guard, protect, and question it for the safety of the realm.

10 Important Questions to Ask Your CMS Provider

When evaluating a CMS vendor, determine if it’s the solution that’s ready for your organization now, and for the future, with these questions.

1) What enterprise expertise and experience exists at the company?

Look for experience working with (or at) large enterprises across all of the vendor’s business functions, including leadership, sales, product engineering and support organizations. Take notice if the vendor speaks your language and understands your challenges. The more experience the vendor has working with companies just like yours (e.g. same industry, similar size), the more they can relate to, anticipate and meet your requirements throughout your customer journey.

2) What processes exist in support of key enterprise concerns?

Verify that the vendor has and follows documented security and business continuity policies and procedures. Ask about relevant certifications, such as SOC 2 or GDPR compliance. Confirm the vendor has adequate insurance and operates with agreements (NDAs, MSAs etc.) conforming to industry standards.

The vendor should be financially viable. While this may seem obvious for some, it’s wise to peel back the layers. For a VC-funded startup without a long history, dig a little deeper into how sustainable their business model is. Hypergrowth often comes at the expense of a high burn rate, which could mean they have a limited run-rate. Conversely, legacy vendors that have shifted attention to other products may not be collecting significant enough revenue from their CMS anymore, so vendor size isn’t a guarantee for CMS longevity.

3) What capabilities and features do you have that specifically address enterprise needs?

There should be a long and thoughtful list of features that support enterprise requirements and concerns, including needs around service reliability, scalability, security, auditability, collaboration, workflows and global deployments. A CMS should appeal to both business and IT users. Ask about features that address the needs of your marketers, content managers, developers and IT. staff. Many CMS solutions favor one audience’s needs at the expense of another.

4) What support and service-level agreements are offered?

How many of the vendor’s customers (actual number or percentage) operate at each level? You don’t want to be the only mission-critical customer relying on and financing the vendor’s support infrastructure.

Understand what support levels and response times are offered. There’s many layers and levels of support – find out which one is right for your organization. Some implement 24x7 support, via a self-service on-line portal, or interacting with a chatbot or by live support via a qualified, human subject matter expert.

5) What is the concrete, ongoing commitment to innovation?

If the CMS is merely one of many different products, ask how resources are prioritized across the product portfolio. Look for the total number of CMS improvements in the previous 12 months and the general cadence of feature releases.

Ask how large the core engineering team is. If there are only a handful of developers working on the product (which can happen at both large or small vendors), this may be an indicator for lackluster future product enhancements. Be proactive and ask to see future development plans and feature roadmaps.

6) What is the historical performance and service uptime?

Look for publicly available service status information and historical outage data. Evaluate architecture, features and procedures that mitigate or eliminate the impact of a service outage to your sites and apps. In the event of a service issue, find out how it would it be communicated.

7) Why do developers like and choose your product?

Look for a rich library of tools, SDKs and thorough (ideally public) documentation. Ask about features that differentiate the CMS for technical users.

8) Why do content managers and marketers users like and choose your product?

Ask about features that differentiate the CMS for business users and evaluate the editor experience.

9) Can we run a POC?

The vendor should not only encourage you to try out their product before signing contracts, they should have a formal program to guide you through a quick and effective POC that validates (or adjusts) your assumptions about the CMS.

If the POC doesn’t demonstrate value in a matter of days, or if it seems complicated and requires specialist expertise – reconsider. Consider the POC a preview of your actual project experience. If the CMS doesn’t seem amazing at a reduced project scope, things will only get worse with a full-scale deployment.

10) What other customers do you have and can we speak to them?

Dig a little deeper than just the company logos on the website – determine if these are non-strategic projects (e.g. a microsite) or if the CMS is powering a mission critical digital property. Ask to speak to customers and take the time to check at least one to two peer references.

Try and find out where your use case falls on the scale of all of the vendors’ customers. You don’t want to be the largest – or most complex – deployment, or be the first company for a major new product option.