Demo evidence packet

What a repair report looks like.

This is a sample, not a real client report. It shows the structure we use before quoting and after delivery: issue, impact, scope, access, fix path, and verification notes.

1. Fault found

The public contact page loads, but the enquiry path fails because the form confirmation appears without a deliverability record and the published fallback address rejects mail.

2. Business impact

Visitors may believe they contacted the business when no actionable enquiry was received. This can silently lose leads and make paid traffic harder to justify.

3. Repair scope

Check form routing, SMTP/provider settings, fallback address, spam controls, and confirmation copy. Deliver a before/after test with no password exposure.

Before work

Evidence gathered from public pages only.

  • Contact page inspected without submitting private data.
  • Fallback email address checked from public business listing.
  • Browser console and network errors reviewed for visible failures.
  • No admin login attempts, vulnerability probing, or server access used.
Access request

Temporary and scoped.

If the client approves the quote, we request a temporary account for the specific repair only. We do not ask for personal passwords, 2FA codes, payment credentials, registrar master logins, or unrelated server keys.

After repair

Close-out proof.

  • What was changed and where.
  • Before/after screenshots or test output.
  • Residual risks and next sensible fixes.
  • Reminder to revoke temporary access.