Your new website is live, the team has approved it, and the project can come off the meeting agenda. Before it disappears entirely, make sure somebody knows what happens next. A launch should leave the business with a working site, usable handover information and a clear route for questions.
The first few weeks are about confirming that everyday use works as intended and understanding where project support ends. They are also a sensible time to assign the small recurring jobs that keep a website useful.
Check the live customer journey
A preview check is valuable, but the live domain and receiving accounts deserve their own check. Agree who will open the important pages, follow key links and send a clearly labelled test enquiry after release. Confirm that the message reaches the right inbox and that somebody can respond.
For a regional commercial cleaning business, that might mean checking the service area on a phone, opening a facilities-management case study and requesting a site visit. If the message lands in an unattended mailbox, the form’s success message has only confirmed part of the journey.
Check important old addresses if the site has been rebuilt, particularly pages linked from proposals or email signatures. Record any problems with the page address, device, time and expected result. Our redesign checklist covers the wider release checks.
If URLs have changed, agree who will monitor redirects and search indexing after release. Google's site-move guidance explains the checks involved; publishing the website does not mean search engines have finished processing the move.
Leave with a handover your team can use
Ask for a short record of the live site, account access, responsible people and support contact. Where editing is included, confirm who has been shown how to make routine changes. Where the site is maintained through code, establish how your team requests an update instead.
The handover should identify renewal arrangements for the domain, hosting and any paid services. It should also explain where agreed source files, content and recovery information are held. A collection of attachments is less useful than a clear note showing which document answers which question.
Have the person who will manage the site check their access before the project closes. Our website access checklist sets out the practical checks without requiring the business owner to become the developer.
Separate three kinds of help
“Support” can describe quite different work. Keep these categories visible when discussing a request:
- Included post-launch support: help covered by the agreed project terms, within the stated period and scope. Confirm what issues it covers and how to report them.
- Ongoing maintenance: agreed recurring work such as updates, backups or checks, depending on the platform and plan. Hosting alone does not describe every maintenance responsibility.
- Further development: additional pages, functions or integrations outside the original scope, assessed and priced separately before approval.
A form that does not behave as agreed should be reported as a fault for assessment. A request to connect that form to a newly purchased CRM is a new requirement. Replacing a staff photograph may fall within an editing allowance or require a separate quote; check the arrangement.
Smartcon Works’ included support follows the selected package and agreed terms. Check the published package comparison and your proposal for the applicable period and scope. A support period does not by itself promise unlimited changes, ongoing maintenance or round-the-clock availability.
Know how and when to ask for help
Keep the support address or request channel somewhere the relevant team can find. Confirm the hours it is monitored, the expected acknowledgement time and how urgent faults are raised. A reply target is different from a guaranteed repair time.
Useful reports explain the business impact. “The enquiry form has stopped sending messages” needs a different priority from “We would like a different team photograph”. Include enough detail to reproduce a fault, using test information where possible rather than forwarding customer details unnecessarily.
If an issue needs investigation beyond the included scope, ask how that work will be authorised. Both sides should understand any proposed charge before additional work proceeds.
Assign the routine jobs
Give one person responsibility for keeping contact details, service information and team changes current. Assign technical maintenance separately where specialist help is needed. Confirm who receives renewal notices and who can approve payment when the usual contact is away.
A simple calendar can include content reviews, an enquiry test and the maintenance checks agreed for the platform. Choose a frequency that suits how the business uses the website. Our maintenance cost guide helps compare ongoing services once those responsibilities are understood.
Close the support period deliberately
Before the included period ends, review any open issues with the supplier. Record what remains to be resolved under the agreement, what has been deferred and which new requests need a separate decision. Confirm the route for later work and whether any ongoing arrangement has actually been commissioned.
When planning a website redesign, discuss this handover alongside the build. Knowing how to get help afterwards makes launch feel like a completed project rather than an abrupt change of subject.