Last modified: September 19, 2025
KM: Support content workflows
Knowledge Management
Use this guide to follow the content lifecycle, from first request to final review.
Roles and responsibilities
Role | Responsibilities |
---|---|
Lead | Manages intake Organizes work in Asana: Triaging requests Creating new tasks Clarifying asks Gathering resources Setting and managing due dates/priorities Oversees quality and processes Peer reviews |
Technical Writer | Drafts and updates articles Adds screenshots, links, and media Flags missing/unclear details to the requester or lead Peer reviews Article verification |
Requester | Submits a clear, actionable ask Provides relevant details, files, and documents Provides the names of the approver(s) if applicable Answers follow-up questions, and/or redirects us to SMEs |
Submitting/receiving requests
Support content requests & feedback form
All requests should come through the Support content request & feedback form. The form is linked in #support-center-updates in Slack,
When someone fills out the form, it creates a task in Support Center To-Dos in Asana.
Anyone requesting work from the Customer Enablement team should be directed to this form so tasks are created and organized automatically.
Monitoring Slack channels
Keep an eye on #product-releases. Product uses this channel to share pending and new features. Most posts won’t require action, but monitoring helps catch anything that might affect support content. Add information about other slack channels!!!!!
Product portfolio in Asana
Star the Product portfolio project in Asana. This keeps it at the top of your sidebar. You can check progress on product work here and note any content needs or blockers.
Support Document update sheet (integrations)
Most integration updates come through the Support document update sheet. The integrations team adds draft documents, media folders, and approved video links here.

How we organize our work and where it lives
Support center to-dos
The majority of KM tasks live in Support center to-dos. You can self-assign or be assigned tasks from this queue. Task descriptions should explain what’s needed and link to any resources. If an ask doesn’t have all of the information you’ll need to complete it, ping the requester.
Larger project boards
Major launches or feature updates will have their own dedicated Asana project. Tasks will be cross-linked to the Support center to-dos board. These dedicated projects will often house all important information and tasks related to a given release.
“Always on” boards
Some boards stay relevant at all times. Check in on these regularly:
- Customer Enablement: Team HQ (Our team board).
- The verification projects for Fullscript and Emerson.
Personal boards
Use your personal Asana board to track all assigned work. This gives you a clear view of your workload and helps you discuss capacity with leads and stakeholders. Organize it in a way that works best for you.
Statuses and work in progress
The KM Status field in a task is essential for giving yourself and your team members an indication of where work stands on a specific ask. The statuses you might see are:
Not started | No work has begun. |
In progress | Work is underway. |
Peer review | Draft is ready for review. Setting this status creates a review subtask and posts in Slack. |
Legal review | Draft has been sent to Legal. |
Ready to publish | Work is final and waiting for launch conditions or dates. |
Blocked | Missing information or resources prevent progress. |
Published | Content is live in the Support center/Help center. |

Reviewing articles
When you move a task to Peer review, Asana creates a review subtask and notifies the team in Slack.
When the subtask is created, the editing team member should:
- Open the subtask in Asana.
- Add a link to the draft or article.
- Add notes on what the reviewer should focus on.
If you’re the reviewer:
- Open the draft from the subtask.
- Review the article in full, or focus on the changes flagged by the editor.
- Use KM resources for guidance:
- Make small fixes (typos, punctuation) directly.
- Leave notes in the task comments.
- Complete the subtask when finished.
Due dates
Due dates are usually set one to two days before launch. They’re tied to release dates but aren’t meant as a signal to wait.
Leads or stakeholders may adjust due dates for needs like Legal review, Customer Success, or Sales enablement. Don’t change due dates without approval. If a change is approved, add a comment in the task.
If a task is blocked, update the status to Blocked and move it to the Blocked/Under development section of Support center to-dos.