Normally, when you ask your agency to take care of something, they will tell you to open a “ticket”.
During ticket management there will be some phases where your contribution will be fundamental to reaching the most appropriate solution in the shortest possible time.
In particular, Triage and UAT, and immediately after Deploy.
The phases
Triage
After opening a ticket with your agency, the project manager will perform the so-called “triage”.
Basically, they will test the ticket to confirm that the problem:
- Is not user error.
- Is repeatable in production and in staging and development environments (if you don’t know what they are, read this article). This could mean having to recreate the same conditions observed in production in the staging or development environments.
- Is described clearly and with the necessary details.
- Is a new problem and not an already known error, perhaps in the process of being resolved.
In addition to this, the project manager will suggest a priority for the ticket. For example:
- If it is impossible to check out for all users, the urgency will be maximum.
- If there is a minor functional problem, such as stock counter malfunction, the urgency will be medium.
- If there is a purely cosmetic problem, the urgency will be low.
Another fundamental distinction is between:
- Bugs, i.e. errors that interrupt or compromise existing functionality.
- Requests for new features, i.e. improvements or implementations that were not present before.
During triage, the project manager will be in contact with you to make sure everything matches your expectations. Speedy and accurate feedback will improve the outcome of this phase.
Well-executed triage ensures that resources are allocated to the most urgent and relevant problems.
At this stage, the scope of the request may also be estimated. Your project manager, in collaboration with the developer, will be able to give you a rough estimate of the time required to resolve the problem.
Development
Once the problem has been identified and the green light has been received to start work, the project manager will pass the ticket to a developer.
The developer may have questions that, generally, the project manager who follows you and knows the project will be able to answer. For example: where X credentials are located, why Y solution was chosen, and so on.
The work will be carried out on the development or staging site, never directly on the production site.
At this stage, communication mainly takes place within your agency team. However, your input may be requested for specific clarification or confirmation.
QA
Quality Assurance (QA) begins when the developer confirms that the problem has been resolved.
In this phase, a tester (or project manager) from the agency will verify the solution following the instructions provided in the original ticket.
A well-done QA involves testing the site in both desktop and mobile mode, using different browsers. Additionally, it includes creative tests to verify that the solution cannot be “broken.” Of course, all tests must remain within the scope of the original ticket.
However, it may happen that new, undocumented problems are discovered during this phase. In this case there will be a discussion to establish whether the problem was caused by the new solution or whether it already existed (you can verify this by checking the live site). If the problem turns out to be unrelated to the current work, the tester will open a new ticket and pass it to the project manager for triage.
In any case, until the tester is satisfied with the results, he will send the ticket back to the developer, explaining the problems encountered and requesting further interventions.
UAT
When the agency tester is satisfied, the ticket is passed back to you, the agency client, for further testing: User Acceptance Testing (UAT).
During this test, you will need to confirm whether you think the solution resolves the issue described in the ticket and whether you are happy to proceed to the last step.
This phase is often underestimated, but it is crucial: the client can observe the site with a different perspective than that of the agency, identifying any particular cases that the solution does not cover and which may have been missed during QA.
This is another step where your contribution makes the difference.
Deploy
Once the work in the development or staging environment has been accepted, the agency will proceed to transfer that work to the production site.
This operation, called Deploy, can take anywhere from a few minutes to several hours and may require you to put the site into maintenance mode.
Depending on the solution you implement, you may need to configure module settings, enter credentials, or make other specific changes after deployment.
It is very useful for the customer to remain available during deployment, to deal with any unexpected events or to complete final configurations.
A good practice is to avoid deployments (or significant changes) on Fridays. This is because, if problems arise after deployment, they could only be detected and addressed the following Monday.
Another good practice is to test the site in production after each deployment, to verify that everything works correctly and that there are no unexpected side effects.
Given the ease with which you can place, cancel, and refund test orders, it will be very useful to have you at the forefront of this type of testing.
