Skip to content

Find your next step.

Explore the studio

Website Maintenance & Support for Perth

Keep the site current. Know what care includes.

Softglimmer provides website maintenance and support for Perth businesses through an agreed care arrangement. We review the existing website, access, dependencies and important journeys, then define the updates and technical work to maintain. Delivery is remote from our Ranchi studio, with clear approval contacts and a useful account of completed work and unresolved issues.

Explore the city guide
A practical arrangement for ordinary changes, technical upkeep and the next problem that needs attention.
  1. 01

    Establish the setup

    Identify the site, dependencies and owners.

  2. 02

    Maintain agreed work

    Give updates a clear approval and review route.

  3. 03

    Explain the result

    Record what changed and what needs a decision.

An example journey, shaped around your requirements.

Define care around the website you operate.

A website keeps relying on accurate information, working functions, software and external accounts after its launch. We can help maintain those parts through a defined scope. The starting point is the actual installation and the business journeys it supports, whether Softglimmer or another team originally built it.

Onboarding establishes the platform, code or CMS access, hosting, connected services and known difficulties. We identify what is suitable for routine care and what first needs investigation or corrective work. That assessment gives the business a clearer basis for choosing ongoing content support, supported dependency work, functional checks and recovery preparation.

The arrangement names included tasks, request capacity, approvals and how priorities are decided. It also states the work retained by a host, account owner or another provider. A substantial rebuild, new integration or application feature can be assessed through a separate proposal while the agreed site-care work continues.

Match the arrangement to the work required.

Discuss the current need and the result you want before choosing recurring support or a focused task.

01

Planned website care

Agree the recurring content and technical responsibilities for a maintainable site. Identify the request route, authorised approver, review tasks and way completed work will be reported.

Discuss before build: A continuing scope with visible limits.

02

A defined fault or improvement

Describe the affected journey and what you observe. A bounded investigation can establish the cause and repair options before implementation and its acceptance are agreed.

Discuss before build: An assessed task with a specific outcome.

03

A larger development change

New templates, functions or a major platform change can alter the site beyond routine upkeep. Scope their design, development and transition separately while identifying the care still required.

Discuss before build: A clear boundary for additional work.

Agree the responsibilities that keep care useful.

The proposal specifies the extent of these six areas for your website.

01

Website onboarding

Inventory the platform, hosting, important accounts and connected functions. Record known issues and access limits, with a named person responsible for missing information or decisions.

A baseline and responsibility map.
02

Content-update support

Define the copy, media and ordinary page work included. Requests use approved material and a clear destination, with review by the person authorised to publish the business information.

A manageable request and approval route.
03

Dependency maintenance

Identify the software, extensions or services covered. Assess relevant prerequisites, licences and update work, then use checks suited to the affected functions and the agreed release approach.

Supported components and update duties.
04

Backup and recovery review

Establish the files, data and configuration required, available recovery copies and people able to use them. State the recovery procedure and any verification included in the care scope.

An understood recovery arrangement.
05

Important journey checks

Choose the reading, contact, purchase or administration tasks that matter for the actual site. Inspect the behaviour affected by a change, with a defined investigation when a performance problem needs attention.

Useful checks and their observed results.
06

Reporting and priorities

Summarise completed work, outstanding faults and recommended improvements. Explain dependencies still awaiting another owner and which next decisions or estimates the business needs.

A record that supports the next action.

Make the request and the completion easy to understand.

Use this card for one real ordinary change or known issue. Suitable page addresses and sanitised examples help us discuss the task without guessing from a general request to fix the website. The completed record should remain understandable to someone who did not attend the original conversation.

A prepared request and an accepted public result are different stages of the work.
Request cardInformation to provideDecision before workCompletion record
Affected placeName the public address, editor screen or customer task involved. Describe how a person reaches it when a link alone does not reveal the problem.Identify the relevant site or environment and the functions that may be affected.Record the pages or journeys actually reviewed after the work.
Intended resultSupply approved replacement material or explain the behaviour expected. Name the person who can confirm it.Agree the outcome and whether the work fits the current arrangement or needs an additional scope.State what changed against that authorised outcome.
Observed conditionDescribe what happens now, when it was seen and any relevant recent change. Share an appropriate capture with unnecessary personal information removed.Separate a known observation from a suspected cause; agree whether investigation is needed.Explain the finding and any limitation still needing investigation.
Authority and preparationIdentify the content or technical approver and any account owner needed for access. Note a business constraint affecting the proposed timing.Confirm permission for the task and the suitable release and recovery arrangement.Keep the authorisation and the release or hold decision with the task.
Checks and next actionExplain which affected outcome the business relies on and who can assess it. Agree any permitted receiving test in advance.Choose the relevant checks and what would prevent the task from being accepted.Record the result, unresolved dependency and person responsible for the next action.

Bring the people who control the existing setup.

Share the public site, the platform information you know, an ordinary update and the faults already affecting use. Identify the owners of domain, hosting, content, licences and connected services. Available access and documentation affect the onboarding work; credentials should follow an agreed access arrangement rather than an ordinary project enquiry.

List the journeys you need to keep useful and the people who can approve changes to them. An initial review can identify an outdated component, incomplete access or a larger structural issue requiring separate work. Recording that condition before routine maintenance begins makes the care scope more realistic and prevents an inherited problem from disappearing into an unspecified support promise.

Use a working routine both teams can follow.

Perth reviews can use dated Australia/Perth and Asia/Kolkata invitations. Coverage, urgency and response expectations are agreed for the site.

  1. 01

    Onboard and agree

    Review the site and its owners, identify existing issues and define the included care. Establish the request channel, approver and dependencies.

    An understood starting arrangement.
  2. 02

    Prepare the task

    Use the request card to settle the intended outcome and required access. Choose the suitable review, release and recovery preparation for the authorised work.

    A task ready to act on.
  3. 03

    Apply and inspect

    Carry out the agreed change and follow the affected behaviour. Keep an unsuccessful check or blocked dependency visible so another decision can be made.

    A result tied to what was checked.
  4. 04

    Report and review

    Explain the change, findings and outstanding work. Revisit priorities and capacity as the site evolves, with a separate proposal for larger improvements where needed.

    A clear next action for the owner.

Keep recovery and continuing duties explicit.

Recovery planning starts with what the useful site depends on. A copy of one component may leave out material needed elsewhere, while a restoration can affect work created after the selected recovery point. The maintenance discussion should identify the scope, available copies, responsible people and practical consequences before anyone relies on a recovery action. Any included rehearsal or restore check needs an authorised plan.

Account access, renewals and external services continue to require owners. Record the operating notes and unresolved restrictions the support team needs, then review the arrangement when the site or its dependencies change. Agreed hours, escalation contacts and response targets belong in the commercial terms. They should be chosen for the real need rather than inferred from the word maintenance.

Questions about an ongoing support arrangement.

A useful scope explains both the work and the people responsible.

Can you maintain a site made by another team?

We can assess it with authorised access and available documentation. Onboarding establishes the platform, dependencies and condition. It may identify repairs, licence decisions or other prerequisites before routine care is appropriate.

What counts as an ordinary change?

The agreement specifies the included content and technical tasks and request capacity. An approved text update and a new feature can require different work. We clarify that boundary when the request is assessed.

How will we know a request is complete?

The completion record explains what was changed, the affected behaviour checked and anything still unresolved. Your nominated reviewer can compare it with the approved result and identify the next decision.

Does website care include continuous emergency coverage?

Availability, urgency and escalation are agreed explicitly. Our team works remotely from Ranchi. Explain the operating needs during onboarding so the proposed care and any separately scoped incident work reflect them.

Can maintenance grow into a redesign?

A care review can identify a reason to improve the larger site. A redesign receives its own content, design, development and transition scope, with ongoing responsibilities for the current website kept clear.