Remediation of defects identified in operation

A defect is a deviation of the product from the behaviour described in the documentation or from the behaviour reasonably expected: an error, an incorrect calculation, a page that does not load, an email that is not sent. Defects discovered in operation are remedied either through a corrective release published to all users, or through a targeted intervention by support, when the problem lies with the data or the configuration of a single store.

3.1. How defects are discovered

• through the platform's monitoring and logs: server errors, failures of notifications or of integrations, abnormal response times;
• through reports from client print shops, sent through the support channels (chapter 06);
• through reports from end customers to the print shop (the contact form, website requests, the telephone), passed on by the print shop;
• through the developer's own operation and the checks carried out after every release.

3.2. How a defect is reported

A good report shortens the remediation. It is useful for it to contain:

1. what was attempted and what happened, compared with what was expected;
2. where: the address of the page on the site or the screen in the admin panel (the path through the menu);
3. when: the date and time, so that the event can be found in the logs;
4. the identifiers: the number of the order or of the request, the name of the product, the email of the affected account;
5. a screenshot of the error message and, for artwork problems, the file in question;
6. the browser and the device used, if the problem appears to be related to display;
7. whether the problem recurs or occurred only once.

Note. A report must not contain passwords. Support never asks for the password of an account; the access needed for investigation is granted through the platform's own means, with the print shop's agreement.

3.3. Classification by severity

The response time to a report depends on the print shop's plan (Pricing) and on the working hours published on the Contact page. Blocking incidents take priority over any other work: the platform's monitoring signals them to the developer independently of any reports, and the intervention begins as soon as possible, including outside working hours for those that stop sales.

3.4. The steps of remediation

1. Registration of the report (channel, date, print shop, description) and confirmation of receipt to the person who reported it.
2. Reproduction in the development environment or in the demonstration store, on fictitious data; when the store's real data is required, access is limited to what is strictly necessary.
3. Establishing the cause, not merely the symptom, and the extent: how many stores, orders or customers are affected and since when.
4. The correction, accompanied by an automated test covering the case, so that the defect does not reappear with a future change.
5. Testing: the automated tests and the regression of the critical flows (chapter 01, 1.4).
6. The release of the corrective version, with no action on the users' part (chapter 02, 2.3).
7. Correction of the affected data, if the defect produced incorrect data (for example an erroneously calculated total): with the print shop's agreement, and recorded in the history of the order or of the customer.
8. Confirmation to the person who reported it and, when the defect could have affected other stores as well, the informing of their administrators.
9. For blocking defects, a post-incident analysis: what was missing (a test, a check at release time, a monitoring alert) and what changes in the process so that the situation is not repeated.

3.5. Targeted interventions by support

Some situations are not defects of the code but call for a specialist to act on a single store: unblocking access when the last administrator can no longer sign in, correcting a configuration that produces unexpected results (a deleted status, a calculator module left unsaved), resending an email to a customer, restoring a file from a backup. They are carried out at the print shop's request, through the support channels; actions that modify data are carried out only with the print shop's explicit agreement and remain in the platform's history.

3.6. What is not a defect of the product

• The unavailability of an external provider (payment processor, courier, email service): the platform signals it in the admin panel or through the failure of the action concerned, and the developer follows it up; remediation belongs to the provider. Payment and delivery methods that depend on an inactive integration are not offered to customers.
• Data entered incorrectly in the admin panel (a price, a VAT rate, a status with its notification switched off): support helps to find and correct it, with a reference to the relevant chapter of the Guide.
• Artwork prepared incorrectly by end customers: the automated and the human check reject it according to the rules configured by the print shop (Functional characteristics, F9).
• Unsupported browsers and devices (Functional characteristics, chapter 02).