A maintenance agreement should explain what gets checked, who handles a problem and how a broken change can be recovered. For Mumbai businesses, Softglimmer scopes website support around the existing platform and the business tasks it supports. Our Ranchi team works remotely with documented access, change records and an agreed escalation route.
Dependencies and critical journeys recorded before changes.
A defined review, backup and recovery approach.
Activities, hours and escalation responsibilities agreed.
An example journey, shaped around your requirements.
An outdated page, a failed form and a suspected compromise require different responses. Combining them under an undefined promise of unlimited maintenance makes priorities unclear. We establish the site baseline and classify the work before agreeing a support arrangement.
Inventory hosting, domains, CMS, plugins, third-party scripts, enquiry delivery and external services. Record the account owner and renewal responsibility for each dependency. A support team needs this map before it can diagnose a failure reliably.
A backup file alone does not show that a website can be restored. Define what needs recovering, where backups are held and how a restore can be checked safely. The required recovery scope may include content, uploads, database records and configuration.
Record platform versions, important user journeys and account ownership.
Use a suitable review environment and an agreed release checklist.
Check the important routes, forms and integrations after a change.
Illustrative workflow. The final scope follows your business requirements.
Choose support around the platform and the consequence of downtime, rather than an undefined list of fixes.
Agree the allowed content changes, update schedule and approval process. Identify changes that need a separate estimate, such as new page templates or integrations. Record what happens when an update conflicts with existing functionality.
Define which failures are monitored, who receives alerts and the hours when a response is available. Distinguish an acknowledgement target from a repair guarantee. External hosting or mail outages may require action from the account owner or provider.
A compromised or unstable site may need a one-time investigation before ongoing support begins. Preserve evidence and create a recoverable baseline. Performance projects, platform migrations and major redesigns should have their own acceptance criteria.
Each support proposal names the platform, activities, exclusions and response arrangement. We do not imply that a new agreement fixes an existing incident automatically.
A practical list of website services, ownership and renewal responsibilities.
The components to protect, retention expectations and a suitable restore verification method.
An agreed review, release and rollback approach for CMS, plugin or application changes.
Checks for the pages, enquiries, account tasks or purchase paths that matter to your business.
Named contacts, support hours and a clear distinction between routine requests and urgent incidents.
A record of completed changes, unresolved issues and separately proposed improvements.
A maintenance brief becomes more accurate when the team can see the existing system and the failures you have actually experienced.
List the owner of hosting, domain, CMS, mail and other connected services. Grant only the access needed for the agreed tasks. Existing credentials should be shared through an appropriate secure method, not pasted into public project documents.
Describe recent failures with the affected URL, time and visible symptom. Include previous changes and existing backups where available. This helps separate a software defect from a hosting, DNS, mail or third-party dependency problem.
Explain what visitors must be able to do and how the team discovers a missed enquiry. Agree priorities for repairs and identify periods when a release would be disruptive. A brochure site and a transaction-heavy application may need different support arrangements.
Mumbai and Ranchi share IST. We coordinate scheduled reviews in that time zone and agree incident contacts before support starts.
Inspect the platform, ownership, available backups and important journeys. Record evidence and known limitations before changing the site.
Set routine activities, permissions, escalation, response hours and the boundary for separately estimated work.
Address the agreed baseline issues with recoverable changes. Verify adjacent functionality as well as the specific fault being repaired.
Keep a change record and review recurring problems. Use the record to decide whether targeted maintenance or a larger rebuild is justified.
Useful answers about scope, ownership and remote delivery.
Potentially. We first inspect the platform, access, code ownership and current condition. Unsupported dependencies or missing source code may limit what can be maintained safely.
A full redesign is normally a separate project. The support scope should distinguish routine content changes and repairs from new templates, migration or substantial feature work.
The proposal defines the recovery checks and their frequency. We should not describe backups as verified recovery points unless an appropriate restore check has been completed.
Availability and the incident scope need to be checked. Share the visible failure and platform details so we can assess the next step; this page does not promise an immediate repair or round-the-clock coverage.