Set Up a Shared Team Workflow

Turn a workflow that already works into a method a team can trust and repeat.

Start from an accepted real example.

Do not use this workflow to turn an untested idea into team policy.

1. Start from the proven workflow

Identify:

• workflow;
• output;
• people who use it;
• people who depend on it;
• accepted example.

Reconstruct how the accepted result was actually produced across:

• messages;
• files;
• browser tabs;
• documents;
• project tools;
• connected apps;
• human judgment.

If no accepted example exists, calibrate one focused workflow first.

2. Separate durable method from personal context

Agree on:

• trigger;
• intended result;
• required inputs;
• source of truth;
• owner;
• contributors;
• reviewers;
• handoff;
• shared destination;
• source links;
• decisions the assistant may make;
• decisions requiring human review;
• privacy boundaries;
• client boundaries;
• employee/candidate boundaries;
• exceptions;
• stop conditions.

Choose the smallest sharing layer that solves the problem.

Possible levels:

• share the artifact;
• create a team skill;
• share broader approved assistant context when several workflows genuinely require it.

Treat these as separate choices.

3. Build reusable guidance

Convert the accepted workflow into concise instructions another teammate or assistant can follow without guessing.

Preserve:

• judgment rules;
• source priority;
• expected output;
• review points;
• escalation logic.

Do not copy:

• personal notes;
• incidental steps;
• temporary workarounds

into the shared method.

Use the team's actual workspace and approved systems.

Put shared guidance and artifacts where intended users can access them.

Verify:

• links;
• permissions;
• fields;
• destinations

for someone other than the original owner.

4. Pilot a real handoff

Run the workflow on one representative task with the people who will own and review it.

Check whether they can:

• find inputs;
• understand the output;
• correct judgment;
• approve actions;
• continue the next step.

Keep the pilot small.

Surface:

• unclear ownership;
• unavailable context;
• permission gaps;
• conflicting source definitions;
• tribal knowledge.

Update the shared workflow from accepted corrections.

Rerun failed handoffs before scaling.

5. Define recurring operation precisely

Once the pilot works, define:

Trigger

The event, state change, or cadence that starts the workflow.

Systems Checked

The exact approved sources.

Actions

What the workflow gathers, compares, drafts, creates, or proposes.

Output

Where the result appears and who reviews it.

Approval Behavior

Which writes, messages, permission changes, or record changes require a person.

Stop Conditions

Conditions such as:

• missing identity;
• conflicting sources;
• unavailable permissions;
• sensitive context;
• unresolved judgment.

Do not add recurrence simply because scheduling is technically available.

Keep it as a reviewed proposal when:

• trigger is weak;
• workflow is still changing;
• on-demand use is sufficient.

6. Hand over the complete operating method

Deliver together:

• verified team skill;
• shared destination;
• ownership map;
• pilot result;
• recurring-operation plan;
• unresolved gaps;
• temporary manual steps.

Use feedback from real runs to improve the workflow.

Do not let one exception rewrite the method automatically.

Review:

• ownership;
• permissions;
• source meanings;
• approval behavior

when the team or systems change.

Keep these separately approved:

• sharing the method;
• inviting teammates;
• enabling recurrence;
• making external changes.