Zeald stands by the quality of its work and provides a warranty for it as set out in our Terms of trade, which you have agreed to and accepted.  However, as web technologies are rapidly changing from time to time, issues with your website and other digital marketing are inevitable.

What you need to know about website issues

Website issues occur when a website doesn’t work as designed (when being used for the prupose it was designed for. They are a fact of life in software – all software have issues, and the more complex it is, the more issues it has.  Eliminating every last website issue is impossible – large software products like Zeald’s Website Manager, or platforms like WordPress or Shopify,  are similar to very complex machines, with millions of moving parts.  The environments they are used in are ever changing, and a lot of the time what people expect software products to do isn’t entirely what was envisaged by the people designing them.  Hence, for this reason, we cannot provide a “lifetime” warranty for website issues without passing the cost to you.

Some things aren’t website issues, they are features

Not every case where the system does something you personally wouldn’t expect, or which is sub-optimal or “not perfect” is considered an issue.   A lot of the time we’d consider it a “Feature”  even though the lack of this feature causes inconvenience or frustration.

What if it’s not a website issue?

Our support team will be happy to help with coming up with workarounds.   You can also contact our Support Team to have a feature added to your website.

What information do we need to fix an issue?

When you find a website issue happening on your website, you need to log those issues with our Support Team as a Change Request.

To be able to fix a website issue, we need information that will allow us to isolate it.   The platforms we support are large and complex pieces of engineering, with over half a million lines of code, hundreds of servers, and all the complexity of different client browsers, ISPs and operating systems to be considered.

If you log a general change request saying in essence “something went wrong on my website”, it will be very difficult for us to isolate the issue. If the issue does not happen to us, we can only perform what we call a “standard diagnosis”, checking your websites logs and checking for common problems and misconfigurations.

To fix a website issue we need information that would allow us to reproduce the issue.  Reproducing the issue helps us to deconstruct it to see the causes involved.  If the issue is intermittent and you can’t reproduce it, then we may be able to investigate it more deeply if you provide us with example times they happened (the more accurate the better), what user account it happened for or any other information that you feel might help isolate the issue.  In general the more information the better.

You can also email us screenshots of the issue, if possible.

Why can’t you make a change request if an issue can’t be reproduced?

This is actually a common problem in technical fault finding – the typical approach for isolating a technical fault is to reproduce the problem in a controlled environment, and make changes to track the issue down.

If you have a problem that we are unable to reproduce, the only recourse we have is to run through standard diagnosis (check the logs, check for common problems) and if this finds nothing we have nothing further we can do.  At this point you need to provide us with more information to reproduce the issue, otherwise we’ll have to close it.  Usually an issue will depend on obscure circumstances (otherwise it would happen to everybody and most likely already be fixed), e.g. only one browser and/or plugins and/or operating system and/or network/isp and/or sequence of actions you perform on the site.

A similar analogy is when your car starts making a strange noise and you take it to a mechanic, but it won’t make this noise when the mechanic is present.  Without being able to reproduce the problem (the noise), the mechanic can only try standard diagnosis (check common noisy parts, the oil pressure etc) and if this finds nothing, he can do nothing but tell you to bring it back if it happens again.

A guide to info that might help with reproducing your issue:

1. Start from a blank slate (clear your cookies & cache, and then load the homepage of the site)
2. Follow a sequence of steps to reproduce the website issue
3. Tell us that exact sequence of steps you did (ie what links did you click in each step).  Tell us what browser and operating system you are using, and if there is an error message & the exact error text (paraphrasing is a bad idea)

Why do we charge for customisation changes?

Issues are a natural part of software development, and even the most competent developers will produce a software with a lot of issues.   For people mainly used to the relatively issue-free experience of using stable, mature software, they are often surprised at how many issues there are in custom software: it’s not that mature software never had issues, it’s that over the years these have been found and fixed.  When you build custom software you need to assume a certain amount of time will be required long-term to maintain it (change requests, upgrading for new technologies, scalability).  Usually, these issues are triggered by:

• changes with external technology eg web browsers, devices or third party software connections
• the way you use the customisation may change, exposing weaknesses that weren’t previously apparent during initial testing.
• other customisations or updates/upgrades/changes to the base website may conflict with your existing customisation – eg redesigns or upgrades to your website will often require changes to your customisation.  

All of our time estimates (including old-style fixed-price quotes) include a certain amount of change request & testing.Often, the estimated timeframe is 1-2 weeks, and our support team will contact you once the fix has been completed.

For new time and materials estimates, we recommend everyone keep some of their budget for change requests. For fixed-price quotes issued in the past, the general rule is that your price includes sixty days of changes.  In either case, we could have budgeted more up-front but have probably erred on the side of keeping costs down.

If there is an issue in your customisation then we will usually let you know if there will be a charge involved before going ahead with the change request and investigation. In some cases where issues are really critical (e.g. your website is completely broken) we will need to act on them immediately and sort it out later.

This obviously doesn’t include change requests in the base system or issues caused by changes on our end – we will fix these for free.  It does include issues in old fixed-price customisations where the 30 day warranty period, which starts on the completion date (Do not confuse completion date with ‘Go-live’ or ‘website launch’.  Completion date is the date wherein you are advised that your website is ready for loading of your content.  Hence, clients are advised to launch their websites within the first 30 days from the completion date.  Otherwise, any issues with your website or its design that may arise after the warranty period will no longer be covered by the warranty).

Issues on unsupported addons, plugins and custom developments

Other plugins, add-ons and customisations are not updated as upgrades often carry a risk of compromising the website’s functionality.  Should there be any issues due to an upgrade, we can downgrade or restore from backup to upon request get your site working.  We can provide you with a quote to upgrade the plugin, add-on or customisation (or fix it) for an additional cost.

How long does it take for a website or design issue to get resolved after the expiry of the Warranty Period?

Depending on the complexity of the issue, a change request for a website issue may take around 30 minutes to up to weeks of work.  Our support team will advise you if it is likely to exceed 2 hours, which will be charged on a time and materials basis.

What’s a “Known Issue”?

Once an issue is identified, we then need to make a call about whether or not to fix it.  Not all issues are equal – some have a critical impact but only happen very rarely, some have a trivial impact but happen to everyone.

Whenever you fix an issue, you run the risk of introducing other issues.  In fact, with a mature and stable software product like Zeald’s Website Manager (which has been continuously developed in some form or another since 1995) almost all issues are caused by previous change requests.

There’s a great danger that by fixing one very minor issue that only affected one person, you’ll create many others that cause much more damage to more people than the original issue ever could – change requests can easily turn into a process of “moving issues around” without it resulting in any overall improvement in software quality.

As these issues move around, they affect different people and so more customers are affected by issues that might otherwise be the case.

Often by change request with a minor effect we create others with a much more major effect.   And in many cases, what frustrates people more is missing features in the software – it’s easy to get bogged down in change requests and have no time left for new features or major changes.

So for that reason, any product development team uses a process called “issue triage” to decide whether to fix an issue.  Our product development team look at new issues and ask “Is this an issue? – Can we reproduce it?” and then we analyse it based on the following questions:

Very often with issues, the “Severity” may be extremely high – but the issue happens so rarely that no one even knows how to cause it.  In other cases the severity and frequency maybe both be high, but the risk is very high – by fixing the issue we are likely to break many other websites.

If, after we mentally ask ourselves these questions, we think the risks and costs of fixing an issue outweigh the benefits it will give – we might add the issue to the list of “known issues” for monitoring.  At some later date, the risk/return may change, or we may find a way to resolve many known issues with one change with an acceptable risk/return.