Memuat
Memuat
Want to go deeper?
Join one of our courses or ask us directly on WhatsApp.
Picked from the software, topic, and level of “Claude from Zero to Expert Class #39: Flowcharts and Process Maps”.
Other ways we can help with Claude.
Learn with a mentor
Scheduled AI & Machine Learning courses with live guidance and a certificate.

Midjourney Course: Create Stunning AI Images from Text
★ 4.9

DALL-E Course: Creating Professional AI Images from Text
★ 4.9

Stable Diffusion Course: AI Art from Beginner to Professional
★ 4.9
Have it built for you
No time to learn Claude? Our team can do the project for you.

AI Image Creation with Stable Diffusion — Unlimited Custom Visual Production
★ 4.9

AI Image & Video Creation with Leonardo AI — All-in-One Visuals for Business
★ 4.9

AI Image Creation with Midjourney — Cinematic AI Art for Business
★ 4.9
Get notified about new Claude classes
At most one email a week. Unfollow anytime with one click.
The full narration of this video. The current sentence is highlighted while the video plays; click any sentence to jump there.
Hi, and welcome back to the Intermediate Artifacts session. After the dashboard, the quiz, and the order form, we now build something that helps a team understand how work gets done. In this episode we turn the story of a work process into a flowchart and a process map, find the bottlenecks, then turn it all into a short SOP.
Why should a work process be drawn? First, new employees understand it quickly. They see the whole sequence of work in one picture, without asking at every step. Second, bottlenecks become obvious. Slow steps, or work that's often repeated, stand out as soon as the process is drawn. Third, the diagram becomes the basis for an SOP, a standard operating procedure that's written down and agreed on by the team. The first step is describing the process as it is. Dewi writes out the Maju Bersama Co. order process in everyday language: a store sends an order to Bayu, it goes on to Andi in the warehouse, Wulan makes the invoice, and the courier delivers. Claude doesn't start drawing right away. It asks three questions that are often forgotten: do new stores need credit approval, what happens when stock is only partly available, and when is the process considered finished. Dewi answers all three. New stores need Dewi's approval, partial stock is still shipped in part, and the process ends when the store receives the goods. Questions about exceptions like these are crucial. A smooth process rarely causes trouble. Problems usually show up in the branches nobody ever wrote down.
Step two is turning the story into a flowchart. Dewi asks for a complete diagram with every decision and branch. The diagram appears in the right panel. There are ovals for start and end, boxes for steps, and diamonds for decisions. The process starts when a store sends an order, then Bayu logs it. Look at the decision points. If the store is new, Dewi has to approve credit. If there's only enough stock for part of the order, part is shipped and the rest follows. The process ends when the store receives the goods, just as Dewi answered. Every branch that used to live only in the team's heads is now written in one picture. Dewi opens the Code tab and asks whether she needs to learn it. Claude explains that this is a diagram code called Mermaid. Each line is one step and its arrow. For example, the line from C to D labeled Yes means: if the store is new, go on to credit approval. You don't need to learn this code. To change the diagram, just write a normal request, such as add a step to confirm with the store after the goods are shipped. To read any diagram easily, learn three basic symbols. Ovals are for start and end. Every process needs a clear beginning and end. Boxes are for work steps. A good rule: one box holds one task done by one person. Diamonds are for decisions, which are questions with a yes or no answer. Every diamond must have at least two arrows coming out of it.
Step three is building a process map. How is it different from a flowchart? A flowchart answers the question, what's the order? A process map answers who does the work, how long it takes, and which documents it uses. The shape is different too. A flowchart is a picture with arrows, while a process map is a table. A flowchart is good for understanding a process at a glance. A process map is good for finding bottlenecks and calculating wasted time. So the readers are different as well. Flowcharts are for new employees, even customers. Process maps are for managers and teams who want to improve how work gets done. Both are built from the same process story. Dewi asks Claude to turn the diagram into a process map. She gives the average time for each step from her team's records over the past month, not from guesses. The process map appears as a table. Logging the order takes fifteen minutes by Bayu, credit approval one day by Dewi, the stock check two hours, preparing the goods three hours, and the invoice thirty minutes. Below it is a summary: an existing store's order is done in about one day, while a new store's takes about two days. And the longest step turns out to be credit approval, by Dewi herself. This finding surprises Dewi a little. All along she thought the warehouse was the slowest. That's the value of a process map: data replaces gut feeling.
Step four is finding the bottlenecks. Dewi asks for the two biggest bottlenecks and realistic fixes for a small distributor. The first bottleneck is credit approval. Claude suggests a starting credit limit for new stores that Bayu can approve himself, for example for a small first order. It also names the risk: you need a clear limit rule. The second bottleneck is the two-hour manual stock check. The suggestion: keep stock in a shared spreadsheet that Bayu can see, so Andi only needs to confirm large orders. These suggestions make sense, but the decision stays with Dewi and the team. Dewi takes both suggestions to the Monday meeting and asks for Bayu's and Andi's views before trying them. Once the team agrees, Claude helps build a before-and-after comparison. First, new store credit. It used to always wait for Dewi; now a small first order only needs Bayu's approval. Second, the stock check. Bayu sees the stock in the shared spreadsheet, and Andi only checks large orders. Third, the time for a new store's order is expected to drop from two days to about one day. Fourth, one thing is monitored during the trial: the number of new stores that pay late. Every improvement brings risk, so the risk needs to be watched with numbers.
The last step is turning the new process into an SOP. Dewi asks for a one-page SOP that can be pinned in the team group and read by new employees. The SOP appears with five numbered steps. Each step names its owner, including the new credit approval rule and the confirmation step with the store at the end. The exceptions sit at the bottom so they're easy to find. The small-order limit is deliberately kept general here, because the amount is decided by Dewi and the team, not by Claude. Before using them, check four things. First, the diagram and SOP are checked by the people who run each step. Bayu, Andi, and Wulan each read their own part. Second, every decision has a yes branch and a no branch. A missing branch is a source of confusion on the ground. Third, the times come from real records, not estimates. Fourth, there's a version date and the name of whoever updated it. Laras can use the same pattern for Sunset Coffee's order flow, from an incoming chat until the courier leaves, and Mr. Hendra for registering new students. Let's sum up. First, describe the process as it is, including its exceptions. Second, ask Claude to draw it as a flowchart. Third, build a process map with owners, timing, and documents. Fourth, find the bottlenecks and try one improvement first, together with the team. Fifth, standardize it as an SOP with a version date, and share it through an Artifact link so everyone reads the same version.
We've turned the story of a work process into a flowchart, built a process map with owners and timing, found the bottlenecks, and turned it all into a short SOP. In the next episode we close the Intermediate Artifacts session with practice: building a mini app to use with your team, from design all the way to sharing. See you there!
Try these on your own after watching to lock in what you learned.
Type a question or keyword; we find the part of this episode that explains it and jump the video there.
Notes are saved with the current video time and are only visible to you.
Stuck on a step? Ask here; the instructor and other learners can answer.
No questions yet.

Cerdas Inovasi Digital Team
Software developers, BIM & 3D engineers, and AI practitioners
We build software, BIM models, games and AI automations for clients every day, and turn that hands-on work into step-by-step classes: every step is shown on screen and comes with a PDF guide you can keep.
See our clients →