How to structure configuration changes/fixes
In the implementation project, a customer-specific configuration is built to connect to customers' systems. For us, often this configuration is complex and sometimes it is used even to cover up the lack of needed features in our products. Due to the complexity of those configurations, they are error-prone. Sometimes the configurations are incompatible with the new product versions, and sometimes minor errors have not been identified in the testing phase in the first place.
I have two questions regarding fixing these configuration errors:
- Would you consider this work to be billable or free of charge for customers
- Which would be the right team to perform the fixes (support, project delivery, change delivery, dedicated team for these, or something else)
Best Answer
-
I would consider three factors: 1. Advocate for your own company first, 2. Be transparent to your customer, and 3. Negotiate in advance. Where you land will depend on your position in the market and how important customer acquisition is.
- Advocate for your own company first. If it's the type of configuration your customer can access and troubleshoot with qualified resources, the best case scenario is to set expectations that after they test and accept it, it is their responsibility to support it, and any support you provide will be billable. As a rule, we support our product with our support group, which isn't billable, but complex configuration support is billable. If the customer either can't access the configuration for some reason, or it's so proprietary that you can't reasonably expect them to support it, give them the choice up front of proceeding with it at the risk of paying for support or bypassing it altogether as unsupported functionality.
- Be transparent to your customer. Before you start this type of configuration, have a conversation about the benefits and drawbacks and likelihood of needing support. If it's something you've not done a lot, tell them. If it's something you've done but know is fragile or subject to problems with upgrades, tell them. Give them enough information to make an informed decision as to whether they should proceed. In our business, it can be a net benefit to our customer and to us if they decide not to proceed with complex configuration likely to disrupt their operations or require ongoing support.
- Negotiate in advance. The worst outcome is to surprise your customer with billable support if they weren't expecting it. It's better to have the difficult conversation in advance than to defer it to later when they feel trapped and deceived. Even if you aren't willing to tell the customer "no" to the complex configuration if they are unwilling to pay for support, I would still position support as billable before conceding to free of charge support. Regardless of your position in the market, you still have a duty to advocate for your own organization's financial health first. There is nothing unethical about asking for compensation for costs incurred, so long as it is done transparently and in advance. Then, if you need to concede, the customer feels like they won an important negotiation.
As to who should be responsible for support, I would think this would be a factor of who is capable and who has capacity, which will vary by organization. I would prioritize the project delivery team last, since support requests will be unpredictable and disruptive to other customer schedule commitments.
4
Answers
-
Hello @Jaakko,
Thank you for reaching out to the TSIA Exchange with your questions regarding - How to structure
configuration changes/fixes? To get the conversation started, I’m reaching out to the following members for their insights on your questions.
Hi @Alex Vecino @Gayle Lassen @Alexander Mundorff @PatrickMartin @SteveCloughesy @steve tennant @Eileen Looi @Daniel Coullet @Justin Nuzum @SumitBhat @ShaunAdler What are your thoughts and insights you can share on this topic and questions?
Thank you,
Edly
0 -
Hello @Jaakko
Good post from @PaulRees which provides excellence guidance on the importance of transparency and the communications on this issue. Your sales, services, CS, Account Management teams would needed to be very aligned on the message. Here are a few additional things for consideration:
- Were the additional configurations needed to win the business in the first place, e.g. were they identified in the sales cycle and they formed a part of the scope-of-work ? If Yes, then arguably those should be chargeable / billable services work that is a part of the scoped implementation.
- Are the additional configurations always necessary or rather part of an "open-bar" approach to requirements gathering in services delivery? Often the delivery team is doing requirements gathering with open ended questioning because they consider their product "highly flexible" and so more and more requests come up during the implementation which are "nice to have" vs. "need to have".
- We have seen some companies group the config gaps into buckets which then are directed to product management / development for the roadmap.
- Many vendors fall into the technical debt trap causes by additional config that is then not compatible with newer versions. In the short term, usually it falls to a combination of the PS and Support team to navigate this. If this issue has grown, then you will have a need for a dedicated services team post implementation who specialist in migrations / upgrades. Otherwise this work becomes too disruptive to manage for standard services delivery who should be aligned to new implementations or larger expansions and support who should be aligned to product support and customer success.
- If additional config is necessary for a customer but can be managed longer term through dedicated support to help with upgrades, then would recommend a services package designed to support this. Your sales and services team should be transparent in what this services package is for, it must be branded separate to standard support - for example "Expert-on-Demand". One of our customers uses this service to specifically help them manage upgrades and configuration updates to ensure that their solution is always compatible with future versions.
Finally it would be really important to land on what your standardised product delivery should look like with more vanilla configuration that can scale both from a delivery perspective and that of the customers. Is it possible to generate a pre-packaged configuration that can be consistent.
1 -
Hi @Jaakko
Above posts cover the front-end considerations sufficiently. I can provide some insights on how to follow through for support:
- It is important to make sure you have a defined program to provide support for the customized part of the solution. Prior to creating a defined offering, we had multiple one-off contracts which listed different processes, SLAs etc., and soon became almost impossible to manage.
- The Custom Support is offered at an annual (or multiple year) price similar to support but clearly defining what is in and what is out. In our case, we did not cover enhancement requests which needed to be a separate SOW. The standard also does not include updates on custom pieces of solutions if they decided to update the underlying products. That needs to be a separate SOW as well.
- We used to have Delivery team take care of support of customization but it caused a lot of issues (some listed in other posts) but also creating two support paths for customers -- one for customization going to Delivery resources and other for the underlying products which was supported by the regular product support teams. We ended up setting up a team to support custom solutions so we utilize same support infrastructure and streamline cases between the custom support team and product support teams. It is hard to put the onus on customer to do the triage and call the right team.
Lastly, you need to invest in making sure there is appropriate knowledge transfer between the Delivery team and Support team.
Hope this helps.
Samir
2
