What are reasonable customer expectations of fixing site faults?

As a site builder, do you clean-up site errors a long time after the build, or do you say you’ve got a week to play around with it and highlight any issues in that period?

That is something you’d want to specify in the original contract before you start on the work. The length of time might be subject to negotiation depending on client expectations.

[font=verdana]As felgall says, a lot of it comes down to what the contract says. Mostly if you try to be reasonable with your clients and show good faith in getting things fixed, they are more likely to be reasonable with you and not expect you to work miracles instantly. There are, of course, always exceptions to that rule!

It also depends whether the mistake was yours or the clients, and whether they could reasonably have been expected to spot it. If they were evidently lax in not picking it up in the initial ‘snagging’, and it was something that they could and should have seen as a problem, then you could reasonably make a charge for correcting it – they have, after all, signed off the site to say they are happy with it. On the other hand, if it’s a problem that isn’t necessarily manifest (eg it might only affect certain browsers – you wouldn’t expect your clients to destruction-test the site in every browser, that’s your job) then any developer worth his salt will fix the problem as a goodwill gesture, even if they aren’t strictly contracted for it.[/font]

The contract matters, but I start by asking myself a few questions first, is this something the client could reasonably know? usually nope. is this something I feel I should fix? usually yes, what is my cost to fix the problem? usually how many hours. I find if I approach the issue in a friendly fix it manor, I am happier with myself. A side benefit is good client relations and in many cases they are willing to pay, a discounted rate, but it makes me feel better.

When I approach the work from the I have to point of view the work takes longer, is no fun, and client relations suck. A few times have talked specifics with others, I can’t remember one time when the programmer / designer / etc wasn’t partially responsible.

Coming from a personal perspective; the word “fault” is important to me; as it implies a problem or mistake that you as the developer introduced. Within our contracts we commit to fixing any “faults” or “bugs” that are introduced to an application due to us making some kind of a mistake; in the sense that the product is faulty. I don’t see that scenario as any different to buying a physical product and there being a manufacturing defect.

There is a length to that commitment; as a fault can appear due to technology changes (lets say 5 years down the line PHP depreciates a function or some CSS is depreciated or a new browser version is launched that handles a certain bit of code differently). Of course you need to protect yourself from that as it’s an external factor.

To be more specific, in our contracts we have a warranty, which is implemented over a fixed term and covers certain problems that could occur but does not include other things that could occur; such as technology changes that make effectively antiquate the product.

The actual warranty duration tends to be negotiated rather than set in stone.

So our warranty covers:

  • Bugs and defects due to a programming or design error x years
  • Problems that occur due to external factors such as technology changes; which is x year (normal shorter than the full bug/defect warranty); so a guard against how technology moves and changes in our industry; under the assumption that we are developers should; on the whole; have some idea of whats going to change in the immediate future.

The warranty itself is voided if the code or design is tampered with by a 3rd party. So if the company hire a freelancer or agency to add a feature or make a design change, the warranty would be voided as that could expose us to having to fix issues that someone else has introduced.

But with that all said, the warranty can be overridden if our clients take out an ongoing agreement with us for site maintenance, support, evolutionary development etc. because keeping the site up to date with current technology is normally a part of that kind of rolling agreement.

In a nutshell, we cover this stuff through our contracts; with an agreement that provides a warranty so the client is safe in the event that we do make a mistake; but we are covered against issues that could occur through no fault or reasonable oversight of our own.

Then you have rolling support/maintenance/evolutionary agreements which if are in place, would naturally cover that kind of stuff anyway.

Also, what techmichelle said about client relations; I think providing a warranty and supporting your clients in the long term is essential to building and maintaining sustainable relationships with your customers and also plays a really important role in securing the client in the first instance.

Most companies; particularly those who care about their digital and online assets will much prefer to work with the company who will stand by them for the long haul over the company who will build it and walk away into the moonlight. By being there, you also make it much easier to maintain an ongoing business relationship; as the client will also be more likely to call you when they need something else doing as by having this longer term relationship you are building just that; a personal relationship with your customer and that stands for a lot. It boils down to loyalty which is very much a two way affair.

The amount of customers who I’ve build relationships with and they have came to me to ask “do you do this kind of stuff too” (things we don’t advertise as aren’t core parts of our business but that we can or may be able to do) is not to be neglected.

Like for example finding myself helping with OOH digital displays etc. We never used to advertise for that kind of stuff; but one of our clients came to us and said that they were going to purchase a digital kiosk and wanted someone to create some software for it; they thought of us as we had supported them with web solutions for quite a long time.

After finding out what brand and model of kiosk they were interested in and what technology it used; the answer was “we haven’t done that before but from reading the technical docs, there doesn’t seem to be a reason why we can’t”. The client having a relationship and therefore trusting our judgement (and being aware that good judgement on our part was as important to us as it was to them) passed that job onto us; which also as a side effect gave us experience in an entirely new field.