Skip to main content

Web Deve Maintenance SOP/Workflow

This clearly outlines the process of a new web development maintenance retainer client.

Jonathan Reisch avatar
Written by Jonathan Reisch
Updated over a year ago

Process Owner: Hanna Landis

Last Updated: December 2023
SOP Linked: HERE

What to do if your client is interested in dev support?

Phase 1: Getting Started

Phase 1: Initiated when AD/AM has received a contract signature announced the new client contract or resign in the #new-client-deployment channel.

Asana Setup:

  • Hanna Landis to review the asana board created by the Ops team to ensure it is ready for use ~ 1-2 days of notification.

    • Once the asana board is set up for the client - a form is set up that will allow for the client to submit their task requests to Asana.

  • Hanna Landis will share the form link with the AD and AM once this has been created.

  • Hanna Landis will enable Asana Board automations using the client’s email for notifications of task progress throughout the process. Insert loom video (“How to use asana form”)

Web Dev Support Setup:

  • Hanna Landis to create a slack channel using the following convention once notified of a new Client Retainer. Channel to be labeled #CLIENT-NAME_Dev_Retainer and includes relevant members of the team as well as for any further comm’s needed for the retainer. People to include in slack:

    • AM/AD/PM

    • Web Dev Lead

  • Hanna Landis to run a site audit report and provide to Client AM to share with clients on our internal findings and recommendations.

  • Hanna Landis to ensure maintenance plugins/backups are set up (WordPress clients only)

  • Assign developer to web maintenance client.

AD/AM Responsibilities:

  • Client AM to schedule internal sync with everyone on the dev team to review the scope of the web dev retainer and any relevant documentation, details of Asana Request Form, answer any clarifying questions, and establish timeline and expectations with the team.

  • If existing client: Client AM to send out an introduction email to client(s) with Web Dev Asana board link / Task form submission link provided by Hanna Landis above.

  • If new client: Client AM to email client introducing team and self, sharing Asana board form submission link and instructions on how to use the form submission.

Phase 2: Dev Support Intake

Phase 2: Dev intake process initiated when full internal team sync has met (AD + Web Dev Team) to review the Asana Request Form and been debriefed on web dev retainer client.

Steps & Responsibilities:

  • Client AM to own communication with clients throughout retainer and relay updates between dev team and client as needed.

Steps after an Asana task is submitted:

  • When a task is submitted to the asana board Hanna Landis will ensure the task has all necessary information in order to successfully complete the task. If the task submission is not clear or needs more info, the task will be set to on hold and assigned to AD/AM to gather the necessary details (i.e. images, details, logins etc.)

    • If the task submission is clear the task will be assigned a due date depending on urgency/priority.

    • The task status will be updated to in progress (if urgent) with a due date for that day the task was submitted.

    • If the task is not urgent the task status will be updated to backlog until the developer assigned starts the work and changes the status to in progress.

    • An email will be sent to the client notifying them of the following status changes: In Progress, QA, Client Approval and Complete.

    • When the task is completed by the dev the status update will be changed to QA and will be assigned to our internal QA developer.

    • Internal QA Developer will review the task to ensure the task was completed properly. If there is work that still needs to be done the internal QA Developer will leave feedback in the comments section outlining the changes still needing to be made.

    • It will then be moved back to in Progress and the assigned inhouse developer will make the updates.

    • Once the updates are completed the inhouse developer will update the Dev Status to QA and assign it to our QA Developer for one final walkthrough.

    • If the QA developer is satisfied with the updates the QA developer will change the Dev Status to Client Approval > which will prompt an email to the client that the task is now ready for client review.

    • If the client is satisfied and ready for the changes to go live then the client can comment on the task card and tag Hanna Landis it is approved or they can reply back to the asan approval email with their approval.

    • If the client requires any further updates that were not outlined in the original task a new support ticket will need to be opened.

    • Once the task has been approved by the client the Dev Status will change to Complete.

Turnaround times based on priority:

High 1 day

Medium 2 - 4 days

Low 5 - 7 days

Examples of Severity:

High = the site is broken and user experience is compromised

Medium = Time sensitive updates needing to be made to the website (i.e. adding a new page, adding a new team member, removing a team member)

Low = Replace an image with another image, Content updates

Status Options

On Hold - Needs more info before the task can be started.

Backlog - Upcoming task waiting for inhouse Dev to start work.

In Progress - Inhouse Dev has started working on the task.

QA - The task work has been completed and is in QA.

Client Approval - Task needs client approval before going live.

Complete - Task is completed and closed out.

After Hours Support

  • More details to come

Holiday Hours

  • AM/AD to communicate with clients of PDM holiday hours.

Web Dev POC

Questions about tasks: Hanna Landis, Rebecca Chambers

Did this answer your question?