"Octane is a web design, development and internet marketing consultancy started in June 1999."
My name's Wayne Smallman and I sell ideas that change the way companies do business, usually in the form of novel web applications.
I'm also a writer for business publications (both web and print), as well as a consultant, adviser and trusted ally to my clients.
Quality is one of those things a business needs to get right early and quickly. Quality of service is not optional, nor is it interchangeable (or to be confused) with something else, like quantity. So would you impose a statute of limitations on the quality of the service you provide? No, you wouldn’t. And neither would I.
Of course, it wouldn’t do for everyone to be the same. At least that’s what my mother used to tell me. But then my mother didn’t run a business. As sage and sound as her advice often was, some things are an immutable prerequisite, like quality.
OK, let’s talk specifics — specifically, where a statute of limitations exists as a legitimate cut-off point for quality. Here I’m thinking of a time-limited warranty, like you get with physical goods, such as home electronics, food and vehicles.
In this kind of situation, you expect the guarantee of quality to fade over time, as the physical product ages, and is exposed to real world knocks, scuffs, tumbles and inexorable decay.
So that’s the physical time-limited quality issue out of the way. I’m sure we all agree on the legitimacy of warranties, yes? Now, I had an unusual conversation yesterday, one that forced me to think of the obvious in a way that, at least for me, is a constant I wouldn’t dream of tinkering with.
I was asked if, say, six weeks was a reasonable period of time, after which a client could no longer legitimately request fixes to software that myself, for example, had developed for them. As you can imagine, that threw me.
There were technical issues here — which I suppose we could consider as clauses — that needed addressing, as they were key players. Ultimately, they amount to an exercise in finger pointing, if I must be lazy about this. My reply was:
“If there’s a bug in your code and it’s your fault, don’t expect a client to observe a statute of limitations — they want a fix!”
And that’s only fair, and that’s where the technical clauses emerged — who made the most recent changes, to which files and when. However:
“If the client made any changes in or around the area of the fault, I’d make them aware of their liability.”
Which essentially highlights to the client the possibility that they will have to pay for those “fixes”, should any be required.
Now, don’t get me wrong, I’m not laying any blame on the person who asked me this question. After all, each industry has its own customs and practices. To me though, common sense wins out every time, and customs and practices be damned.
So I guess what I’m saying is, software doesn’t come a warranty, and don’t expect a client to think otherwise.
Image credited to Flickr and Junichi Ishito.