Service website audit: a 60–90 minute self-check

To find obstacles on a service website, start with one enquiry. Imagine a person with a specific task and follow their journey from the service page to an enquiry received by an employee. In 60–90 minutes, you can test that route, record observations and choose the first fixes. This is not enough time to examine the entire website, but it will give you a list of verifiable tasks.

You need a computer, a phone and access to wherever you receive enquiries: an inbox, customer management system or website administration panel. Download the free self-audit spreadsheet for your notes. It opens in Excel, LibreOffice or Google Sheets. If you prefer paper, use the printable version. Neither resource requires registration.

Prepare one scenario and agree on a test

Choose a service for which you want enquiries. Open the page linked from your advert, business listing or post. Use the homepage if visitors actually start there. Record the URL so that you can repeat the test later.

Describe the visitor's task in one sentence. An illustrative example: “My Bitrix website's form has stopped working; I want to know whether this provider can fix it and what they need to prepare an estimate.” Home renovation, accounting or training would need a different offer. For now, test only your chosen scenario.

Allow around ten minutes for preparation, twenty for the offer and contacts, ten for the phone, twenty for the form and ten for notes. Use any remaining time for analytics or repeating an uncertain step. If you get stuck looking for access, mark that stage “not checked” and continue with what is available.

Send a test enquiry only on your own website or with the owner's permission. Warn the recipient and establish what the form triggers: an email, call, task for a sales representative or automated mailing. Use your own email address and number. Write “Website test, no response needed” in the comment and add the test time. If the form creates an order, triggers a paid action or sends data to a partner, first agree on a safe test method.

Read the offer from this visitor's perspective

First, read the page without editing it. In the spreadsheet, record the answers you found and where each appears. You need information for making a choice, rather than an impression that the page looks attractive or dated.

• What work is offered and whether it suits the visitor you chose.
• What the person will receive: a repaired feature, document, training or support within an agreed scope.
• What information is needed for an estimate and how the work begins.
• What determines the price if an exact amount is not known in advance.
• What next step is available: ask a question, send a description or order a specific package.

In our example, “We create a digital future” says nothing about fixing a form. “We diagnose and repair forms on existing Bitrix websites” lets the visitor continue evaluating the service. This illustrates how to make wording specific; it is not ready-made copy for every company.

The absence of a fixed price does not itself make a page poor. For an unfamiliar system, it is reasonable to describe a diagnostic stage: what the specialist will examine, what they will deliver and how further work will be agreed. If the page says “from RUB 5,000”, check whether it explains what that amount includes. A figure without a scope leaves the question unanswered.

When you find a problem, propose a small edit first: change a heading, add the scope of a stage or explain the estimating process. “Rewrite the whole page” is too broad for one observation. “After reading, I could not tell whether the company works on existing websites; add this to the service description” is ready for discussion.

Check work examples and contact methods

Open one case study related to the service. Here, a case study means an account of completed work: the original task, the provider's actions and the result. Check whether you can identify the company's contribution. A screenshot of an attractive website does not explain who designed, developed or maintains it.

If a case study gives a growth percentage, look for the period and an explanation of what was measured. If those details are absent, record “figure not explained”. This is a reason to clarify the publication, not proof that the result was invented. Educational examples and the company's own demonstration projects should be labelled accordingly.

Now compare contact details on the service page, in the footer and in the contact section. The phone number, email address and provider's name should belong to the same company. If an office is listed, check whether visitors are welcome and whether an appointment is needed.

1. On your phone, tap the number and check the digits in the dialling screen. There is no need to make an unnecessary call.
2. Tap the email address and check the recipient in the draft message. Record an unconfigured email application separately from an incorrect address.
3. Open the messaging link and check the profile. You do not have to send a message.
4. Read the button label. “Get an estimate” should not unexpectedly open a newsletter subscription.

Save the exact URL of the incorrect link or a screenshot. This lets the developer fix a specific location without searching the whole website.

Repeat the journey on a real phone

Open the same URL on your phone in a normal browser. Record the device model and browser. A narrow desktop window is useful for a quick check, but it does not reproduce an on-screen keyboard or finger taps.

Go through the page from top to bottom. The service text should be readable without constantly zooming in, and ordinary paragraphs should not require horizontal scrolling. Open the menu, then close it. Check whether the heading, contacts and main button remain accessible beneath a fixed header, banner or chat widget.

Move to the form. Tap each field and check whether the keyboard hides the current line, hint or submit button. Try changing a value you have already entered. Go back using the browser's standard Back button: it should be clear where you are and how to continue.

On a computer, try moving through the fields with Tab. Record where the focused field becomes invisible or the button cannot be reached. This is a limited practical check; it does not replace a separate accessibility assessment for people with different needs.

Record a reproducible obstacle. “Awkward on mobile” explains little. “After opening the form, the bottom button stays behind the keyboard and the dialog will not scroll” gives a developer a specific scenario. If the problem disappears on another phone, save both results.

Test the form through to receipt of the enquiry

Start with input errors

Before a successful submission, test an empty required field and an obviously invalid email format, such as a string without an @ sign. Do this as part of the agreed test: a misconfigured form may accept even this input. Use only your own test details in the remaining fields.

Expected result: the website explains what to correct, beside the relevant field or in a clear message. Other entered text remains intact. A red border with no explanation makes correction harder. W3C guidance specifically covers clear error and success notifications.

Check whether labels disappear when typing starts. If a field shows only a grey example that vanishes as you type, the person must remember its purpose. Open the document links beside the consent control and check that they lead to the intended text.

Checking entered data is called validation. It can happen in the browser and on the server receiving the request. A visible browser message does not confirm server-side validation; a developer must test that separately. The MDN guide to forms explains the distinction. This self-audit does not require you to bypass restrictions or submit malicious data.

Then make one successful submission

Correct the fields, add the test label and press the button once. Record the time. If there is no response, do not press it again until you have checked with the recipient: the first enquiry may have been saved even though the screen did not show it.

After submission, it should be clear whether the enquiry was accepted and what happens next. If the website promises a response within a certain time, check whether that matches your operation. “We have received your enquiry” and “We are calling you now” require different actions from the company.

Verify the result in the system that actually stores enquiries. A CRM, a system for managing customers and deals, may be one such place. On a simple website, it may be an enquiry log in the administration panel. Find the record by its time and test label. Check the text, selected service and phone number or email address. If you cannot access the log, mark that stage as unchecked.

Check the email and “Thank you” message separately

Open the recipient's inbox. Find the test email, check spam and note when it arrived. Verify the customer's address inside the email. If an employee normally clicks Reply, open a reply draft and check that the intended address becomes the recipient; you do not need to send it.

A record may be saved while its notification fails to arrive. That points to notification configuration or delivery. If no record is found, a “Thank you” message alone is not enough to treat the enquiry as accepted. Give the specialist the time, page and screenshot of the result; do not post personal data in a general chat.

If customers receive an automatic reply, check your test inbox too. If no automatic reply is configured or promised, its absence is not a fault. Finally, agree with the employee how to mark the test record so that it does not enter real sales or operational tasks.

Do not confuse a button click with an enquiry

An analytics event reports the action the counter is configured to track. This might be opening a form, clicking a button or confirmed acceptance of data. Calling all these events “enquiries” causes confusion: an input error can leave you with a click but no enquiry.

A website owner can check the logic without editing code. Record the names of existing goals in Yandex Metrica and ask a specialist to show when each fires. A successful-enquiry goal should be reconciled with data acceptance by your system. Keep phone and email clicks as separate actions; they do not prove that a conversation happened or an email was sent.

For technical testing, follow the official Metrica instructions, which explain event debugging and verification. Allow for filters excluding your own visits and browser settings. If a record is present in the enquiry log but no event appears in the report, investigate analytics; that absence alone does not mean the enquiry was lost.

If you cannot access the counter, do not hold up the entire audit. Record “enquiry receipt checked; analytics not checked” and assign that item to its owner.

Record observations and distinguish blockers from improvements

Each spreadsheet row should describe one problem. Record the page and step, device, expected result, observation, evidence, priority, next action and acceptance criterion. The acceptance criterion explains what you will repeat after the fix and what result you will accept.

The observation below is illustrative, not a report about a client's website. In your spreadsheet, enter the actual page, device and time.

A blocker prevents completion of the chosen journey: an incorrect phone number, inaccessible form or lost accepted enquiry. An improvement makes the journey clearer, for example by explaining the diagnostic scope. A hypothesis proposes an effect you have not yet measured: “A different heading will encourage more people to open the form.” Keep “not checked” as a separate status.

Address confirmed obstacles first, followed by unclear parts of the offer. For hypotheses, decide what you will observe after the change. Do not combine unrelated findings into an artificial score such as “website 73 per cent ready”.

Turn an observation into a small developer brief

A technical brief connects the problem to the expected result. For a focused fix, this description is enough:

On the support page, part of the form is inaccessible on a phone after tapping “Discuss your task”. The page URL, device model, browser and screen recording are attached. To reproduce: open the page, open the form, tap the email field and try to reach the lower fields.

Make all fields and the button accessible while the keyboard is open. Preserve the current fields, enquiry recipient and transfer of the selected service.

Acceptance: repeat the scenario on the specified phone and a computer; check a required-field error; make one agreed submission; reconcile the on-screen message, saved record and notification. Test the change on a website copy first and agree on deployment with a rollback option.

This describes the result while leaving the technical solution to the provider. Before work begins, clarify the price and timing for this specific scope.

When you do not need a website rebuild yet

If the service is clear, contact details are correct and enquiries arrive, a few isolated faults do not establish the need for a new website. Fix the verified problems and repeat the journey. A different font or more modern animation will not correct a wrong recipient address.

A low enquiry count does not automatically indicate a design problem either. First check who visits the chosen page, whether the offer matches their expectations and whether they receive a response. Without that information, a complete rebuild remains a hypothesis.

Revisit the structure when it prevents you from presenting the required services and terms, or when repeated fixes become difficult to maintain. That is a separate decision after diagnosis, rather than an inevitable outcome of a self-audit.

Save the completed spreadsheet and start with one confirmed obstacle. If you need help, you can share that row, the test recording and the expected result with a specialist. The discussion will then start with a specific task whose completion you can verify.