Routine, Periodic, SOP-Triggered, and Received from Others: How Role Tasks Enter a Workflow

A clear handbook for a role does not necessarily mean its work will start on time.

Someone handles messages every day but misses the review due at the end of the month. Someone waits for an assignment even though the workflow has already reached their step. Someone else receives a forwarded message and creates a new task, leaving two people doing the same work.

These problems often arise when a task enters the workflow: Why has this work come up? When should it be done? Who will take it on? Is someone already doing it?

When I work through a role's responsibilities, I start with four task attributes: routine, periodic, SOP-triggered, and received from others. A single task can have several of them. Clarifying these attributes helps us arrange the work. Before execution starts, we still need to check the objective, the conditions, and who has accepted responsibility.

Here, a role means the capacity in which someone carries specific responsibilities at work. SOP stands for standard operating procedure.

What each attribute tells us

Routine emphasizes ongoing attention. For example, a role checks the inquiry channel during agreed service hours and identifies messages that need follow-up. This does not mean every message must be resolved immediately or that one person must stay online around the clock. Coverage hours, backup arrangements, and escalation of exceptions should reflect the business's actual arrangements.

Periodic emphasizes an agreed rhythm. Examples include reviewing open matters every week or checking the validity of documents every month. Routine work can also have a fixed daily schedule, so “routine” and “periodic” can overlap. Organizing inquiry records before the end of each day is both regular work and work with a clear daily rhythm.

SOP-triggered has a specific meaning here: when an SOP reaches an agreed step and the relevant conditions are met, the work for that step arises; the exact arrival time cannot be known in advance. For example, a quotation task arises only after requirements have been confirmed and checked and the workflow reaches the quotation step. There may be a requirement to respond within a certain time after the trigger. That does not justify assuming that a prerequisite output will arrive on a particular day simply to fill the calendar.

Received from others describes how a task is received: another person requests or assigns a matter, and the relevant role receives it. The requester might be a collaborator, customer, project lead, or another contributor. This attribute does not imply a lack of initiative, and the requester does not have to be a superior. After receiving the matter, the recipient still needs to clarify the need, assess the conditions for taking it on, and communicate the arrangements.

The four attributes describe different aspects of work. Routine and periodic mainly help arrange its rhythm. SOP-triggered describes the conditions under which a task arises in the SOP. Received from others describes how a matter comes from another person. They are neither four mutually exclusive categories nor substitutes for priority and task status.

Scroll sideways to explore, or open the full diagram.

Open full diagram ↗Download editable SVG ↓

One matter can have several attributes

Suppose a company's requirements coordination role routinely checks customer inquiries and, by agreement, organizes unfinished matters before the end of each day. The first activity emphasizes ongoing attention. The second has both routine and periodic attributes.

For a particular request, the requirements are confirmed, the SOP reaches the quotation step, and a collaborating role assigns the work to the quotation role according to the process. For the quotation role, this task is triggered by a workflow step and also arrives through another person's assignment. It can therefore be marked both “SOP-triggered” and “received from others.” If the system merely generates the task automatically at the relevant step, without another person requesting or assigning it, there is no need to add “received from others.”

If the customer later sends a reminder referring to the same requirements, version, and delivery purpose, link that message to the existing task and update the communication and timing information. Creating another quotation task could produce two conflicting outputs.

Three things need to be kept distinct: standing responsibilities describe what the role normally handles; task rules describe when work arises; a task instance records what must be delivered this time. “Review once a month” is a rule. “Review the documents expiring this month” is this month's task. Leaving the rule permanently on a to-do list and mixing every month's work into the same record makes those distinctions disappear.

Task attributes do not determine importance either. An ad hoc assignment may have a major impact or may be able to wait. Periodic work may be important or may need adjustment as the business changes. Priority depends on customer commitments, economic impact, dependencies, deadlines, and available capacity, and should be determined by a role with the appropriate authority.

From a task arising to someone being able to do it

I suggest recording where the matter came from, then using the same requirements to judge whether it can be taken on. Start with the following questions.

First, does this matter already exist?

Look for the same business subject, delivery purpose, scope, and document version before deciding whether to link it to an existing task or create a new one. Identical names do not necessarily mean the same matter, and one matter may have several names. Reviews of different monthly batches are usually different tasks. Two reminders about the same quotation usually add communication to an existing one. When the scope or version changes substantially, make clear whether to amend the original task or start a new one, and preserve the relationship between them.

Second, why is the work needed, and what result should it produce?

Explain which business activity it relates to, where its scope ends, who needs to use the result, and what counts as complete. For work connected to customers and economic outcomes, be able to explain which stage of the performance chain it supports. Checking off every supporting action does not establish that customer value and economic outcomes have been achieved.

Third, are the conditions for taking it on in place?

Check the input materials, prerequisite outputs, applicable rules, required authority, and available capacity. An SOP-triggered task should identify the relevant SOP step and the evidence that its conditions have been met. Periodic tasks also require a check that the materials for the current period are complete; the scheduled time alone does not mean work can begin. Once a task arises, the conditions for accepting responsibility and for execution still need to be checked for this particular work. If information is missing, record what is missing, who will supply it, and when it will be checked again. If the task needs to be passed on, state why and identify the receiving role.

Fourth, who confirms responsibility, and what happens next?

Within the agreed authority and division of work, a role can take on tasks under established rules. Where discussion is needed, identify who confirms the arrangement and record the deliverable scope, priority, and timing. Receiving a request should not leave the requester thinking that completion has already been promised. When a request is outside the role's scope or current capacity, respond by clarifying, adjusting, passing it on, or explaining that it will not be taken on for now.

Start the work once its execution conditions are in place. If it needs to be scheduled in advance, state the dependencies, the expected arrangement, and the time for another check. A planned date must not be treated as proof that the conditions have been met. For matters that need to wait, preserve the reason and the conditions for reassessment. Choose task statuses and approval requirements according to the complexity of the business. Classifying work need not add layers of confirmation.

Scroll sideways to explore, or open the full diagram.

Open full diagram ↗Download editable SVG ↓

What a role handbook should record

These attributes also need to become part of the role's working arrangements so they can be used in practice. I suggest keeping at least six kinds of information:

1. Purpose and scope: Why the work is done, which part of the business it serves, and where its boundaries lie.
2. Attributes and rules for arising: Which attributes apply, what the schedule or SOP conditions are, and where the matter is received from.
3. Inputs and supporting evidence: Which materials, versions, and prerequisite outputs are needed, and who provides them.
4. Responsibility and coordination: Who takes on this instance of the work, and whom to contact if authority or capacity is insufficient.
5. Timing and delivery: When to respond, when to finish, what to deliver, and who will use and check the result.
6. Exceptions and relationships: How to record duplicates, missing conditions, scope changes, transfers, and cancellations.

These six items can fit on a short task card. Put the stable, recurring parts in the handbook. For each instance, fill in only the specific subject, materials, dates, and changes. Simple work does not need the same long explanation written out repeatedly.

For example, an arrangement for quotation work could say: after the requirements check passes, proceed to quotation using the requirements reference, version, and checking record. The quotation role confirms responsibility under the agreed rules. If cost or lead-time evidence is missing, first ask for it to be supplied. The deliverable includes the scope of applicability, price, lead time, and conditions of validity. Link reminders to the existing task. If requirements change, first confirm the version and work scope.

The business must set actual prices, response times, and approval authority in light of its operations and customer commitments. This example shows how to write the arrangement; it is not a quotation policy that every company can adopt unchanged.

Open collaboration also needs room for initiative

Participants in the resource, operations, customer, and capital ecosystems can all identify problems, raise needs, or contribute on their own initiative. The four task attributes should not leave anyone fixed in a position of waiting for assignments.

For work already covered by the handbook and the role's authority, the role can act on its own initiative under those arrangements. For a new proposal, start by explaining the problem to solve, the expected result, and the roles and resources needed. The appropriate role can then judge how to bring it into the work. Making a proposal does not mean that others have already accepted responsibility, nor does it automatically create returns or entitlements. Those arrangements must be defined separately according to the actual business and its rules.

A lean operations team is responsible for decisions, rules, and coordination, connecting value production, sales channels, and customer relationships. It needs to resolve conflicts between roles and make resource trade-offs. It does not necessarily need to assign every routine task manually. For work that can proceed under established rules, roles should know when they can act directly. For matters that do require coordination, make clear whom to contact.

Role handbooks apply to roles that contribute value. Customers buying for consumption and people participating solely as investors use their respective business and communication processes. They need to take on tasks under a contributor role's arrangements only if they actually undertake that role's work.

Use a stretch of real work to see whether the classification helps

Start with one role and record the matters that actually arise over a period of work: which come from routine arrangements, which arrive on a periodic schedule, which are triggered by SOP steps, and which are requested by others. Allow more than one attribute, and also record duplicate entry points, reasons for waiting, and actual delivery.

During review, there is no need to rush into comparing how many tasks each person completed. First ask: Was any work that should have arisen missed? Was the same matter handled twice? Did work have to be returned because conditions were not ready? Did the person receiving a request explain the arrangements promptly? These records help reveal whether the rules are clear.

AI can help organize task sources, find possible duplicates, and flag missing materials and schedules. Whether two records concern the same matter, whether a commitment changes, and whether there is authority to execute still need to be checked under the actual rules. The four attributes do not establish that AI can independently make these judgments and bear responsibility.

Whether this method helps depends on the specific business. Does needed work arise in time? Are receipt and commitment clearer? Is completed work being assigned again? Start with something currently being done: make clear why it arose and how someone takes responsibility for it, then gradually improve the arrangements for the whole role.

Research background: the classification used to investigate work content in the author's early Methodology for Mapping and Designing SOPs, together with research on roles, work handbooks, and workflow collaboration. This article develops the four task attributes using the definitions stated here and proposes a practical way to accept responsibility for tasks. Its effects need to be tested in the business where it is used.

Optional further reading, in Chinese: Ten Steps for Enterprise Planning: Connecting Direction, Resources, and Execution; How Can a Project Schedule Advance Step by Step as Conditions Are Met?; The Four-Ecosystem Governance Model: A Cycle of Contribution, Rights, and Collaboration.