We have a client that is considering switching from Vonage to Thirdlane/3CX.
They HEAVILY rely on the mobile client and we lost this customer about 18 months ago because of the lack of backwards compatibility of the mobile client with older server versions.
As was discussed in this thread, https://www.thirdlane.com/forum/newbie-with-thirdlane, this is such a vital "feature".
Essentially, they got tired of waking up one morning or some random point in the day and their mobile phone Thirdlane client updated and they suddenly could no longer receive calls until the server could be updated. This amounted to a loss of ~200 extensions to Vonage.
They are willing to give us another try because Vonage obviously has a much higher price point, but not losing their mobile client connections to the phone server due to unknown and unplanned updates is an absolute hard requirement and something that even 3CX struggles with in some releases.
I could potentially bring these people back, but I would need to know if this is going to be implemented moving forward and when to set the proper expectations with the client so that can keep their trust in us.
Maintaining backward
Maintaining backward compatibility is an uphill battle - mapping features to versions, "graceful degradation", and tons of extra code and testing for every release. We have considered a few options, none of them were perfect.
Branded Thirdlane Connect that we now offer and already delivered to a few customers is the way to go as it allows you not only promote your brand, but to control and time the app and platform releases.
So if interested - contact us to discuss branding..
Issue is cost and the fact
Issue is cost and the fact that we more so specialize in providing dedicated single tenant VMs for each customer.
So it sounds like a branded client might be cost prohibitive as we would need 4-5 versions at least to replace our 3CX customers.
Maybe approach thing from the opposite direction and allow newer versions of Thirdlane SERVER to support older versions of Connect, this way you can push the updates to the server software ahead of the mobile app updates. The biggest issue is there is no notice whatsoever, you just wake up one day to non working software and a forum post that an update was released.
Pre-announcements was one of
Pre-announcements was one of the options we considered, and while we may make them any way, we don't see this as a real solution.
I am pretty sure that branding can be adopted to a variety of deployment scenarios.
I guess this will depend on
I guess this will depend on how you implement the fees for branding.
Every customer has different rules for updates and their sensitivities to testing updates. Some customers will test for 2 weeks before rolling out into production, others will wait 6-8 weeks of testing.
So to make branding the answer, we would need 4-5 different Google Play/Apple Store accounts. If we would have to pay a branding fee for each one, it probably would not make financial sense as the solution as some of the systems are 20-30 extensions.
This is one nice feature of the branded Connect app, which we recently rolled out. Now we control app/server updates and are not subject to this issue. If you want to learn more about it or discuss I’m happy to chat. We might be able to help with the issue using our version of the Connect app.