The sequence
- Fit check. Establish whether the problem is in scope, without collecting credentials.
- Diagnosis. Determine the actual cause, and deliver the findings even if repair is not viable.
- Authorisation. Agree scope and price before implementation.
- Secure access. Request the least access the work requires, and no more.
- Change and rollback plan. State what changes and how it can be undone.
- Verification. Check the original fault and the paths likely affected.
- Written record. Record the cause, the change, the checks, and the unknowns.
- Access removal. Remove access when the work closes.
Why the WordPress diagnosis order matters
Every step above exists because skipping it has a predictable cost. For example, changing before diagnosing destroys the evidence that would have identified the cause. Similarly, implementing before authorising produces an invoice nobody agreed to.
In short, the sequence is not bureaucracy. It is the difference between a fix you can trust and a change that happened to coincide with the symptom disappearing.
What a fit check does and does not do
A fit check answers one question: is this problem something DuePress should take on. It happens before any access, and it costs you nothing but the description.
Notably, it is not a diagnosis. It cannot tell you the cause, because nobody can determine a cause from a description alone. What it can do is rule the work in or out quickly, and point you elsewhere when the answer is out.
Diagnosis is a deliverable, not a sales step
The written findings belong to you whatever happens next. Consequently you receive them even when the conclusion is that a repair is not viable, or that the fault sits with your host or a third-party provider.
That matters commercially. A diagnosis you can take to another provider, or to your host’s support queue, is worth more than a vague opinion offered for free.
The access principles that do not change
Whatever mechanism is used to hand over access, four rules hold.
- Never by ordinary email, web form or chat. Passwords, API keys, private keys and database dumps do not belong in a message thread.
- Individual, not shared. A named temporary account beats handing over the owner’s login.
- Lowest privilege that does the job. Administrator is not the default request.
- Removed when the work closes, with a clear statement of what you should revoke or rotate.
Further detail on how access is handled is set out under access and security.
Change, rollback, and verification
Before anything is changed, two things are stated: what will change, and how to undo it. If the second cannot be answered, the change is not ready.
Afterwards, verification checks the original fault and the paths around it. For instance, fixing a plugin conflict while silently breaking checkout is not a fix. The WordPress debugging documentation describes the standard groundwork this rests on.
What you get at the end
The written record is the part that outlives the incident. It states the cause where one was established, the change that was made, the checks that were run afterwards, and anything still unknown.
That last field matters more than it looks. Unknowns are recorded rather than quietly dropped, because the next person to touch the site deserves to know where the certainty ended. Consequently a WordPress diagnosis leaves you with something you can hand to anyone, including another provider.
Where to start
For a live fault, see WordPress support, or hacked site recovery if the site shows signs of compromise. For a store, see WooCommerce support. Read the service scope first if you want to know what is declined before you make contact.