Who looks after the product after launch?

The website or tool is approaching launch. Alongside the release work, there is a question worth settling: who will look after it when the team needs something changed?

The answer may involve several people. The person who approves service information may be different from the person who edits the page. Someone investigating a fault needs a different brief from someone assessing a new feature. Giving every request a clear route makes those responsibilities easier to discuss.

Our suggested planning note separates content changes, faults and new capabilities, then records the owner, contact route, useful information and agreed boundary for each.

Separate three kinds of work

Consider a fictional service website. The business wants to update a service description. Its enquiry form has stopped submitting. A colleague has also suggested adding online payments. All three requests concern the same website, but they ask for different work.

A content change updates information within an existing feature. The new service description needs approved wording and someone who can make the edit. The team should know who decides what the page says and who checks the result.

A fault concerns behaviour that differs from the agreed working scenario. For the enquiry form, useful information would include the page, what someone tried, what they expected and what happened instead. That gives the person investigating a place to begin.

A new capability expands what the product is expected to do. Online payments would need a discussion of the intended job, the surrounding process and the work required. It belongs in a scope decision before it becomes an implementation promise.

These categories help describe a request. They do not determine the answer to every disagreement about what was included. The agreed release and support terms remain the reference for that conversation.

Agree how the request reaches the right person

For each category, name the person or role responsible for receiving the request and the route the team should use. If the first contact is unavailable, record the agreed alternative rather than leaving people to guess.

A route might be a shared support channel, a task queue or a named business contact. The useful choice depends on the arrangement you have made. Include where someone can find that information when they need it.

Also agree which details belong in the request. A content update needs the approved replacement and the page it applies to. A fault needs enough context to describe the behaviour. A new capability needs the intended result and the reason it matters.

Make the boundary of support visible

WGMI's Website & App Build includes a documented handover. Ongoing support, response arrangements and future changes need their own agreed scope. Those details should be discussed for the actual project rather than assumed from the launch date.

Useful questions include which systems the arrangement covers, who can request a change and how a new request is assessed. If a response time matters to your operation, it needs an explicit agreement. The care note should point to that agreement and use its wording.

The same applies to access. Identify who can arrange the access a maintainer may need, without putting passwords or account secrets in a general handover note. The note should help people find the responsible route.

Keep one practical care note

For the fictional website, the note could contain a section for each of the three request types. Use the same four fields in every section.

Owner: Who receives this kind of request and decides the next step?

Contact route: Where should the team send it, and what is the agreed alternative if the first contact is unavailable?

Useful information: What would help that person understand the change or investigate the behaviour?

Agreed boundary: Which document or agreement explains the work covered and how anything additional is considered?

Keep the note where the people using the product can find it. When the arrangement or responsible person changes, update the note with them.

Complete that care note for one website or tool before its handover.

Prepared for WGMI with AI assistance.