Winning deals in today’s market takes a lot of effort, as any MSP can tell you. Customers all have specific business needs, and to sell them on a UCC system, it’s vital for partners to know a way to solve those particular issues.
One of the foremost ways Wildix seeks to help partners in this regard is the Feature Request form, where we take suggestions for new features to implement in the Wildix system. Obviously, this is a tremendous opportunity for partners and is a pillar of our value statement: these suggestions are not only read, but when they’re taken in earnest, they’re seen by the entire tech support team (and even by the company CTO).
That said, Wildix has to prioritize certain requests over others, just because of limited time and resources. But that doesn’t mean when customers request a feature, you necessarily have to tell them “no.” Actually, if partners take charge of feature requests and approach them with the right knowledge, this process can become an opportunity to build customer relationships — yes, even when Wildix doesn’t directly implement a requested feature!
As such, this guide will help you better understand the ins and outs of the feature request process, both to make the best use of your time and to better secure deals and customer relationships.
The Request Process
When completed feature requests are submitted, they go directly to the Wildix Global Tech Support Team. This is significant because, within this process, there are no intermediaries involved; in all cases, it is only Wildix technicians and engineers who look over feature requests and decide on their viability.
The first stop for a completed feature request is to the Solution Architect Pool, a subdivision of the Support Team consisting of team leaders and third-level support experts. There, technicians consider the usability of submitted feature requests with the help of the sales department and, as appropriate, determine their priority in being implemented. Although this can usually be done without the assistance of Research and Development, that department can be contacted if further help is needed.
Which Requests Are Prioritized
As said before, Wildix support only has so much time, like any professionals. We just don’t have the capability to add every single feature that’s requested. In fact, the majority of requests for features end up rejected, which is why it’s all the more important to understand what features get prioritized.
Rejections aren’t done at random, of course. Most happen for the simple reason that most are financially not worth the team’s time. And that decision is made for two main reasons.
1. Can it be done by MSPs?
First, if a requested feature can already be done without much additional effort, it will rarely be a project that support takes on. This is because simple changes to the Wildix system aren’t worth a major time investment; configurations directly in the system are best left to MSPs if they don’t have much impact when unchanged and if they don’t take a lot of work to implement.
A large part of this is because one of the main points of value for the Wildix system is in its customization. Wildix can be deployed for many different purposes and under many different configurations, so making too many elements of it “the default” would defeat a major part of its purpose.
There are exceptions to this standard, however. Any such changes that are a security threat are critical to patch, even if the fix is easy on the MSP’s side, because the Wildix system always must have full security. Also, changes that would significantly improve the customer experience are important to implement.
Still, any changes that are easy to do during installation or upkeep will usually be a lower priority.
2. Will it bring revenue to customers?
Wildix is built with a specific purpose: increase the sales of end-user businesses. So when considering the potential benefits of a requested feature, we naturally put revenue first.
In other words, if a requested feature is a change that can’t be easily implemented by MSPs, the next consideration is whether it will be something that increases the profitability of the Wildix system. Some changes can easily save end-users time and money in processes or just increase efficiency, and of course these are the most valuable outcomes Wildix can hope for in implementing changes.
We should emphasize that the focus is less on the feature itself and more on the use case. That is, priority isn’t about how cool of a feature it might be, but on what the feature can do and how widely applicable it is. Features with a limited set of use cases won’t be a priority, just because of the lower benefit, while those with wider use and more overall use cases are most important.
Using Feature Requests for Sales
But of course, it’s obvious where the vast majority of feature requests come from; rather than something that Partners want, these typically come from the end-user side.
This is something we value, however. Passing an end-user’s request onto Wildix can be a valuable move. It represents sincere listening to the customer and a thorough attempt at engaging with them and their business issues.
More than that, it represents you acting as their dedicated service professional. Fulfilling requests personally is exactly the sort of valuable service an MSP should be providing, after all. And when applicable, and when achievable, using the feature request part of Wildix to carry out this part of customer relations can be very valuable. It’s easy enough, of course, to just tell your customer the request has been submitted and now it’s just a matter of time to see it implemented.
Taking up requests from customers is incredibly valuable for these very reasons, to be sure. However, relying too much on feature requests from Wildix can become more of an obstacle than an advantage.
Setting Expectations
The key to remember is that properly carrying out this positioning requires a strategic approach. As we just explained, not every feature request can be implemented, and the approach for deciding what to prioritize is accessible and standard.
But this isn’t worth considering just for Wildix’s sake. Actually, it’s important that you as a skilled MSP be able to determine yourself what times to consider a feature request and when to dismiss one.
For one thing, telling a customer their feature request won’t be accepted just makes for better relationships. Yes, it’s not easy to tell a customer “no” when they ask for some way to improve their business operations. However, what’s worse than telling a customer “no” upfront is telling them such long after they asked. If a client is waiting weeks or even months on a request’s status, only to find it’s been denied in the end, it amounts to them having waited and waited only to hear failure from you, a far worse outcome than an early refusal.
But more important is the matter of your own positioning. You as the MSP need to position yourself as a UCC expert to your customer: someone who knows all the value they’ll achieve through their UCC system, and someone who can implement that total value.
This goes back to that first criterion we listed: If the requested feature is something the partner can fulfill themselves, it’s generally better to let it simply be fulfilled as a custom setup instead of a Wildix update. Remember, to the end-user, the value of a local MSP is to have fast, creative service on call. Providing that yourself instead of going to your vendor is what will separate you as a valuable service provider for that business.
To Recap…
We have a questionnaire on the actual feature requests form that gives a solid idea of what exactly we’re looking for in implemented features. But just for a simple rundown, the features that do end up being implemented are ones that fulfill the following two requirements:
- Is it something partners can change in the system themselves?
- Will it bring more revenue to end-users?
The reason we at Wildix follow these guidelines is simply because our resources are limited, like any organization. But even with that in mind, there’s good reason not to overuse the feature request form when fulfilling requests from your customers.
Beyond simply setting your customers up for disappointment, submitting a feature request that doesn’t fulfill these criteria is wasting your own potential as a provider of valuable services. Yes, it’s valuable to serve as a connection between your customers and Wildix. But even more valuable is to just provide services on call, as needed, with your own creativity and input. From your customer’s point of view, it’s much better to get a feature or change implemented by the business they’re directly buying from, after all.
The most critical thing to consider about feature requests is they always present an opportunity to build customer relationships. Listening to these requests and advising customers on them honestly — that is, informing them whether the change can be done by you or by Wildix, or even if it can’t be done at all — will do a lot to reinforce your position as a technology expert in your market. Just set expectations realistically and remember that it’s you, not Wildix support, that your customers should see as most reliable.
For more tips on managing technology and customer relationships, subscribe to receive our magazine for free!