Most of the company was at the Mix conference last week. They posted a note prior to the conference to warn that they would be less available. I suspect they are catching up now and inquiries may be given a lower priority than problems.

I have used the support channels (http://www.bvsoftware.com/Support/) and received good repsonse times.

Thanks for your responses. Like I said, I really think its a great product. Now I feel better about going ahead and purchasing it.


Mark

Mark, given the exceptions of the MIX conference, my experience with BV Support has been spotty. I've had Support Tickets go unanswered for more than a week. One email message on the contact us form about purchasing a Support Contract was never replied to. I think they try hard, but it's a small firm. The fact that they are now charging more for an annual Support Contract than for the product itself should tell you something. I am happy with the product and have been able to customize it to fit my needs so I am happy with the purchase, not so satidfied with product support.

Rick

Marcus, first let me say that I feel that BVC 5 is a good product, something that I do recommend to other users. I think it is a big step up from BVC 2004 and have been able to customize it to meet my particular needs At the same time, I have not been totally satisfied with the level of support provided for the product and I am going to call it as I see it. I am sorry to see that you are getting testy about this.

First, no one ever informed me that my support had expired and that I should not be submitting tickets. You or your staff could have communicated that to me on any one of my tickets. You did not do so. Secondly, given that support had expired as you indicate it was CLEARLY a the limitation of your Support Ticket system, which at the time continued to allow me to post support tickets. At the time the Ticket System did not have any information (as it does now) on when the Support was over. That has been changed now that you are charging for system support (I can no longer log in and post a new ticket).

I believe that it is quite unfair of you to be "blaming" me for the failure of your Support Ticket system to prevent me from posting tickets after my support had expired or for your staff failing to inform me that Support services had expired. Let me also say that my support questions have been for a) software that was not working properly or b) for features that were not adequately documented. I can say, uncategorically that at least one ticket was never answered. I posted Ticket 1-113dc-f11 on 6/19/2007 8:38:57 PM about why Order Export 3.10 was not working. It was NEVER answered on the ticket system much less within 24 hours as you claim and I'd be happy to send you the screen shots.

Tuesday 6/19/2007 8:38:57 PM - Ticket 1-113dc-f11 - Can't get Order Export 3.11 to work

Saturday 6/23/2007 9:02:04 PM - Still No response to Ticket. Posted a screenshot of the problem

Finally got an answer from you on BV Order Export Forum (http://forums.bvcommerce.com/default.aspx?f=44&m=48097)
(This turned out to be a coding problem in the Windows app where the Window size was hardcoded to 130 DPI and the submit buttons were not being displayed on large monitors at high resolutions). This was the first time BV had been informed of this problem and you indicated that this was an oversight that would need to be corrected.

Sunday 6/24/2007 9:46:58 PM - Closed my own ticket by indicating that I had finally gotten an answer from the forums.


I also sent a message via the Contact Us form asking about why a Support Contract could only be purchased for 1 year and not for a period of months and never received an answer.

As I stated at the outset. I think BV is a good product. And I believe that better support could be provided.

Rick

Luckily I've never posted a support question. Or if I did I don't remember when it was or if it was answered.
I agree that support should mean simply “I can’t figure out how to do something, please help” and not “this does not work, a fix is required”.
Bug fixes should not be part of standard support. The main problem that I see is actually not new bugs just found out, that don’t get resolved for a long(er) time but regression bugs, new stuff coming out in service packs or fixes, a fix that breaks two other functionalities and so on.
I’m still on a highly modified and customized by me SP2, and I don’t feel like upgrading anytime soon due to the sheer amount of bugs reported with new SP3 and beyond: search, coupons and other issues.
In the project I lead at work these days, almost every raised bug, gets a unit test to prove it’s fixed. You first write the unit test, to reproduce the bug, then fix it and use the unit test to prove it’s fixed. Every day we have continuous builds running that run all the unit tests as part of the build and no-one goes home until the build is good.
I think you should release the code together with all the unit tests, whatever they are: VS Unit Tests, nUnit, mbUnit, Watin.
Good reference: http://www.ssw.com.au/ss...esToBetterUnitTests.aspx
If a customer has a problem that you know should be fixed and proven as a unit test, just ask them to run the unit tests. If they work it’s a new bug. If they don’t it’s a user bug, change, missing update, missed database change or something else but you are able to pinpoint it much easier.
You can do regression tests at any point in time or (with lots of confidence) ask the user to upgrade if the bug they encountered is fixed in a new version/fix. :)
My 2 cents :)

Regards,
Corneliu.

Mitch and Corneliu,

You touched on an issue that I find particularly hard to resolve. I will be charging some sort of maintenance fee soon (ala everyone else in the industry), and I am trying to decide if bugs and new features should be treated separately, like you are suggesting.

Here are some of the policies that I have seen:

Microsoft Commerce Server: Free bug fixes, charge for new feature releases every 5 years.
Microsoft Office: Free bug fixes, charge for new feature release every 2-3 years.
FogBugz: Free security bug fixes (there has only been 1 in the last 3 years), maintenance required for all other bug fixes and new features.
Infragistics: Maintenance required for bug fixes and new features.
DevExpress: Maintenance required for bug fixes and new features.
Xceed: Maintenance required for bug fixes and new features.
Innovasys: Maintenance required for bug fixes and new features.
Endicia: Subscription required for bug fixes and new features.
Techsmith: Free bug fixes, charge for new feature release every 1-2 years.
Norton security software: Subscription required for bug fixes, charge for new feature release every 1-2 years.
Intuit: Free bug fixes, charge for new feature release every year.

I see a pattern. If the company has frequent updates that include new features, then there is a charge for bug fixes. If the company releases new features infrequently (1+ years), then bug fixes are free.

I suspect this has everything to do with how the code is treated internally. To be able to deliver bug fixes without new features, there has to be a snapshot of every release that has not reached end-of-life. That means branching for each release. When a new bug is reported, someone has to recreate the specific release, write the test, fix the bug, verify that the product has not regressed, then issue the bug fix. Then they would need to repeat that for each successive release to the current. I have several products. If have a new release each month or even every 6 months, that would be a nightmare within a very short time. I think this model only works when the company and product are big enough to have a separate maintenance organization. Hand them the frozen code and tell them they can only fix bugs.

On the other hand, if bug fixes and new features are made simultaneously, then only one code base needs to be right. When a new bug is reported, I only have to reproduce it on the current release (or verify that the current release does not have the bug).

Frankly, I don't see how I could realistically deliver bug fixes separately from new features for a reasonable cost that is fair to both you and me.

The subject of my post was just the "treat customers well" part. The rest is just part of a presentation that happens to contain good advice for merchants. I didn't post it for BV's sake alone.

Since you asked, I think it does apply to them on all points (except 4 and 5, obviously), since BV is a manufacturer selling digital goods directly to consumer merchants. BV is the first and last point of contact for the software product itself. Any similarities vs. differences between a retail store and software maker are moot; I'm talking about fundamentals.

But, again, my point was focusing on support. I probably shouldn't write when I'm tired. ;)

Andy,
I've been in the business of writing software for just over 12 years now. (The gaming is my hobby but not paying for my mortgage).
I have to agree with you that you can't always deliver bug fixes without new functionality.
DevExpress and most of the others give you bug fixes for free for the version you purchase for up to a year after purchasing: From: http://www.devexpress.co.../DXperience/editions.xml "Within 12 months from the date of your purchase, you automatically receive all updates for those products which you are licensed under a given subscription. In addition, you will receive all new products that we release for the Subscription level you own"
I think you can charge for support but not for bug fixes. I think the main frustration most of us on this thread have is not just bugs, but the handling of them, and the relevance. We see regression bugs for stuff that used to work, we see simple bugs appearing in SPs, we see several updates for the same stored procedure and so on.
I also think you can't write good code without unit tests and that you should have unit tests to avoid regression bugs and stop anoying some of your customers :)
I love the BV engine like most of you do and I participate with help on these forums as much as I can as well, but I still feel the frustration.

Mark,
Even with the issues raised on this thread I can still strongly recommend you use the BV before anything else. The engine is great, the support is prety good, place a question on these forums and you will get a reply in hours.
These discussion are things that I know Marcus & Co. will read, think and try to do some positive changes that we would all welcome.

Regards,
Corneliu.

I have spent 25 years in an industry that lives and dies by customer service and I believe that customer service is the difference between a good/not so profitable company and a great company that is profitable.



I have 4 trained people that help answer product sales support tickets and the toll free phone number on our web sites. We answer requests for support from 7 am to 11 PM, 7 days a week (I do much of the evening and weekend support myself). I just ran a report, and our average response time for support tickets received between 7am and 11pm local time (7 days a week) is 15 minutes and 45 seconds. That is based on the the last 8,000 support requests. We get from 2,000 to 4,000 new text product support requests per month (not counting requests that come in by phone). There is a direct correlation between how fast we answer a customers request for help and how often they buy. Fast support in our business means increased sales. Customers have an increased sense of trust and confidence in a company that is responsive.



My employees know that I better not find support requests that have been idle for more than an hour. It's a good way to get the boss in a bad mood!



BTW, we also cheerfully provide support toll free as well. And yes, we get a lot of stupid calls. But we write a lot of phone orders too.



The bottom line: If your customer takes the time to ask for your help, give it to them cheerfully and fast, and you will reap the rewards. Our office manger tells the girls that answer our phone to "smile" when they are answering the phone... it even makes a difference over the phone!



One last thought when it comes to web based businesses. I usually look a web site over and look for a phone number and a brick and mortar address. Next, I call their phone number to see if I can talk to a real human, even if I intend to order on line. If you fail these three tests, you probably lost my business. I will pay more to purchase from a company that I think will be there if something goes wrong. In my opinion, email is a support tool, but it's not "support". Some problems can be resolved much more quickly if you can just talk to someone.

First, thank you to everyone for the feedback. I appreciate hearing how you are viewing our support currently as it will help us improve things.

I'd like to give you a little insight into what we have to deal with here at BV and how it may be affecting your view of our support infrastructure.

1) I personally get 200+ email messages a day. Many of them are support requests even though we have a ticket system. When a customer doesn't get an immediate response to their email it's not because we're ignoring them it's because we have a huge volume of requests and email is not the proper channel to get support from us. We have a ticket system to track the entire history of the request and to ensure that customers who are paying for support get priority over people who are not willing to pay.

2) Many support requests that we get are NOT related to our software. More than 50% of all trouble tickets are caused by changes on the customers web host OR by customizations made by the customer. Although we try to resolve these tickets when possible often it is out of our control and we have no way to resolve the issue other than contacting a web host and asking for them to resolve the issue. This can be a chicken and egg problem when a customer is paying a cheap monthly hosting fee and the host won't provide any support for applications.

3) 75% of all tickets related to service pack upgrades are the result of someone botching a customized store update. If you customize your store there will be additional responsibility on your part or your developer's part when service packs come out.

4) 25% of all support tickets we receive are feature requests.

5) We do not ever charge or expect customers to pay to report bugs. However, bug reports are just that, reports. Each one has to be investigated to determine if it is a real bug and then we have to evaluate the impact of the bug on the software. If a bug is minor and a work around is available there is a chance that we may decide it is less risky to leave the bug in the software than to fix it and risk creating new bugs. Bug reports are not guaranteed any response time because we can not know ahead of time how complicated the solution might be.

6) Each license of BV Commerce includes 2 developer licenses. It is always our recommendation that every merchant have a development site where you can test service packs or other modifications before applying them to a live store. We get TONS of tickets that want us to drop everything we're doing to help out right now because a store is down. This "task switching" is a huge cost in time to us and we never want stores to be down but it is almost always because someone tried a patch or modification on a live store, not a problem with the software.

7) Our ticket system did not enforce cut off dates for support until last month. This was by design. It was our goal to provide support for more than 1 year for free if possible because we do value our customers, we want our software to be great, and we absolutely want to make sure customers are happy with our products. Last month we had to change the ticket system to enforce support time limits because the volume was getting so large that it was negatively impacting response times for paying customers.

This has been a pretty long rant so far and I'll wrap things up shortly.

BV Commerce is a packaged software product but it is unique in that without a web host and other services it isn't a complete solution to merchants. This is one of the root causes of support issues. BV Commerce is just one piece of the puzzle, web hosts, designers, developers and other services are also part of the solution. There isn't a single person in charge of a merchant's entire infrastructure in most cases. If you sell shoes you don't need anything else to use the shoes so it is easy for one vendor to support the shoes. With a bunch of services all mixed together it is a struggle to figure out who should provide support and how costs/revenue are divided between the players.

That being said I'm very open to any suggestions you may have as to how to improve our support system.