Overview
TaskTrain is built for actionable standard operating procedures: SOPs you can use to define, coordinate, and track repeating work. The key is breaking work instructions into discrete, logical Steps. While SOPs in general take many forms, from freeform narratives to flowcharts, TaskTrain has you write the work as individual Steps, so each Procedure is written once and worked many times as Assignments. Procedure Steps can be arranged in an outline of substeps up to four levels deep, grouping related Steps to make the instructions easier to follow.
Since most SOPs are a sequence of steps, outlines describe them naturally: their list format mirrors the order of the work. The outline also groups Steps into logical sections. Because human working memory is limited, this lets the reader see the "big picture" of the Procedure without getting lost in the individual Steps.
Well-crafted outlines do double or triple duty as step-by-step guides, progress trackers, completion checklists, and work records. Get the most out of them by following the suggestions below. To draft a Procedure with AI that follows many of them for you, see Generate a Procedure with SOP Savant.
Procedures
Scoping Procedures
Consider the following factors to ensure the work in question constitutes a cohesive, well-scoped procedure, which should unite a series of related steps designed to advance toward accomplishment of an organizational goal without duplicating or requiring multiple dependencies on work defined in other procedures.
- Group by goal and task dependence: Consider the immediate business objective first to identify the steps that must be followed to reach that goal, regardless of who will execute them. Any steps that are interdependent or must otherwise be properly sequenced should be part of a single procedure so that those following it can understand those dependencies and the part they are playing in achieving the goal. However, if steps may run in parallel without dependency and are executed by different members or teams, it probably makes sense to create separate procedures for each.
- Segment by triggering condition: An actionable procedure has a limited scope, defined by the triggering condition which initiates it and the goal of the work it accomplishes. While it’s tempting to include everything related to a topic in a single procedure, doing so can overwhelm or confuse readers and prevents it from being easily used to coordinate and track work. For example, “Asset Inventory Management” is a process area too broad to be captured in a single procedure and should instead be broken into at least four separate procedures, according to the independent condition triggering its execution:
| Procedure Name | Trigger |
| Asset Receipt | Procured asset physically received |
| Asset Assignment/Transfer | Asset (re)assigned to employee or location |
| Asset Disposal | Asset is physically disposed of |
| Asset Audit | Annually, April |
Naming Procedures
- Use concise, descriptive, unique, subject-action noun phrases: Start your procedure name with the subject it addresses, followed by the specific action executing the procedure accomplishes, for example: "Expense Report Filing", "Expense Report Generation", "Expense Report Reconciliation". Starting with the topic keeps related procedures automatically alphabetized together. Ending with the action ("filing", "reconciliation") makes the activity carried out clear. Using a phrase instead of a full sentence makes the name easily comprehensible and short enough to show up in list views.
- Omit unnecessary words: Avoid using words that are applicable in all procedure names, such as starting the name with "How to" or ending with "Procedure", as these redundant words obscure the topic and make searching more difficult.
- Use title case: Capitalize each important word in the name to differentiate Procedure names from Step names.
- Use symbols, acronyms, & typographic symbols: While you should be cautious about using unfamiliar acronyms or abbreviations that may be ambiguous or difficult to read, using well-understood or previously defined acronyms and abbreviations, as well as common typographic symbols to substitute for words ("&" for "and", "%" for "percent", "/" for "or") can keep names short and easy to parse.
Describing Procedures
A well-described Procedure gives the members who assign and do the work, and any AI agents that carry it out for your Organization, the context they need to apply it correctly. TaskTrain organizes a Procedure's description into dedicated, structured parts. Filling in each part is more useful than writing the same information into the free-form Description: structured parts are shown to the right member at the right moment, are searchable, and are passed to AI agents as data.
Use the structured parts wherever they apply
- Objective: one or two sentences on what the Procedure accomplishes and why it matters. It is shown on Procedure cards and in search results, so write it for a member who has never done the work.
- Estimated Duration: approximate end-to-end time ("15 minutes", "2 hours", "1h 30m"), to help members plan.
- Fields: the typed values the work takes in (Inputs) and produces (Outputs), such as a customer name or an approved amount. They are captured on each Assignment and can be carried into the next Procedure. See Define Procedure Fields.
- Materials: the physical or non-data things the work consumes or produces. A Task's Assignee sees them as Supplies and Deliverables.
- Tools: the equipment, software, and systems the work is performed with. List each one separately. See Add Materials & Tools.
- Entry Criteria and Exit Criteria: the conditions the work should wait for, and what should be true when it is done. Exit Criteria are the rules used to check the work, not the things it produces. See Add Entry & Exit Criteria.
- Roles and Default Assignee: who does the work, named by Role or by Position rather than by member, so the Procedure keeps working when members change Positions. See Define Procedure Roles and Update Procedure or Step Default Assignee.
- Approval Steps: Steps whose work must be signed off before it closes. See Require Approval on a Step.
- Related Procedures: the Procedures that come before or after this one, are alternatives to it, or are worth seeing alongside it. See Relate Procedures.
- Triggers: the situations, schedules, or completed work that start the Procedure, set up on its Triggers tab. See Triggers Overview.
- Keyword(s), Function(s), and Sector(s): categories that drive search. Prefer the words members actually search for over internal jargon; two to five keywords usually work best.
Use the Description for narrative context
Reserve the free-form Description for what needs prose to be useful, everything without its own structured part, such as:
- Background & rationale: history or context that doesn't fit in the Objective.
- Required authorizations: sign-offs, delegations, or compliance attestations beyond the Approval Steps.
- Notes & cautions: known pitfalls, edge cases, or escalation paths.
Steps
Defining Steps
- Follow the sequence of work: To be easy to execute, the Step outline should mirror the sequence of actions in the underlying process being documented.
- Identify important actions: Each discrete action necessary for the completion of the procedure’s objective should be a separate step. Create a Step for every action that:
- needs to be tracked separately for work coordination, collaboration, or communication,
- is critical and also likely to be forgotten or skipped if not called out, or
- must be tracked separately for reporting or auditing.
- Extract explanations: Sometimes it can be challenging to determine the granularity of description needed, and it’s tempting to include a lot of detail which can end up leading to the creation of an overwhelming number of steps, making the procedure hard to understand and follow. If information is being provided for reference or training only, it should probably be included as detail or Resources within a Step (see Describing Steps), rather as a separate step or sub-step.
Grouping Steps
TaskTrain allows Step outlines to be nested up to 4 levels deep to allow grouping of related steps for ease of understanding. It may be fastest to start by writing your Procedure as a simple flat list of all the individual steps that must be carried out in sequence to complete the work, and then go back over your list and group any related Steps into substeps in order to make the overall Procedure flow easier to follow. The number of levels in your outline and its overall length will vary depending on these considerations:
- Group related steps: When a series of Steps are closely related and can be summarized by a higher-level objective or phase in the Procedure, consider grouping them together as substeps to make the Procedure easy to grasp at a glance.
- Keep steps at the same logical level: For simplicity of understanding, the nature of tasks or activities should be consistent at each level of the outline. A “nit-picky” detail such as a specific action to take (“send an e-mail with the title “Time Off Request”) should not be at the same level in the outline as a general description of work (“Request time off”). Likewise, such general descriptions should not be at the same outline as even broader section/phase headings (“Request”, “Approval”, “Appeal” …) that may be appropriate to include for particularly long procedures.
- Keep subsections short: The commonly quoted “magic number” of 7+/-2 maximum items in human working memory may not be empirically validated, but it’s still probably a reasonable rule of thumb for the number of steps in an outline level. If the number of steps in a logical grouping exceeds that range, consider breaking it down into several smaller groupings at a lower level in the outline.
- Consider the skill of the assignees: Those already familiar with the Procedure's work requirements need much less specific instructions than those who have never done the work before. Yet another advantage of the outline form! An employee very familiar with the work may need only to scan the top level steps in the outline, while a member unfamiliar with it can drill-down into as much detail as needed.
- Include edge cases and error-catching: While it may not be possible to foresee and plan responses to every contingency, when a procedure contains known exceptions that require conditionally executed branches, or steps with a high probability of failure, include relevant decision steps with sub-steps for each conditional path or at least a general exception path for handing failures, not just the most common “happy path”.
- Use sub-steps for alternatives: As appropriate, add sub-steps describing the decision branches or alternatives in executing a given step. End the last sub-step with a period and the preceding with semicolons. Starting all but the first with “Or,” or “Alternately,” if the decision is a matter of preference, or with “If/Otherwise” clauses describing when to take a decision branch.
- Select the Assignee
- Choose the appropriate user from the User dropdown menu
- Or, type in an appropriate address in the E-Mail field
- Determine Priority based on Severity Level
- If Level 3 count >= 3, select High
- If Level 2 count >= 3, select Medium
- Otherwise, select Low
Naming Steps
The effectiveness of an outline is dependent on its contents being well-written and easy to digest at each step. Since an outline allows additional details to be described at lower levels in the outline, each step should be kept short and consistent with its siblings.
- Use phrases, not complete sentences: To make the procedure easy to execute, each step should be understandable at-a-glance. A concise and clearly descriptive phrase quickly conveys intent: “Return completed W-2 to HR”, not “When completed, the employee should return the W-2 form to HR.”
- Use symbols, acronyms, & typographic symbols: While you should be cautious about using unfamiliar acronyms or abbreviations that may be ambiguous or difficult to read, using well-understood or previously defined acronyms and abbreviations, as well as common typographic symbols to substitute for words ("&" for and, "%" for "percent", "/" for "or") can keep step names short and easy to parse.
- Name action steps with verb phrases: Lower-level steps that prescribe a concrete action should use the imperative mood to give the action prominence by starting with the appropriate action verb, for example: “Send e-mail to HR”, “Complete W-2 Form”, …
- Name grouping steps with noun or gerund phrases: Very long procedures may benefit from being grouped into logical sections that describe a phase of the process rather than particular actions. If an outline level does not prescribe any particular action but merely groups together steps that in turn describe actions to be taken, start the step name with a noun phrase, such as: “Project Planning”, Project Initiation”, “Project Execution”, “Project Completion”. Alternatively, use a gerund phrase, such as: "Initiating the Time Off Request", "Completing the Pro Forma Submission Requirements".
- Use decision verbs for branching logic: If a procedure has multiple possible completion paths based on a decision that must be taken at some step, use a decision verb (or equivalent gerund) like "decide/deciding" or "determine/determining" in the verb phrase (for action steps) or gerund phrase (for grouping steps).
- Assign actors rather than naming them: if work passes between members, give each Step a Default Assignee (a Role or a Position) instead of writing the actor into its name, so each Task goes to the right member automatically. See Define Procedure Roles. Where it still helps readers, you may add the actor at the end of the name: "Complete W-2 Form [Employee]", "Approve or deny leave request [Supervisor]".
- Omit numbering: TaskTrain automatically applies legal numbering (1, 1.1, 1.1.1, 2, 2.1, 2.1.1, …) to allow for easy cross-referencing of steps when tracking and communicating progress, so do not include outline numbering/lettering in step names.
Describing Steps
An outline has many advantages, but sometimes a name is not enough. A picture is worth a thousand words, and a video a million. Adding explanations, lists, screenshots, tables, diagrams, or videos gives members just-in-time training without breaking the flow of the outline.
Information that explains a Step, but doesn't need to be tracked separately (and so isn't a substep), belongs in the Step's detail or its Resources.
- Use Step detail for information unique to that Step: each Step has one formatted detail field, on its Guide tab, for information that applies to that Step alone. See Update Procedure Step Name or Detail.
- Use Resources for reusable information: a Step can have any number of Embedded, Attached, Linked, or Google Drive Resources, which can be reused on other Steps and Procedures in the Portfolio.
- Provide just-in-time training: the main purpose of Step detail and Resources is to explain how to do the Step when that isn't obvious from its name to every member who might do it.
- Put the Step's structure in its structured parts: a Step has its own Fields, Materials, Tools, and Entry and Exit Criteria, which the Task's Assignee sees on its Guide as Supplies, Deliverables, Tools, "Before starting", and "Before completing". Use them rather than burying the same information in the detail, so it reaches approvers and AI agents as data. See Follow a Task's Guide.
- Use normative vocabulary: when a Step name, detail, or Exit Criterion states a requirement, a recommendation, or an option, use the capitalized keywords of IETF RFC 2119 in the table below. Lowercase forms ("must", "should") have no normative force. In a Procedure's Description and in Procedure and Step detail, the Rich Text Editor underlines weak wording and suggests a keyword.
Keyword Meaning Replace these weak phrases MUST Absolute requirement. "is required to", "is to be", "shall", "will" MUST NOT Absolute prohibition. "shall not", "will not" SHOULD Strong recommendation; deviate only with a documented reason. "is encouraged to", "should consider" SHOULD NOT Strong discouragement; deviate only with a documented reason. "should not" (lowercase), "is discouraged from" MAY Truly optional; either choice is acceptable. "might", "could", "try to", "consider" - Call out cautions: Always include any appropriate notice of safety or other hazards that may arise while performing the Step. Use the following language to consistently communicate the hazard level, in decreasing order of severity:
- Danger: Near certain likelihood of death or serious injury [call out before step explanation in red boldface]
- Warning: Possible injury or death OR serious damage to equipment [call out before step explanation in red boldface]
- Caution: Possible minor injury or damage to equipment [call out before step explanation in red boldface]
- Note: clarification [call out in boldface]
Related Articles
Overview
Step-by-Step
