LandlordMax Customer Testimonial
Yesterday I just the follow great testimonial from Becky Rivera. Thank you for the great compliment! You can expect to see it on our LandlordMax Testimonial and Success Stories page very shortly.
“Thank you so much for your prompt response and accomadating service!!!!! I’ve read the testimonials on your website and I can see why your clients are so pleased with your software and service. This response made my day and I really appreciate you solving my problem so quickly.
THANK YOU, THANK YOU, THANK YOU!!!”
Becky Rivera
Permalink to this article Discussions (0)
Should We Release Now?
A common question with software companies is when to release the next version of their software. Should it be as soon as enough new features and benefits are available that people will be interested in? Should it be when there’s enough value that virtually everyone will want to purchase an upgrade rather than only a percentage? Should it be every month? Should it be once every year, two years, etc.? This is a very hard question to answer and every software company handles it differently.
Not only does every company handle it differently, but sometimes different releases of the same product/project are handled differently! And this happens to be the case with this latest version of LandlordMax. Normally I only like to release a major version of LandlordMax when we’ve added enough new features that it will excite a large percentage of our customers! If it’s only a few features, we sometimes will just release that as a patch, but I generally like to push features to major releases.
This particular upcoming release will be different than usual in that it’s only been a short time since the last release. Although version 2.12 states that it was released in December, it was actually released in April. That means it’s been just 6 months, which is very quick for a new major release. Is it too soon is the better question! And this is where I’m facing a very big delimna which I’ve finally resolved over the last few weeks.
I’m sure you’re wondering why it was a difficult choice, and I’m going to explain why right now. In the upcoming version we’ve added several features that have a major impact on how people perform their daily tasks. One of these features is the “Late” button shown in this animated tutorial. Although this is just a simple button, the amount of effort it will save some of our customers is significant. Another small feature that has large implications is that when you now create a new lease, a scheduled accounting entry will also automatically be created for you. The more tenants (ie. leases) you have, the more beneficial this quickly becomes. For some of our larger customers with hundreds of tenants, this is a huge benefit!
On top of this we’ve added many other features. I don’t want to divulge everything yet, but another major new feature is the ability to create, store, and print receipts. This is a whole new section that many people requested. We’ve also added date formatting, some preference settings, etc.
As well, we’ve done a lot of very significant performance enhancements. Between version 2.12b and version 2.12c we initially did some amazing performance enhancements, as much as an order of magnitude faster for many screens (that’s 10x faster performance!). Well in this version we did another order of magnitude in performance for most data and list screens! We ran a test database with over 2000 tenants, over 2000 units, over 5000 workorders, over 5000 receipts and invoices, over 50,000 accounting entries, and all the related data. I can assure you that the larger your database, the more significant the performance enhancements! Some screens have improvements where the display is virtually instantenous for larger tables (under 1/2 second)! We’ve improved the speed of the UI (User Interface) and the database calls (which I’ll probably write about the later very shortly). All in all, there are some very significant performance enhancements in this upcoming version!
Now you’re probably still asking yourself where’s the dilemma? The dilemma is that we wanted to add two other new and very powerful features for this upcoming version. The problem is that neither of these features is going to be ready for at least 2 more months. So do we wait 2 months for these two features or do we go ahead and release now with all the great features and benefits we’ve already implemented?
You still don’t get the dilemma? The dilemma is that if we release now, we might now also want to release the other two great features in 2 months. Releasing major versions too often will annoy your customers! Nobody wants to be upgrading every other day. So if we release now, then when do we release the two other major features? In case you’re wondering, these are very highly requested features, so I believe they will have a significant impact on sales and customer happiness.
So we can postpone the release for 2-3 months, which means we lose revenue (opportunity cost) as with every new version, every new features, we increase our sales. If we release in 2-3 months, I personally believe that these two new features will generate additional significant sales by themselves! So we want those in sooner than later too. So if we release now, do we push those features to the next major release to avoid having too many upgrades and annoy our customers or do we release them in 2 months? Which do we do?
As well, each release has technical support costs. Although our upgrades are fairly easy to do, all you need to do is re-install the software overtop the old one (the database is automatically converted for you), many of our customers still require technical support. What you have to understand is that many of our customers aren’t all technically literate (we do offer the easiest property management software after all!), which means it will convert to some extra technical support costs for us. This adds to the equation in that more releases is more expensive.
So just to recap as this is fairly complex, here are our three choices:
1. Release today missing two major features. Re-release again in 2-3 months as another major upgrade (knowing that people don’t like too many new major releases, and that there will be additional technical support costs).
2. Release today missing two major features. Push the 2 major features into the next major release several months away, even possibly as long as a year (and lose the additional sales for that time).
3. Release in 2-3 months and withold all the great features we’ve already built. This also means we’ll lose additional sales during 2-3 months.
As an extra factor, September to April is our busiest time (they’re multiples of the rest of the year). So these 2-3 months are right in the middle of where we make most of our yearly revenue! This means that 2-3 months is actually like 6 months for most businesses!
Which would you choose? I personally opted for option 1. I’m willing to absorb the extra support costs that come with each upgrade because I think the additional revenue during our busy season will outweigh them. I also believe that we shouldn’t hold back our current features for these two other features, no matter how great they are! I don’t care if they’re pure gold, we already have so many highly requested features that I’d like to get them out there now rather than later. The other two features are important enough to me that I don’t want to wait until another major version, I’d rather release them as another upgrade in 2-3 months. They’re big enough to warrant an upgrade rather than a patch, but I’m not willing to wait for the next major release.
Which option would you take with these assumptions?
Permalink to this article Discussions (9)
Animated Tutorials Follow-up
I’ve already alluded to the idea that we were going to start providing animated tutorials for LandlordMax in the past on this blog. We currently have one such animated tutorial we use to help people who have problems entering in their license information when they purchase LandlordMax, but we haven’t published any others yet. The reality is that we’ve started to create them, but we decided to wait until the next major version is available to start releasing them (which although I can’t promise, is looking like it will be in November).
For those of you who are interested in getting a sneak peak behind the scenes, here’s one of the latest ones which I personally created that shows how to process your regularly scheduled accounting entries within LandlordMax, like the monthly rents you collect from your tenants. Just a quick note though, this tutorial is just not productized, which is to say it hasn’t been cleaned up, no introduction title has been added, etc. But at least it gives you a good idea of what to expect in the future.
A few other quick things about the tutorial, the “Late” button described in the tutorial is not available in the current version 2.12, this will only be available in the next major upgrade (the upcoming one I just mentioned earlier). As well, the “Receipts” button on the left menu is also only available in the new version. Lastly, some of you may have noticed the date format is different, in the new version you’ll now be able to select 1 of several different formats.
Let me know what you think. Did you find it useful?
Permalink to this article Discussions (0)
LandlordMax Customer Testimonial
There’s nothing I love more than receiving customer testimonials, and we just got another great one on Friday from Gloria Spencer that we’ll shortly be posting to LandlordMax’s Success Stories and Testimonials webpage. Thank you for the great compliment Gloria!
“You have been extremely helpful and quick with your responses. I will inform my friends, associates, etc who have investments property about my experiences with you.”
Gloria Spencer
Permalink to this article Discussions (2)
Record Day!
I thought Tuesday this week (October 24, 2006) was a great day, but it turns out to be greater than I initially thought! We broke and tied many records that day, both LandlordMax and FollowSteph:
- Broke our sales record for the most units sold in a single month (and there’s still a week left).
- Broke our sales record for the most revenue in a single month (with upgrades, etc., the number of units doesn’t always directly correspond with total revenue).
- Tied our one day sales record for the most units sold.
- Broke our one day sales record for the most revenue.
- Broke the record for the most unique visitors in a single month (and there’s still a week left).
All in all a great day. I initially knew we broke the sales record for the month but I hadn’t realized we also hit the daily sales records too. Not to mention FollowSteph’s traffic growth which has been growing at a pretty consistent 20-30% a month average for the last year almost. Tuesday was a great day!
Permalink to this article Discussions (3)
Business versus Technical Solutions
Last week I published an article here entitled “LandlordMax’s Most Challenging Bug” which received lots of comments both online and through personal emails (probably more people sent emails than commented). One thing that really struck me was the difference in thinking between people who run a business (from small ISV owners to managers) and technical people (developers, architects, etc.). Based on their background the solutions varied substantially. I’m not talking how to tackle the problem technically (btw there were some great tips and information being shared, thank you!), there was no doubt there was a lot of variation here, but I’m talking in terms of what types of solutions made economical sense.
What really struck me is that most developers completely ignored the cost to benefit side of the equation! I’m not saying that you should always base your decision on cost to benefits (I don’t want to acquire design debt for example), but sometimes this becomes a strong factor in the decision making. This is something that I use to lack, I always wanted to get in there and find the correct technical solution. The reality is that sometimes it’s not the right thing to do. This is a hard pill for technical people to swallow. I know it use to be for me. Not so much anymore being a lot more on the business side of things, but in the past it was a common issue.
Using my last article as a basis for this argument, let’s look at the cost to benefit of different types of solutions. Not actual solutions, but cost to benefits of the types of solutions. Rather than share my actual numbers, let’s just round realistic numbers to make the calculations, it’ll be much easier that way. So our first assumption is that allocating a developer to a task for 1 full day will cost $1000 in immediate salary. We should of course add in the costs of benefits, hardware, software, training, testing, etc., but for now let’s just say it’s $1000/day for a developer. Now remember this cost does not include any testing!
Ok, now I’ll assume that our fictional company makes $1 million in revenue a year, a simple round number. Assuming we have a unit price of $150 per unit, then this means we sell 6667 units per year.
Now before I proceed, let me backtrack a little. For those of you who are interested, you can read the full article here. However, just to get everyone up to speed, here’s the quick version. We found a bug in LandlordMax regarding how it reads certain types of JPG images. This bug is also present in many larger software application such as Internet Explorer and FireFox, so it’s not a simple solution. Also, images aren’t part of our core functionality. Don’t get me wrong, they’re a great feature, but we didn’t have them in the first 3 major versions. Now the problem is that we have two solutions, one that’s quicker to implement and one that isn’t. This problem only affects 0.05% of our total customers, and of those 90% will be satisfied with this solution. The other solution is complex, will take more than a week or two, and probably won’t fully work (IE and FireFox with very large resources still don’t have it full working). This solution will satisfy 90% of those customers too, possibly more.
Using these parameters, we can see there are two sides to this coin. Most technical people will want to fully solve the issue, to get it right. Yes the costs are high, but let’s do it right. The business side want’s to see what’s the cost to benefit. Now just a quick side step, you have to remember that you can’t always just look at the cost to benefit otherwise you’ll get so far into design debt that you’ll eventually kill your company. However, in this case, we’re not very likely to expand on this issue once it’s solved so it’s very unlikely that we’ll add any design debt no matter what solution we decide.
In any case, let’s look at the two solutions.
Solution 1:
An acceptable solution to the problem which will take about 1/2 a developer day, padded to 1 full day for safety. In this case, the cost is $1000. Now if we calculate it terms of cost to benefit, it means we’re paying $1000 for 0.05% of our 6667 customers, or 333 customers. On average, this means that we’re paying $3.33 to add this solution for these customers, of which 90% will be ok with the solution. The remainder would like a better solution but will probably live with it since this is only a small part of why their using the software, after all this is not the core functionality of the software. Also remember that these few people who are used to using this type of image mode also use to having this issue with a number of other major software applications. So it’s nothing new.
Solution 2:
We provide as best a technical solution as we can, knowing that we probably won’t be able to solve it fully as other software companies with budgets multiple orders of magnitude bigger larger than our total revenue can’t solve it. We’d be lucky to spend only a week, probably 2 weeks, and this might only reduce the number of people facing the issue by a percentage. But let’s be optimistic and say that we’ll solve it for 90% of the people who use this image mode.
Then in this case, we’ll spend 10 developer days, $10,000, to solve it. This means that it costs us $10,000 for our 333 customers. On average, this means we spend $30 per customer on this solution alone. This is now a significant percentage of the purchase price (20% of the total purchase price for fixing a small bug). But again, remember that it’s only for 90% of these 333, so we’re only really solving it for 300 people, bringing our per customer solution price to $33.33, or 22% of the total purchase price. We still have to deal with the remainder 10%, or 33 people. Assuming we use solution 1 for the remainder, this now brings up our price to $11,000, $10,000 for the initial solution and $1,000 for the remainder. Our total price per customer is now $33 for just this bug fix, or 22% of the total purchase price.
Which Solution is Right?
Which of these two solutions would you be more inclined to implement from a business side? What about from a technical side?
From a technical side, at least from my experience, we always want the perfect solution. But from a business side, it makes a lot more sence to go with solution 1. And don’t forget, solution 2 is probably a lot more costly than we estimated, it might take us a month, maybe two, or what if it’s a never ending series of issues? If the solution takes two months, which is not so hard to imagine once you see how Mozilla (FireFox) solved it (and that’s not even fully working), that brings our cost per customer to approximately $120 per customer. We’re now at 80% of the total purchase price for just one bug fix that’s not critical! Yes it’s only a portion of the customer, yes we could amortize it, yes we could calculate in the total lifetime purchases of the customer, and so on. But looking at the numbers when the first scenario is perfectly acceptable, I just can’t see how I can justify scenario 2.
As a developer, I can easily find ways to justify solution 2 such as design debt, etc. But from a business perspective solution 2 makes no sense!
UPDATE: Now add to solution 1 the fact that we now have an additional 9-10 developer days to add more features and benefits to the software. Let’s say we can increase our sales by 2% by instead allocating this same developer for the time difference to a new highly requested feature (maybe it’s only 1%, maybe it’s 10%, in any case, we’ll just use 2% since it’s easily feasible). If that’s the case, we can increase our sales of $1 million to $1,020,000, or by $20,000. Now not only have we paid for our bug fix, we’ve also paid for our developer and made a profit!
And the thing to remember here is that we’re not just helping 0.05% of the people (which we are), we’re also making 100% of the all our customers happier with a new feature (well maybe not 100%, but a much much larger percentage than 0.05%) that they wanted!
Permalink to this article Discussions (13)
LandlordMax's Most Challenging Bug
In the last little while we started to receive the same error/bug report coming through the Error Reporting functionality within LandlordMax. The error coming back was:
Error refreshing logo image javax.imageio.IIOException : Unsupported Image Type
Now this seemed weird to us, because we had all kinds of validations on which types of images to accept within LandlordMax. Before I proceed, to give you some context, LandlordMax has the ability to import pictures (jpg’s and gif’s only) into it’s database for 2 things. You can import an image for your logo/letterhead which will appear at the top of all your reports, which is great for the property management companies that purchase LandlordMax (about 50-65% of our customer base). The other area where you can add pictures is for your tenants, buildings, and units. This is a new feature that many people requested and that we added with version 2.12.
Getting back to this bug, we added all kinds of validation checks when you import images, such as the file extension (does it end with .gif, .jpg, .jpeg, etc.). We also added validations where it tries to first read the file, in case someone tried to manually change the file extension. And so on. Basically a lot of validation checks!
Initially we received some error reports such as the one listed above, and we found that we had missed a few potential validation checks, which we added with one of the patches (version 2.12a). That did significantly reduce the number of error reports, but they didn’t fully go away. Of course not everyone upgrades right away, but with time it seemed to dwindle down very significantly to just a few random ones. However, like I had just said, it didn’t completely go away which we don’t like to see.
Yesterday, we were finally fortunate enough to have someone also send us their email address (an optional parameter in the Error Reporting Dialog Window) along with the Error Report. This was great for us in that we finally had a repeatable test case for this very elusive bug that we couldn’t replicate, and that was extremely rare. We immediately contacted this customer and had her send us the image she used for the logo/letterhead as we tracked it down to a specific line in the code. We got the image, saved it, and added it to our test database. No problems, no errors, no issues! What? That didn’t make sense.
We then contacted her saying we couldn’t reproduce the error and we would be very appreciative if she could send us her database so that we could investigate it in detail. She obliged us and when we immediately tried it we got the exact error. It didn’t make any sense…
So the next step was to manually extract the image from her database into an image file and try that. I know she already sent us the image, but you never know. We extracted the image and opened it up with an image viewing tool without any issues. Very confusing… This image opens up in our image viewing software but not in LandlordMax.
So we dug deeper. Nothing. I personally spent several hours looking at this issue with no luck. So onto the internet and Google Search. After another hour or two, I found a weird bug report from Sun (Bug ID# 5100094). This was the key to the issue. It appears that the Java language doesn’t support JPG images that were saved in CMYK mode and threw this exact exception. Like most people, I know what a JPG image is, but I don’t know the details of how it’s encoded, nor do I really want to know. Now I was forced to find out more about this.
Without getting into too many technical details, it appears that JPG’s can be encoded from a number of modes, with RGB being the most common by far, or at least that’s my understanding. CMYK mode exist, but it’s not very commonly used.
Therefore I quickly checked the images, and low and behold, the image I had extracted from the database was encoded in CMYK! But what about the image she had sent me before? Well I did some further investigation, and to show you just how prevalent RGB mode is, the image she had sent me was in RGB mode. I don’t know if it’s the browser that converted the image or what, but when I did “Save image as…” it saved it in RGB mode. I did some further testing, and when I saved the image in CMYK mode, both browsers weren’t always happy with the image (depending on how exactly I saved it). That was very surprising to me. So it wasn’t only LandlordMax that had difficulties with this image mode sometimes, the major internet browsers also did!
As soon as I converted the image to RGB mode, everything went smoothly and with no issue. This was probably the most brutal bug I’ve ever encountered (omitting concurrency issues and such and just limiting it to straight bugs). It wasn’t an issue with the software, so it wasn’t possible to track down in the code. It was an issue with the image file and the programming language’s support of the image type. The error message wasn’t very indicative of the error as it usual is. And I also can’t blame the Java language either if both the major internet browsers had difficulties with this image mode.
So now what are the options for LandlordMax? This particular mode is not supported by the programming language. Do we look for a third party component and buy it? This is a very expensive solution, it costs a lot of money, not to mention the integration time (which is probably going to cost more than the component)? Will it have other bugs? Testing costs… For the percentage of users, I don’t think this is a viable solution.
Right now I’m personally leaning towards doing an extra validation and trying to invisibly render it from the file directly before accepting it. I’m leaning towards it, I’m not satisfied with it yet as it will have a lot of performance overhead, every new image will have to be rendered before being accepted… Imagine if you add 100 pictures for your building unit and each one has to be rendered. Rather than take a few seconds to a minute to import, it could now take 5-10 or more minutes easily. Is it worth it? Could I do a check after the fact, when trying to render it? That’s a possible solution also but it opens up a whole other can of worms…
The reality is that we don’t yet have a solution to this issue. We’re going to further investigate our options and definitely solve it for the next major upgrade, which is now expected to be out next month rather than this month. This is probably the most challenging bug I’ve encountered simply because it was absolutely unobvious what the issue was, there was no way to track it down in the code, and there is no real, or obvious, solution to it.
For those of you who don’t program, I hope this gives you an idea of the effort that goes into producing a software like LandlordMax Property Management Software. And although this is probably the most challenging bug I’ve ever encountered, it’s also one of the most interesting because of its difficulty!
Permalink to this article Discussions (30)
LandlordMax Customer Testimonial
Today we just received the following great LandlordMax testimonial from Jennifer Beaton which I’d like to share with you:
“I have been using LandlordMax for over a year a now. I manage 54 doors and can’t imagine what type of spreadsheet I would need if I didn’t have LandlordMax. It is very easy to use and has a wide variety of reports that gives me the information that I need to provide reports to my clients on a monthly basis. Excellent product with a great price! Keep up the hard work!!”
Jennifer BeatonProperty Manager
ARCA Property Management Inc.
Permalink to this article Discussions (0)
Is Technical Phone Support a Viable Option for a Software Company?
Yes and no.
Yes, in that it lets you get closer to your customers. There’s nothing quite like talking to your customers one on one to find out exactly what they think of your product, of your company, how they found you, and everything else. Having a phone number also gives some credibility to your company.
No, because phone support is extremely costly. Most people don’t realize it, but phone support is several times more expensive than online support for the same customer base! As well, although it increases the sales, it’s nowhere near in proportion to the extra costs. I now understand why pretty much every software company charges for phone support.
So is it a viable option? Maybe… Rather than debate the hypothetical, I’m going to share our latest experience with free phone support and our prototype project here at LandlordMax. There’s nothing better than a case study! The results might be different for you and your company, but this is what happened for us.
When I first started LandlordMax, I offered support through email only. In the beginning it was pretty simple, I could manage it all through my email client. As the company grew, the support needs grew where we ended up purchasing a customer support system called FogBugz (allowing multiple people to manage support through a web application). As our needs continued to grow and exceeded even this software (we still actively use it for project management and bug tracking, it’s strong suite), we moved up to HelpSpot which is focused on customer service. This is an online system which accepts requests by email, through online forms, etc. All requests are allocated a ticket number and everyone also receives an online link where they can view the details of the request directly online if they want (including every detail, from how long it took to respond, and so on). This is great because it alleviates a lot of the issues with people who have very aggressive spam filters (because we’re a real estate based business, sometimes we need to use words such as “mortgage”, etc., which are often wrongly picked up as spam by email filters).
Because of the way our customer service system works, we’re able to offer free unlimited online support which is guaranteed to be answered within 1-2 business days (generally we answer it on the same day). This is great because most of our competitors charge for ANY support, and some quite a bit! Never mind phone support which I’ll get to in a minute.
About three months ago we decided that we wanted to start offering free phone support to our customers. Up until now, that is for the past 3-4 years, as I just described, we’ve been offering online support only (email, web forms, etc.). We wanted to see if it made a difference, how much, and if we could offer it for free. You see, although I could charge for phone support like our competitors, I really don’t like this option. To give you an idea of the market, most of our competitors charge between $100-200/hour for phone support!!! Some only offer email support if you buy a support contract. Another competitor will only sell you their software if you also buy a minimum support service package of $200! Personally I don’t believe in this. If you buy a product, you shouldn’t have to pay to get some help in answering your questions. I understand there is a place for premium support, for example a guaranteed response within 24 hours, etc., but this wasn’t out goal today.
I also do understand the business behind it, phone support does cost money. And let me assure you, it really does cost quite a bit. Not just in technology or service costs, but in man-hours! Man-hours are your largest cost factor, no doubt about it. Anyways, what we decided to do was offer free unlimited phone support for 3 months as a trial experiment to see if it was a viable option for us. Hopefully by offering phone support this would increase our customer’s happiness, and hence increase our sales. We also decided to use 3 months because it gives it some time to build momemtum As well, perhaps we’d also be able to add some extra sales from people who were more timid about purchasing software from a website and would rather purchase it over the phone.
That was three months ago. Today I know the results. So let’s look at the results of our experiment. Although I’m not going to share the detailed metrics, here’s a summary of what happened:
- The average time to support a customer increased significantly over the phone versus online support. There’s nothing wrong here, it’s just the way it is. I would say that on average the time spent responding to a customer increases by 2-10 times. This can be attributed to the fact that some people ask more questions on the phone, some wish for you to wait while proceeding through the steps (for example waiting for the purchase email to make it through), sometimes you wish to wait to verify that the customers issue is fully resolved, and so on. Overall I would say this is fairly accurate metric for us.
- For each person who answers the phone you need to train them in your software. This includes how it works, how to properly answer questions, what the procedures and policies are, etc. To achieve a good support level this is not a small task.
- With phone support, although we don’t promise an immediate answer (we keep the same guarantee of 1-2 business days), phone calls break people’s workflow, their rhythm. For every break in concentration expect between 15-30 minutes of lost time to get back to the same productive state. With online support this can be drastically reduced by answering requests in batches during breaks, or what we list to call “mental breaks” (where you need to look at something different to give you brain a break). By doing this we keep all support responses in blocks and greatly increase overall productivity!
- Long distances phone charges do add up… We’re using a VOIP system but that’s also not without it’s own costs.
- Sales have increased, but nowhere near in proportion to the extra costs (especially if you add in the time costs). I’d say that we’ve barely increased sales by 10% and almost multiplied our support costs by 5-6 times. Therefore it doesn’t make sense to spend 5-6 times more money to make 10% more!
- One thing that you really benefit from is that you get real live customer feedback about your software. I personally found that when I was on the phone, people told me a lot more about what they liked and didn’t like about the software right away. They also told me what their biggest pains where, which is golden! Which features do you think we’re going to add next? Probably where our customers biggest pains are!
Therefore, weighing in the pros and cons, it looks like we’re going to discontinue free phone support. Actually at this time, we’re going to discontinue all phone support. We’ll probably try it again in the future, things do change, but for now it just doesn’t make economical sense.
I can already hear some people saying why don’t you just offer paid phone support for those customers who want it. This way you don’t have to build it into your price and those that are interested can pay. The reality is that I’ve found that only about 7% of our customers (combined with pre-sales) use phone support. I can’t speak for every industry, but assuming these numbers, and the fact that we’d have to charge, I believe that the total percentage of people who would use paid phone support would drop significantly. Because there is a minimum fixed cost associated to having a call center, we’d still have to charge a minimum fee per call to just cover the costs. Assuming only 10% of the people who use phone support would be willing to pay the fee (I’d guess around $100/hour), then that would mean 0.7% of all customers would use this service. I’m not willing to risk the significant amount of capital it would take (we’d now also have to add a billing system to our phone system) to support 0.7% of our customers. At that point, unfortunately, I’d have to welcome them to purchase from our competitors.
As you can see, it’s not that I don’t want to offer phone support for LandlordMax, it’s just that it’s not a viable option for us. And yes I understand that some people will not purchase anything from a company that doesn’t offer phone support, but that’s ok. I’m willing to lose that very very small percentage of customers. Assuming they’re 10% of the 0.7% of customers willing to pay for phone support, we’d be losing 0.07% of our potential customers.
Therefore, to answer the question based on our experiment, is it viable for software companies to offer technical phone support. Again the answer is yes and no. It depends on your market and who you are:
Software under $100
I seriously doubt you can do it for free. I also doubt you can charge for it either! Unless you have economies of scale and you can seriously amortize your costs, no one is going to pay you the price of your software for assistance! And if you did offer phone support, it couldn’t be more than one call for free at best, if that. I looked up Quicken, a large company that can use the advantage of economies of scale, and they only offer free phone support for installation, purchase related questions, etc. After that, any help within the software (for example how to setup a bank, etc.) will cost you $24.95 per issue, or 86% of the purchase price!
Software between $100-$250
You’d still be hard pressed, but you might have a chance. Of course you could only offer one incident at most, and every additional call would have to be charged. Also if your company is smaller than a medium sized company ($10 million plus in annual revenue), I just don’t see how you could offer free phone support.
Software between $250-$1000
Possibly. Here’s where it gets interesting. I think in this case the industry and specifics of the software will determine whether you can or not. To give you an idea of just how difficult it still is at this level of pricing, Microsoft Office only offers you two free phone support sessions and then they charge you $35 per additional incident, all this for a product that costs $399 for the “standard” edition!
Software over $1000
Generally software over $1000 comes with some sort of SLA (Service Level Agreement). The more expensive the more comprehensive the agreement. Under $5000 it will be somewhat limited, but over $30,000 it becomes generally becomes much more comprehensive (before LandlordMax I had only worked with one company that sold software for under $30,000). Often in these markets there are a limited number of customers, and the vast majority are corporations where phone support is expected as part of the SLA (wouldn’t you expect it if you paid $1 million for a software package).
So all said and done, looking at our cost to benefit ratios, it looks like we’ll have to end our phone support for now. There’s not much to debate about. Like I said earlier, we’ll probably try it again in the future, maybe next year… I don’t know. But for now, we’re going to go back to online support only (email, online forms, etc.). I just can’t justify the substantial extra costs for the amount of extra revenue it provides. This would be like asking a landlord to build a private pool for each apartment unit to generate an extra 10% in revenue. It just wouldn’t make sense, landlords don’t do that.
To quickly end the discussion, since I know some people will ask, do you regret experimenting with offering phone support? Absolutely not! I think every business is different, and every business should try it! You can’t grow without trying. Michael Jordan didn’t just start scoring baskets on day one, he tried a lot of things before he figured out just what worked for him. So try things, test what works and doesn’t for your company. Maybe you’ll have very different results than we did at LandlordMax. Please comment if you did, I’d love to hear about it.
Permalink to this article Discussions (15)
Should You Use a Code Profiler?
If you’re a software developers, absolutely!!! No doubt about it!
Before I go on, let me just take a step back to explain what a code profiler is to those that aren’t familiar with the term since a lot of you here also aren’t software developers. And surprisingly, a lot of software developers have no idea what a code profiler is!
A code profiler is a software application that helps you find performance bottlenecks, pin down memory leaks and resolve threading issues in your software application. So in other words, it’s a tool that helps you find where your own software needs the most improvement.
You would think that with today’s amazingly fast machines you wouldn’t need to worry so much about performance or memory (threading is something you always have to worry about). Yes, that’s partially true, but not always! For LandlordMax, as the database becomes progressively larger, so does the importance of running a code profiler. As some of you may have noticed, we’ve really been pushing performance enhancements recently (for example: here and here), and there’s a reason why. When we initially ran our tests, we ran them with fairly large databases, but we’d only test one section at a time. Lately we’ve been really pushing the envelop, creating databases that are larger than any of our customers will ever have, and we’ve noticed some performance issues with these massive databases, as well as some memory issues.
So then the question becomes, why not just optimize everything? Because that’s incredibly time consuming and very expensive. But more importantly, it’s often a waste of time and money. Most of the improvements you’ll do won’t make any noticeable difference. For example, if a screen refreshes in 10ms versus 20ms, no one will notice, it’s too fast to be perceptible, even if it’s a doubling in speed! However the cost of this improvement may be significant, hence driving up the cost of the software! No one wants this, and there’s no real benefit to anyone in this case.
So what we’re left with is focusing on the main performance bottlenecks. How do we do this? Most people will think that you just look at code, it should be obvious. It’s not! Often where you think there’s a bottleneck is just plain wrong. This is one of the hardest things to do!
So where does this leave us? How do we do this? We could integrate within our application a bunch of timers, memory readouts, etc. that would continually post information out to the screen. I’d suggest against this because this is very time consuming, error prone, has the high probability of introducing unncessary bugs, and adds a lot of extra code to your application.
A better solution is to use a code profiling application. As LandlordMax is Java based, I can only talk about the Java code profiling application. There’s 4 main software solutions, all ranging greatly in price, how they tackle the problem of profiling, what features they offer, etc. They are: JProfiler, YourKit, OptimizeIt, and JProbe.
After some analysis, I narrowed our list of options down to either JProfiler or YourKit. I simply couldn’t justify the cost of OptimizeIt, and JProbe seemed still stuck back about a decade in terms of GUI (it just wasn’t friendly to work with at all).
I did personally contact both of the companies I was interested in evaluating (JProfiler and YourKit) and told them I was going to write a review here on FollowSteph.com about this topic. Both were enthusiastic about it, and each was willing to provide me with a free license to their application (thank you!) so that I could really try out their software packages. It’s great to see this kind of enthusiasm! It’s also great to see companies that really believe in their products!
That being said, after some experimenting, I’m going to say that I prefer JProfiler. YourKit was nice, but I found JProfiler’s interface much more intuitive, it provided me the information I needed in a very organized and obvious manner. This made finding the bottlenecks and memory issues much faster and easier! Therefore in my opinion, although both tools are powerful, but I recommend JProfiler as the better alternative.
To give you a few examples of some of the phenomenal improvements we got with LandlordMax, before we started using JProfiler, we ran a rent roll report that generated 521 pages of rents due (that’s a big database!) in less than 14 minutes. That seemed reasonable to us when you consider the size of the report. This same report now runs on my computer in 12 seconds!!! Yes you read that right, in 12 seconds! When we ran it with JProfiler, the performance bottleneck jumped right out at us. It was not at all where we thought it was, we had been focusing on the wrong area of code. Had we not used JProfiler for this, we could have spent many more hours, possibly days, trying to improve the performance and it would have only been minor, maybe we would have shredded one minute from the total time, nothing like what we achieved.
Also, remember that the time cost to fix this was extremely small, once we saw it in the “CPU Views” section, it was a no-brainer. Solving it wasn’t obvious, but locating the source of the issue was! Much like locating the leak in a pipe can be brutal, but once you know where it is, solving it isn’t nearly as difficult. With JProfiler we were able to find it in seconds, with just one pass of the report.
Although I’ve been mostly mentioning performance bottlenecks, memory leaks (or extraneous usage) can and also does happen. While running JProfiler we also found that we used more memory than necessary in many places. We immediately saw that our “instance” count was extremely high for Vector Objects (a Java library object that stores a list of other objects). Why was our instance count so high? By quickly drilling down JProfiler’s Call Tree, we immediately noticed the issue.
What was happening is that for each Model Object we created (a chunk of programming code that represents either a real world object or a concept), we were pre-creating several empty Vectors (lists). I know that without a context this doesn’t make much sense, so let’s give it a context. So for example, when we created a new Building Object, we would pre-create an empty Vector (list) of units, of accounting entries, and every other item that might be in the tabbed panels. There’s nothing wrong with that. When we were in the list view (where you would only see the list of buildings without the details), we only populated the basic building information so that it could be drawn in the table, not the full data (the list of accounting entries, etc.). We didn’t populate these lists (accounting entries, etc.) for every building because you might never view most of the buildings every time. Why take the performance and memory hit to pre-populate all the data if you probably will only use a small portion of it. Therefore we’d only populate the lists (accounting entries, etc.) for a building when that building was selected. This way, only when we actually look at the details of a building do we put information in our Vector Objects (accounting entries, etc.).
So how can there be a memory leak here? Well there isn’t one really. But what happens is that when we created a new Building we’d also create several empty lists (accounting entries, etc.) by creating a new Vector Object with no items in it. Still don’t see where the memory leak is? To be honest in retrospect it’s really obvious, but at the time I hadn’t really thought of it. The memory leak is that each of those empty Vectors Objects take memory. Each Vector Object has to be created (instantiated and allocated). Although the list contains nothing, the Vector Object does take up space. If you only have a few hundred buildings, it’s almost unoticeable. But now imagine that you have thousands of buildings, each with about a dozen empty Vector Objects! What about if you run a rent roll report like the one above with 521 pages of Objects each containing a dozen or so empty Vector Objects (lists)!
I wasn’t even looking for a memory issue in this area of the code, but by just running JProfiler while performing some random tasks quickly brought this to my attention. Of course, I had I run LandlordMax with a database of only a few hundred buildings I probably wouldn’t have noticed anything. You see in Object Oriented Languages such as Java, almost everything is an Object, there’s lots of Objects. Each Screen is an Object itself composed of many other Objects (Button Objects, Label Objects, etc.). There are Objects everywhere. But in this case because the database was much larger, the Object count quickly got out of proportion and it became very obvious when looking at the metrics within JProfiler.
So to fix this little issue, all we had to do is go from created empty Vectors (lists) to using lazy instantiation. What that means is that we don’t even create an empty Vector, all we basically do is say this is where the list will go in memory. We don’t actually put a list there, not even an empty one. In Java, we assign it the value of “null”. Without getting too technical, variables generally point to the Object in memory, they don’t store the actual Object (pass by reference rather than pass by value). So when we put “null”, we don’t need to worry about allocating that Vector Object right now, we can deal with it later if need be (or never if we don’t need to). if you want more details this article explains it in a lot more detail. Anyways, doing this greatly reduced the amount of memory we used everywhere. Had I not run a code profiler like JProfiler, I don’t think I would have noticed this. It’s not a show stopper, but the less memory your software uses the better, and generally the faster it is. It didn’t need to create and destroy all these empty Vector object instances for nothing.
Another great benefit we quickly got with JProfiler is that it showed us our data entry screens needed some performance boosts. Up until now, we generally focused on the list views, as those are the ones that contain the biggest amount of data. But JProfiler quickly brought to our attention that the combo boxes can be performance issues. For example, when I go to create a new accounting entry where the database contains over 2000 tenants, 2000 buildings, 2000 vendors, etc., each of these respective combo boxes need to be redrawn (in case any data updates were made). Each combo box requires a database call. Each combo box requires some Objects to be created and destroyed as they are updated. This quickly added up and became really apparent with a large database just by looking at the screens within JProfiler.
Because of this, we’ve now added some caching to LandlordMax which will be available in the next major release. As I mentioned earlier in this article, we could have cached everything, but because of JProfiler we focused on only caching the combo boxes that had performance and memory bottlenecks (which ended up only being 5 combo boxes). Talk about a time saver! I can’t imagine having created caching for everything! By analyzing the metrics, we found that 99% of the performance bottlenecks could be attributed to only 5 combo boxes, which is a lot less than hundreds of potential combo boxes, labels, prefilled data entry fields, etc.
As a quick side note, those of you who aren’t familiar, caching is a way of storing information in memory so that it doesn’t have to be retrieved from the database each time (and also a way of re-using the same Object instances rather than re-creating new ones each time). Because of this, if no changes occur between screens (for example no tenants are added, removed, or modified), the combo box is virtually instantaneously drawn and consumes no extra memory. If a change do occur (a tenant’s name is modified, etc.), we now just update the cached tenant list so that it still doesn’t require a full database call or the creation of new objects. If you have thousands of tenants, buildings, units, vendors, etc., this can quickly add up.
Before I finish this article, I just wanted to point out JProfiler’s “Hot Spot” functionality which is available for memory and performance analysis. This is basically a feature within the software that tries to actively point out to you where the bottlenecks are, so that you don’t have to look any further. Think of it as a summary of where you should look next, where you should look to enhance your software. It’s a nice little feature. Now that I think about it, it’s almost like it generates a “to do” list for you on where you should focus your time and money to enhance performance.
So have I convinced you that you (at least you software developers and software company owners) that you should run a code profiler for your software application if you haven’t already done so? I hope so! These were only some of the highlights we got from using JProfiler, there were others (I didn’t even mention any of it’s thread analyzing capabilities!). As you can tell, I really benefited from using JProfiler, so I definitely recommend them, especially if you’re coding in Java. The value in terms of time, cost, and benefits is definitely worth it!
Permalink to this article Discussions (9)
| « PREVIOUS PAGE | NEXT PAGE » |
