WordPress website maintenance & support
in Westwood

A large share of support tickets on a maintained site are not defects. Somebody does not know how to do something, so they ask the people who built it. That is reasonable, and it is expensive to answer the same question eleven times.

The first step is to separate the two. A defect is behaviour that differs from what was agreed. Everything else is a question, a change request, or a task somebody would rather delegate.

Separating them changes the answer. A defect gets fixed. A question gets answered once and written down. A task that arrives monthly is either automated or handed back with instructions.

The pattern to watch for is the recurring ticket. The same person asking how to swap the banner, every quarter, is a documentation gap wearing a support badge.

Documentation for this is short and specific. Not a manual. A page per recurring task, with the actual screens of this site, written for somebody who does it four times a year and forgets in between.

Video helps for anything with a sequence. Two minutes, recorded on the real site, costs less than writing it and is used more often.

Then the honest conversation about which tasks should stay with us. Anything risky, anything touching payments or structure, anything where a mistake is hard to undo. Those stay, and the routine ones go back with instructions.

There is a commercial trap here worth naming. A retainer that bills by ticket has no reason to reduce tickets. We would rather the number falls, because the tickets that remain are the ones worth our time.

The measure we watch is the share of tickets that are questions. When it climbs, the answer is usually a page of documentation, not more support hours.

Every maintained site is supposed to have a staging copy. Most of them have something that is called staging and is not close enough to prove anything.

The differences that matter are predictable. A different PHP version. Fewer plugins, or the same plugins in older versions. A fraction of the content. Caching switched off. Under those conditions a change passes on staging and fails on the real site, and the value of the test was zero.

Content volume is the one that surprises people. A page that renders instantly against two hundred records takes ten seconds against forty thousand. If staging has a sample, it cannot tell you that.

So the copy has to be recent and whole, which raises the question nobody enjoys. A full copy contains real customer data, and it now lives in a second place with weaker protection.

The usual answer is to copy everything and then scramble what identifies people. Names, addresses, mail, phone numbers. Order structure and volume stay, so the tests stay honest.

Mail has to be blocked at the system level rather than by remembering. A restored copy with live mail settings will send order confirmations to real customers, dated today, for orders placed last spring. It happens, and it is a bad morning.

Scheduled tasks and payment keys need the same treatment. Test credentials, and background jobs either disabled or clearly labelled, so nobody charges a card from a copy.

Staging also has to be closed to search engines and to the public. An indexed staging site competes with the real one and occasionally outranks it.

We rebuild the copy on a schedule rather than keeping one alive for a year. An old staging site drifts from production until it is just another site nobody maintains.