Update working-practices.md

.config/mkdocs.yml

@@ -186,10 +186,11 @@ nav:
           - Templates: practice-areas/project-management/templates.md
           - Training: practice-areas/project-management/pm-training.md
           - Unanet Tasks and Training Material: practice-areas/project-management/pm-unanet-tasks.md
-      - Project Support:
+      - Project support:
           - Overview: practice-areas/help-desk/helpdesk.md
           - Project support and Agile: practice-areas/help-desk/help-desk-agile.md
-          - Support working practices: practice-areas/help-desk/working-practices.md
+          - Support best practices: practice-areas/help-desk/working-practices.md
+          - Support checklist: practice-areas/help-desk/project-support-checklist.md
   - About this guidebook:
       - About this guidebook: about-this-guidebook/README.md
       - Why this guidebook is open: about-this-guidebook/why-guidebook-is-open.md

practice-areas/help-desk/project-support-checklist.md

@@ -0,0 +1,101 @@
+# CivicActions Project Support Checklist
+
+## 1/ Start by defining "support" for your project team
+
+-   What does support or O&M mean for your team?
+-   What is included in your service?
+
+Make these a part of your core operating tenets and include it in your project [TWA](../project-management/team-working-agreements-instructions.md). Make sure everyone on the project understands this definition.
+
+## 2/ Define roles and responsibilities for support providers
+
+-   The primary goal of support is to respond to questions and solve issues for our customers, end users, stakeholders and clients who are using a product or service (which may be provided or managed by CivicActions).
+-   The secondary goal is to support the team by allowing for retention of focus in competency areas. Therefore everyone needs to know the breakdown of responsibilities for team members. Are there specialties? Tiers? How about schedules? Everyone on the team needs to understand these details.
+
+## 3/ Define your support (O&M) workflow and tasks
+
+Next define the workflow for support, including all associated tasks. Document - even in the simplest form - your workflow and share it with the team.
+
+-   If possible, have a single point of entry to receive, respond to, and track support requests
+-   Create a new ticket for each support request
+-   Create documentation for support processes as well as solutions for support related issues
+-   Documentation can include canned answers, knowledge base, frequently asked questions, common problems, etc.
+-   FAQs and knowledge base articles can often be turned into a self-service support portal for end users and stakeholders
+-   Documentation should be stored in a central location accessible to all team members
+
+## 4/ Know your Service Level Agreements (SLAs)
+
+Most production sites carry contractual expectations regarding uptime, or Service Level Agreements. They are critical to maintain system integrity. Every team member needs to understand SLA response times. Often a matrix view is an efficient method, e.g.,
+
+<table>
+    <tr>
+        <th>IMPACT</th>
+        <th>1 (highest severity)</th>
+        <th>2</td>
+        <th>3 (lowest severity)</th>
+    </tr>
+    <tr>
+        <th>How widespread is the issue?</th>
+        <td>Every page of the site</td>
+        <td>Half of the site, or high traffic pages</td>
+        <td>Small part of one page on the site or low traffic pages</td>
+    </tr>
+    <tr>
+        <th>How many people is this issue impacting?</th>
+        <td>Every user of the site</td>
+        <td>All public users or data publishers</td>
+        <td>A low number of users</td>
+    </tr>
+    <tr>
+        <th>Is it stopping anyone from working?</th>
+        <td>Yes, completely</td>
+        <td>Yes, somewhat</td>
+        <td>No</td>
+    </tr>
+    <tr>
+        <th>Is work efficiency impacted</th>
+        <td>Yes</td>
+        <td>Yes</td>
+        <td>No</td>
+    </tr>
+    <tr>
+        <th>Is there a work-around?</th>
+        <td>No</td>
+        <td>No</td>
+        <td>Possibly, yes</td>
+    </tr>
+    <tr>
+        <th>By when is a fix required?</th>
+        <td>Immediately</td>
+        <td>ASAP</td>
+        <td>Soon</td>
+    </tr>
+</table>
+
+Often support responses are broken by severity levels, i.e., P1, P2, etc. Confirm that all team members understand this information plus the workflow when recording/ tracking them.
+
+## 5/ If possible, automate your tooling
+
+-   Automate as many support related processes as possible
+-   Automate manual or low-lift tasks in order to free up effort for more complex tasks
+-   Look for apps, plugins, and integrations that can improve support efficiency
+-   Check for existing resources or documentation that can be refined and made available for broader use
+
+## 6/ Arrange for backup for your Support resources
+
+-   Determine the process for when primary support team members are out of office
+-   Ensure backup support providers have proper access/privileges to necessary accounts
+-   Share documentation among team members
+-   Provide training for all team members
+
+## 7/ Creating accessible content
+
+When designing content for project support, be sure to weave accessibility best practices into it. Some helpful tips:
+
+-   Include ALT text for applicable images
+-   Confirm plain language
+-   Avoid .pdf documents and instead - whenever possible - use a responsive layout that allows for resizing
+-   Use headings and subheadings
+-   Provide captions and transcripts for videos
+-   Ensure keyboard navigation
+-   Test for accessibility

practice-areas/help-desk/working-practices.md

@@ -38,17 +38,15 @@ Often when someone asks a question about a web application, responding quickly m
 
 The first step toward helping users feel attended-to is to **always reply promptly**. Any reply is better than no reply. Users and clients like to know that we've read their correspondence, and that we're looking into the issue. We don't have to know everything in order to begin an interaction, and we don't even have to be specific about next steps; often our first response may be as simple as:
 
-> Hi (name),
->
-> Thanks for sending this over! It sounds like you're experiencing a problem with (statement of problem). We'll (research some more about this / put it in front of our engineers immediately / see if I can solve that problem), and we'll follow up once we've got more information.
->
-> Let me know if I can help with anything else in the meantime!
->
-> Thanks,
->
-> (My name)
->
-> CivicActions Support
+Hi (name),
+
+Thanks for sending this over! It sounds like you're experiencing a problem with (statement of problem). We'll (research some more about this / put it in front of our engineers immediately / see if I can solve that problem), and we'll follow up once we've got more information.
+
+Let me know if I can help with anything else in the meantime!
+
+Thanks,
+(My name)
+CivicActions Support
 
 The simple act of sending a response that acknowledges a question helps create a mutually beneficial partnership, and tells the user that they're not alone.
 
@@ -58,7 +56,7 @@ We **always follow up**. We check and re-check our ticket queues frequently. If
 
 ### Resolution Time
 
-We do our best to **solve problems quickly**. We can't always do this; sometimes problems require lengthy engineering engagements, or simply can't be done, or _shouldn't_ be done. But when possible, we come to an actual solution quickly and let the user know. If our resolution doesn't solve the original request, we'll explain why and what's being done instead.
+We do our best to **solve problems quickly**. We can't always do this; sometimes problems require lengthy engineering engagements, or they can't be done, or shouldn't be done. But when possible, we come to an actual solution quickly and let the user know. If our resolution doesn't solve the original request, we'll explain why and what's being done instead.
 
 If a given support interaction requires engineering time or work that's outside support staff's capacity (for instance, if it means opening an engineering work ticket, or requesting approval or information from a stakeholder), we'll inform the user of the next steps, make sure they know everything they need to know, and communicate with other people involved to make sure those next steps can and will be taken, before our support interaction can be considered complete.