Agree on acceptance before changing an online store

Once a store task reaches a developer, the owner needs a way to decide whether the result meets the agreement. We recommend defining that check before work begins. Consider a hypothetical request to preserve a selected filter when returning from a product page to the catalog. This example describes a process, with no completed project or specific product screens implied.

1. Turn the request into observable behavior

“Make the catalog easier to use” leaves many possible interpretations. Describe a sequence: open a category, select a filter, visit a product, and return in a specified way. Then state the expected result: the filter remains selected and the listing reflects that selection.

Clarify whether the return action uses the browser's back button or a link on the page. Record the device and any other conditions included in the task. You do not need to describe the entire store. You need an example precise enough for the owner and developer to understand the requirement in the same way.

2. Agree on scope and responsibility

Decide whether the change also covers other categories, sorting, or scroll position. If those details fall outside the current scope, record them separately. Acceptance can then follow the agreed requirement, while new requests receive their own discussion.

Name the person who clarifies the task, the person who checks it, and the person who accepts the result. One person may hold several roles, but the decision should be explicit. Also agree where the change will be available for review and who is responsible for bringing an accepted change into the live store.

3. Repeat the agreed scenario

After implementation, follow the original sequence under the same conditions. Record actual behavior beside expected behavior. A screenshot may show the selected filter, while a short recording or detailed steps can document the sequence of transitions.

Check related actions that fall within the agreement, such as clearing the filter and selecting it again. If something differs, provide the review location, steps, expected result, and actual result. A broad statement that something is broken does not tell the developer what to reproduce.

4. Close the task with a useful explanation

The closing note should say what changed, where it can be checked, which agreed checks were completed, and what limitations remain. The person accepting the work should explicitly confirm it or describe a mismatch. If review is postponed, preserve that distinction: implementation and acceptance are separate stages.

This is a recommended working process. Status names, review environments, and evidence formats depend on the project. One successful route does not establish that the entire store is free of faults. State the boundaries of the check as clearly as the requirement itself.

WGP develops and supports online stores. Frontbox includes a responsive storefront that also works on phones, plus development and support, and connects to a 1C-Bitrix store. A mobile app is a separate paid add-on. Acceptance arrangements for a particular change should be agreed as part of that task's scope.

5. A checklist before handing over a task

• Describe the starting situation and expected behavior.
• Record the steps and conditions for review.
• Clarify which related actions are included.
• Name the reviewer and the person accepting the work.
• Agree on the review location and evidence format.
• Define what the closing note should contain.

Choose one open task and complete this sentence: “We will accept the result if these actions produce this behavior.” Check whether another person could follow the scenario without a separate verbal explanation.