Give providers the same website brief
List the domains and systems in scope, the platform, hosting arrangements, integrations, access owners and known problems. Identify the journeys the business depends on: sending an enquiry, receiving a booking, taking an order, signing in or publishing information.
For each journey, explain the consequence of failure and who can authorise a temporary workaround. A contact-form success message is not proof that the business received the enquiry. A successful homepage check does not establish that checkout works.
Separate existing defects from ongoing care. Ask whether takeover assessment, resolving inherited issues, setting up monitoring and documenting recovery are included or quoted once at the start. Providers need enough information to identify assumptions before committing to scope.
Open the printable proposal comparison worksheet. Save or print it and record each provider's actual answer beside the evidence or clarification needed. It is a procurement aid, not a contract or an offer of specified service levels from Nolixia.
Compare what the proposed work includes
Use concrete tasks and completion evidence rather than accepting broad labels such as “security” or “support”. The right scope depends on the website; not every item below belongs in every package.
| Area | Question for the proposal | Evidence to request |
|---|---|---|
| Routine updates | Which platform, components and integrations are maintained, and how are changes tested? | Change record and affected-journey checks |
| Backups | What is backed up, where, how often and for how long? | Backup coverage and recent restore-test record |
| Recovery | Who can authorise and perform recovery, including outside normal hours? | Recovery procedure, access ownership and escalation route |
| Monitoring | Which availability and application checks run, and who receives alerts? | Defined checks and an example alert-handling record |
| Forms and notifications | Is delivery checked at the receiving destination? | Traceable test message and confirmation of receipt |
| Content changes | Which edits, capacity and turnaround arrangements are included? | Examples of included and excluded requests |
| Integrations | Who investigates faults involving booking, payment, stock or email services? | Named boundary and third-party escalation process |
| Reporting | Does the report distinguish completed work, failed tests and open issues? | Redacted sample report with next actions and owners |
Routine updates, recovery and monitoring
For a WordPress site, the official plugin documentation recommends a current backup before plugin updates. The auto-update guidance also discusses preparing a rollback route. Ask the provider how those principles apply to your particular site and its data.
A backup-success notification and a successful restoration test answer different questions. Ask what was restored, where it was tested and whether the important journeys worked afterwards. For a trading site, recovery also needs a decision about orders or bookings received after the restore point. Do not assume a full rollback is harmless simply because it restores a page.
Ask who acts when monitoring finds a failure. A tool sending an alert does not establish that someone has accepted responsibility for handling it.
Content changes and integration support
“Small changes included” needs examples. Does it cover replacing an image, adding a product, changing a form field or creating a new page? Ask how work is estimated, whether unused capacity carries forward and who approves additional charges.
An external service can fail while the website itself remains available. Clarify whether the provider only identifies an upstream issue, contacts the supplier, implements a workaround or repairs an integration they own. Record any access or client input required before work can proceed.
Separate response from resolution arrangements
An acknowledgement confirms that a request was received. An initial technical response may identify the owner and next action. Restoration makes the affected service usable again. A permanent fix addresses the underlying cause. A proposal should make clear which of these its target describes.
Compare support hours, time zone, bank-holiday coverage, reporting channels, priority definitions and escalation. Ask when the clock starts, when it pauses and what happens outside the covered window. A response described in business hours cannot be compared directly with a continuously measured target.
Use your own incidents to test the wording: a failed checkout, a form that stops delivering messages, an unavailable homepage and a request to change a photograph. Ask which priority each receives and who can change that priority. Do not substitute a generic one-hour promise for an arrangement the provider has actually offered.
Record exclusions, dependencies and renewal charges
Write down the recurring fee, billing period, currency and stated VAT basis. Separate takeover work, hosting, domains, licences, paid monitoring, additional capacity, emergency work and larger development. Check renewal prices and who owns the accounts and licences when the arrangement ends.
Ask about third-party outages, unsupported software, client-made changes, compromised components and work that exceeds included capacity. An exclusion should lead to a clear next step: who diagnoses the issue, who estimates extra work and who can approve it?
Also compare notice, handover, access removal, documentation and backup-export arrangements. Keep the organisation's own access and recovery responsibilities explicit. Passwords and secret keys do not belong in a comparison worksheet; use the appropriate account invitations or secure credential process during an authorised handover.
A fictional proposal comparison
The following example illustrates unanswered questions. These are not real offers, Nolixia packages or market prices.
| Question | Fictional offer A | Fictional offer B | What the buyer still needs |
|---|---|---|---|
| Updates | Says monthly updates | Names covered components and post-change tests | Confirm any excluded integration |
| Backups | Says daily backups | Specifies data coverage, retention and restore rehearsal | Check responsibility for recent order data |
| Support | Says priority support | Defines support window and initial response by incident type | Confirm escalation outside the window |
| Content edits | Says small edits included | Describes included edits and capacity | Price any work above the allowance |
| Reporting | Lists completed tasks | Separates passed checks, open issues and next actions | Request a redacted example |
Offer B supplies more comparable information in this fictional example. That does not make it automatically the better purchase: its actual scope, evidence, terms and price still need to fit the business. Record missing answers as “Not stated”, rather than treating silence as an included service.
Resolve unanswered scope questions before agreeing
Return the worksheet with specific questions and ask for revised written scope. Check that the final proposal incorporates the answers rather than leaving them in a separate sales conversation. Give the responsible business and technical people a chance to verify the assumptions.
After choosing a provider, use the website maintenance checklist to organise the recurring checks. For performance work, start with the page-speed review guide, then agree which pages and journeys are being measured.
To discuss an actual website with Nolixia, use website maintenance services. Supply the platform, key journeys, current problems and support requirements so the scope can be reviewed before an offer is made.
For a specific performance requirement, use the PageSpeed report and fix-record guide to agree the tested page, device, evidence and verification before commissioning optimisation work.
Common questions
What is included in routine maintenance?
Only the agreed scope establishes what is included. Common areas to check are updates, recovery, monitoring, fault investigation and reporting. Hosting, content changes and new features may be separate.
How do response and resolution differ?
A response starts handling the request; restoration or resolution concerns the affected service or underlying fault. Check the precise definition, support window, dependencies and measurement in the proposal.
Which exclusions should I ask about?
Ask about third-party services, licences, inherited defects, security incidents, client changes, new development, extra capacity and emergency work. For each exclusion, establish how investigation, approval and additional charges work.
