Start with the support route documented in your project handoff or website-care agreement. If you cannot find that information, use the Help Center or contact us with your project name and a short description of the issue. We can then identify the right next step. Support coverage, response times, and included work depend on the arrangement for your project. They are not the same for every client.
Make your request easier to investigate.
Tell us which website or project is affected, the page or feature involved, what you expected to happen, and what happened instead. Include when you first noticed the issue and whether visitors can still complete the important task. A screenshot or exact error message can be useful. Do not send passwords, payment-card details, or sensitive customer information through an ordinary contact message.
If your site is unavailable, use any emergency or hosting route named in your agreement first. Otherwise, describe what is unavailable and whether the issue affects the whole site or a specific page. The team needs that context to separate a hosting problem from a form, content, or device-specific issue.
Know what happens after handoff.
A completed project can still need updates, troubleshooting, or new features. Those are different kinds of work. A website care plan may describe recurring tasks. Client support can help frame a specific request. New functionality or work outside an existing agreement may need a separate scope before it starts.
Keep your handoff information where your team can find it. It should identify who owns the domain, hosting, software accounts, content changes, and any scheduled care. When those responsibilities are clear, a request can reach the right person without guesswork.
What should happen after you submit an issue?
The next step is to identify the affected system and the coverage that applies to your project. A website may load while a form or booking tool fails, or the whole site may be unavailable because of hosting or domain settings. Those situations need different owners and sometimes different urgency. The agreement, not a general FAQ, defines any response commitment.
We may need to reproduce the issue, check recent changes, and request safe access through the approved method. Once the cause and impact are clearer, we can explain whether the repair fits support, needs a third-party provider, or requires a separately approved scope. After a change, the affected visitor task should be tested again. If your team can provide the exact steps that failed, the investigation can start more precisely.
How can you prepare for future project support?
Keep a current list of account owners, approved contacts, renewal dates, and the pages or workflows most important to the business. When a team member leaves or a provider changes, update that record. A handoff document should not contain passwords in plain text, but it should tell authorized people how access is granted. If your site relies on a form, payment gateway, or CRM, note who receives alerts and who can verify that submissions arrive.
For planned updates, describe the outcome rather than only the visual change. “We need the booking form to ask for a location and send the result to the right team” gives us a better starting point than “add a field.” It also helps separate an edit from a workflow change that needs testing and approval.
Get the request to the right place.
Bring the project name, the affected task, and what you have observed. We can help determine the appropriate support or new-work route.