The website is live, the announcement is published and the project looks finished. The next day, questions arrive: where should someone report a problem, who helps an editor and what happens with a case the training did not cover?
Plan the first month as a defined period of work. That is a suggested organisational horizon; adjust it to the scale and rhythm of your service.
Establish one place for requests
Staff should know where to describe an issue and what to include: the task, expected result, actual outcome and time of occurrence. Supporting material should not reveal more information than is needed to investigate.
Assign someone to distinguish defects, questions about using the system and ideas for new features. These categories may involve different people and different charging arrangements. Keeping them separate also makes the work easier to discuss with the supplier.
Define launch support
Has the supplier reserved availability, and during which hours? Who contacts the hosting company or an external system's provider? How will users hear about a significant problem?
Agree reporting and review dates. “Post-launch care” does not by itself establish the scope or explain whether extra training and content corrections are included.
Choose what to observe
For a form, check that submissions reach the team handling them. For bookings, see whether staff can resolve exceptions. For an information website, note the questions that still require staff to send direct links manually.
At the end of the agreed period, review open problems, proposed changes and responsibility for normal maintenance. Separate work owed under the delivery scope from new requests in the budget. This gives launch a planned follow-through and leaves staff with a clear contact and understandable support arrangements.
Every number in this article, plus thousands of other contracts, is in the database.
Open the database