Written by 4SYSTEMPublished on Updated on
Digital project management · 6 min reading
To choose a CMS, compare what your team will need to do, the rights that can be assigned to them, and the maintenance responsibilities. Then request a demo on your own tasks and check the data recovery. Choose the tool whose possibilities and constraints correspond to your organization, rather than the one which has the most functions.
Key points
- Assess real-world tasks, not just a prepared demonstration.
- Distinguish between publication, commercial management and administration rights.
- Clarify who maintains each component and what the offer covers.
- Test the export and its reuse before considering the data as recoverable.
Transforming needs into selection tests
A CMS, or content management system, is used to administer the contents of a site. For your comparison, start from what you actually publish and modify: service pages, articles, product pages, variants, documents or multilingual content. Also specify the necessary links with your stock, invoicing or customer relations tools.
Classify each need as essential, desirable, or unnecessary at this point. Then ask how it is covered: built-in function, extension, external application or specific development. Note the limitations and dependencies. An answer “it is possible” is not enough if it does not say with what, under what conditions and under whose responsibility.
Have the tool handled by its future user
Prepare representative content and ask the person responsible for it to create, edit and publish it. Observe the steps that require assistance. For a store, add a product change and an order fulfillment task. An attractive interface is not enough to make your team autonomous on a daily basis.
Compare access, not just number of accounts
Write down the responsibilities of collaborators: write, validate, publish, manage products, process orders, modify prices or administer technology. Then check that the rights can reflect this distribution without giving general access unnecessarily.
The official documentation of WordPress distinguishes between roles and capabilities. In its standard configuration, a contributor can prepare their articles without publishing them, while an editor can manage the publications of other users. Adaptations are possible: therefore check the rights actually configured on the proposed site.
Shopify also distinguishes several actions. Its store permissions documentation notably separates the creation or modification of products from the modification of their price. This example shows why “catalog access” remains too vague a description. The same documentation points out dependencies between permissions: also check automatically added rights and actions accessible via applications.
Check the authorized actions, but also those which must be refused. Ask how to remove access from an employee or service provider and how the company will maintain control of the owner account.
Choose a CMS with explicit responsibilities
Don't just compare tool names. Compare the specific offer: hosting, installed components, support and supported operations. For an installation managed by your company or its service provider, have updates, backups and controls assigned. For a hosted platform, ask what the operator manages and what remains your responsibility.
Have the scope of the offer detailed
Request a written response for added extensions, applications, themes and developments. Who happens if an integration stops working? Are bug fixes included? Do changes in content or functionality relate to another service? Who keeps the documentation necessary for a recovery?
Compare expense items with equal scope: subscription or hosting, licenses, maintenance, assistance, training and specific adaptations. Ask for detailed quotes rather than an isolated amount. No generic price can replace the analysis of the offer actually proposed.
Verify data recovery and reuse
Take inventory of what you will need to recover if you change tools or providers: content, media, products, customers, orders and configurations. For each set, ask for the available format and the recovery procedure. An exported file is not proof of complete re-import.
The documentation Shopify on backups and duplication specifies that exported commands cannot be imported through the administrator interface. The documentation mentions import by third-party applications or by API Shopify, while specifying that this procedure is not supported by Shopify. It is therefore necessary to check the scope and the assistance available. Have a relevant sample retake tested and document what would require further intervention.
Illustrative example: choosing for a sales team
This example is fictitious. A small store wishes to let its team enrich the product pages, while reserving the modification of prices to the sales manager. She also wants to recover her catalog if she changes her solution.
Instead of asking "which CMS is best?" », she submits the same scenario to the solutions envisaged: modifying a description with a limited account, attempting a price modification which must be refused, then exporting a product with its variants. Finally, she asks to show how this data would be reused. The choice is based on these results, the limits observed and the responsibilities proposed, not on the reputation of a tool.
Checklist before choosing
- The essential tasks have been demonstrated.
- Employees tested the operations that concern them.
- The necessary rights and restrictions have been checked.
- The technical additions and their dependencies are identified.
- The maintenance and support scope is written.
- The expense items are comparable between offers.
- Data recovery and recovery limits are documented.
Limitations and common errors
This method does not produce a universal ranking. A solution may suit one team and complicate the work of another. Avoid choosing only because a tool is known, confusing the availability of an extension with validation of its operation, or equating a hosted offer with a total absence of responsibilities. The possibilities must be checked on the configuration and the offer envisaged.
Frequently asked questions
Is an editorial CMS enough to sell?
Not on this criterion alone. Check which business functions are needed, how they are added, and the associated responsibilities. The management of pages does not demonstrate that of orders.
Does an open source CMS eliminate expenses?
Do not make this assumption. Consider hosting, possible licensing, maintenance, and support your team will need. Compare complete offers.
Can we still easily change CMS?
This needs to be checked. List the data, export formats and recovery conditions. Ask for a demo rather than a simple migration promise.
Next step: prepare a common scenario
Choose an editorial task, a commercial task if you sell online, and a significant access restriction. Submit these scenarios to each solution considered and keep the evidence, caveats and contractual responses in the same document.
Sources and resources
A FIRST EXCHANGE
A project to develop?
Tell us about your site, campaigns or emails. We will define with you the next actions to take.
