TutorialsAssignment: Turn One of Your Processes into a Runnable SOP
Three levels in one assignment — reproduce the classroom result with Prompt A, run the full six-step formula on a process that keeps stalling, then build a minimum viable version. All three parts required.
Goal
Connect the three things from class and hand in something you can take back to work:
- Reproduce: pick the process you know best and use Prompt A to break it into a state machine and step table, then check whether you can answer the three questions AI asks;
- Apply: take a process that is running but keeps stalling, or where nobody can say who does what, and run the full six-step formula — using Template 3 to find at least 5 boundary problems;
- Advance: make it real — build a minimum viable version in DingTalk AI Tables, Yida or a similar tool, run it for a while, and come back to see which steps need adjusting.
Marks come from every part being written against your actual work, not from how pretty the diagram is.
Requirements
Hand in three things only: a six-step breakdown (state machine + step table), a boundary problem list (5 or more) plus an automation assignment table, and a minimum viable version. All three are required — missing one means the assignment is incomplete.
- It must be your own process: the repair ticket from class does not count — use a real process from your role.
- Say who and where: a step with an action but no executor and no data destination does not count as broken down.
- Format: one document, or paste straight into the submission area; three screens or fewer, no long screenshots.
- Deadline: parts one and two within 48 hours of the lesson; the minimum viable version can follow within 7 days, since it has to actually run.
Run through the red lines first: check numbers, dates and names against the source; anonymise real cases before feeding them in (replace customer names, IDs and prices with placeholders); treat AI output as a draft — what lands in the system and what is promised externally is yours to confirm.
Part one: reproduce (break down a familiar process with Prompt A)
Pick the process you know best — expenses, shift scheduling, stock replenishment, weekly reports.
| Item | My answer |
|---|---|
| The process I chose (one line) | |
| The raw description I wrote (copy what you actually sent, do not polish it) | |
| AI's state machine output (states plus transition arrows) | |
| How many steps I got in the step table | |
| The three questions AI asked | |
| Whether I can answer each of the three (write "open" if not) | |
| Which question I turned into a rule, and what the rule says |
"The rule I added" must not read like "be more careful" or "improve communication". Write a clause that can be judged true or false — such as "if the customer does not respond to acceptance within 48 hours, it passes by default and the supervisor is notified", not "pay attention to follow-up timing".
This cell is where your level shows most clearly.
Part two: apply (run the six steps and hunt the boundaries)
Switch to another process — one that is running but keeps stalling, or where nobody can say who does what. This time you run all six steps.
Note the difference from part one: there you reproduced; here you take a harder object and walk the whole formula yourself. Changing the variable is how you find out whether the method really landed.
My six-step breakdown
| Step | My answer |
|---|---|
| 1. State the trigger (who / when / which event) | |
| 2. State machine (states plus transition conditions) | |
| 3. Step table (number | trigger | input | action | output | executor) | |
| 4. Data flow (what each step reads and writes, where it lives) | |
| 5. Boundary questions (see the table below) | |
| 6. Automation levels (fully automated / semi-automated / human) |
Boundary problem list (at least 5)
Run Template 3 and record what it hits. Do not fill every row — write the ones you genuinely believe will happen.
| No. | Boundary type | Concrete scenario | Impact (high/medium/low) | How I plan to handle it |
|---|---|---|---|---|
| 1 | ||||
| 2 | ||||
| 3 | ||||
| 4 | ||||
| 5 | ||||
| 6 |
The six classes for reference: concurrent conflicts, abnormal interruption, timeout, missing values, state rollback, permission isolation.
If you cannot reach five, go back to the waiting states from step six — where a process stalls, the reason is almost always next to a waiting state.
Automation assignment table
| Step | Level (fully automated / semi-automated / human) | Reason in one line | Suggested implementation |
|---|---|---|---|
| Extra | My answer |
|---|---|
| The 3 steps I think are most worth automating first | |
| Why those 3 (argue by payoff, not by difficulty) | |
| The steps I decided not to automate for now, and why |
Part three: advance (build a minimum viable version)
Get it running in a table before you talk tools. The minimum viable version does not need to look good; it needs to complete one real run.
| Item | My answer |
|---|---|
| The tool I used (DingTalk AI Tables / Yida / other) | |
| The fields or form I built (list them) | |
| The status field and its values | |
| Whether I set a reminder or timeout rule (and what) | |
| Screenshot or link of the trial run | |
| One adjustment I recorded after running it (write "none", but say why) |
You do not need to build all six steps into the system. If your process does not suit a Gantt-style board, build just three fields — registration, status, timeout reminder. Completing one small loop beats building a full system nobody uses.
Marking scheme
| Grade | Standard |
|---|---|
| ⭐⭐⭐ Excellent | All three parts; every row of the step table has an executor and a data destination; five or more boundary problems with concrete scenarios and handling; the automation priority argued by payoff, including what you chose not to do |
| ⭐⭐ Good | All three parts; the six steps completed with a coherent state machine and step table; five or more boundary problems; sensible levels in the assignment table |
| ⭐ Entry | All three parts; one complete breakdown with Prompt A; the boundary list essentially filled in |
There are only two usual reasons for missing ⭐⭐⭐: the "boundary problems" are imagined (scenarios that will not happen, while the real stalling point is missing), and the step table cannot say where the output goes — actions with no data destination.
Submitting
- Upload a screenshot of each finished piece to the site to submit.
- Pick your favourite one and post it in the course group so everyone can see your workflow.
One last reminder: always run the breakdown on a real case. A first pass misses at least 30% of the boundary cases — without real data, you will never find them.