Start with responsibility, not a monthly number
A maintenance plan is useful when both sides know what it covers. Begin with the systems involved, who owns the accounts and who can authorize a change. A marketing website and a customer-facing application can have different operational needs even when both are described as “a website.”
Use a fictional driveway business to make the handoff concrete. Leah owns the business, Sam coordinates enquiries and an appointed maintainer handles the agreed technical work. These are example responsibilities, not an araNET support commitment or a customer incident.
Their handoff should name the public website and enquiry route, then record:
- Business owner: Leah approves releases, extra spending and changes to the service offer. Record a deputy for her absence.
- Account ownership: Leah’s business controls the domain, hosting and delivery-provider accounts. Record the account identifier, administrator and recovery contact; keep credentials in the agreed secure store rather than the handoff document.
- Daily operator: Sam checks the enquiry destination and reports problems through the agreed support channel. Record who covers that inbox when Sam is away.
- Technical contact: name the maintainer, the access granted and the steps for removing that access when the engagement ends.
- Renewal owner: Leah verifies payment details and approves renewals; the maintainer supplies the technical inventory and flags dependencies within the agreed care scope.
A support relationship should not depend on a password that only one person knows. Confirm that the owner can actually reach the accounts rather than simply listing them as transferred.
Separate four kinds of work
- Routine care: agreed updates, workflow checks and small changes within the stated allowance. Replacing a supplied photograph could fit here if the plan says so.
- Incident work: investigating a broken or degraded service through a defined contact and escalation path. A missing enquiry needs investigation, even if the homepage loads.
- Product work: a new feature, redesign or integration needing its own scope. Adding appointment scheduling changes the fictional business’s workflow and should be assessed separately.
- Provider costs: domains, hosting, storage, email and other usage under the agreed billing arrangement. List who pays, who receives notices and who can authorize a change.
“Updates included” does not establish unlimited development, continuous monitoring or emergency coverage. For every inclusion, identify the action and the evidence the owner receives: for example, a change record naming the affected workflow and its check result.
Ask what gets checked after a change
Updating a package and confirming the homepage loads are different from checking the important workflow. Choose repeatable checks based on what would interrupt the business.
For the fictional enquiry site, a useful release check would cover:
- Navigation and content: on desktop and phone, reach the service details and contact route; confirm the approved phone number and service area.
- Form behavior: use labeled sample details in a controlled environment. Check required fields, readable errors and retained input after a simulated failure.
- Receipt: verify the test record reaches its agreed destination and the operator can find it. Check what the visitor sees when delivery fails or its outcome is uncertain.
- Access: confirm the business administrator can sign in and a removed maintainer no longer has access.
- Recovery: identify a known prior release and test the agreed recovery procedure outside production. If stored records are involved, separately check that a recoverable copy restores the required records and files.
OWASP’s dependency guidance discusses handling vulnerable components according to the situation, including testing affected features. Assign someone to assess an alert, choose a mitigation and record the outcome. A dependency count alone does not establish that the customer’s workflow works.
Make the limits easy to understand
Write down support hours, how requests enter the queue, how severity changes priority and when the next update is due. Distinguish acknowledging an incident from restoring the service. Confirm the allowance, carry-over rules and how work beyond it is approved. Annual payment terms and a monthly delivery allowance are separate decisions.
Here is an example incident handoff: Sam reports that a labeled test enquiry did not appear. He records the page, time and visible message without pasting customer details into a shared ticket. The maintainer checks the application record, delivery state and provider status, then reports the confirmed impact and a next-update time through the agreed channel.
Leah approves any paid change or temporary public contact instruction. If the cause is a recent release, the maintainer assesses the agreed recovery path. Nobody should blindly resend uncertain submissions. After a fix, repeat the controlled enquiry check, confirm receipt with Sam and record the cause, action and remaining uncertainty before closing the incident.
Keep an owner’s handoff even without a plan
Ongoing aftercare is optional on araNET build packages. The owner still needs agreed access, release information, renewal responsibilities and a way to request future work.
Keep a renewal register with the service, account owner, purpose, next verified renewal date, billing term, payment owner and cancellation consequence. For the fictional domain, Leah checks the registrar’s actual renewal date and contact address; Sam records which website and contact routes depend on that registration. Do the same inventory for hosting and enquiry delivery, and update it when a provider changes.
Close the handoff by having the owner locate an account, find a renewal notice and explain how to report a broken enquiry. Record anything still missing. Compare those responsibilities with the current website care or application care scope before choosing a plan.
