Mapping Your First Automation Workflow

You don't need Visio or Lucidchart. You need a pen, a surface, and 15 minutes.

We've mapped workflows on napkins, whiteboards, the back of a receipt, and once on a paper placemat at a diner. (The waitress gave us a look. We tipped well.) The tool doesn't matter. What matters is the process of getting the mess out of your head and into a shape you can actually build from.

Most automation advice jumps straight to the platform — "Open Zapier, click New Zap, select your trigger." That's like telling someone to open a word processor when they haven't figured out what they want to say yet. The building is the easy part. The thinking is the hard part. And the thinking happens on paper, not in a software interface.

Here's the step-by-step method we've used to turn hundreds of messy business processes into clean, running automations. If you've already read The SMB Automation Playbook and you're ready to get tactical, this is where you start.

Step 1: Identify the Job to Be Done

Start with the outcome, not the tools. Not "I want to use Zapier" or "I want to connect HubSpot to Slack." Those are implementation details. Start with the job.

What's the job? One sentence. That's all you need.

• "New lead gets added to CRM and gets a welcome email."
• "Customer pays invoice and finance gets notified."
• "Support ticket closes and satisfaction survey goes out."
• "New employee is added to HR system and gets accounts provisioned."

That's the job. If you can't describe it in one sentence, you're probably looking at multiple workflows, and that's fine. Split them up. A workflow that tries to do five jobs is a workflow that's going to be fragile, confusing, and painful to maintain. One job, one workflow. Keep it clean.

The job is your north star for everything that follows. Every decision you make during the mapping process should point back to it. "Does this step help accomplish the job?" If yes, it stays. If no, it goes.

We had a client who came to us wanting to "automate the sales process." That's not a job. That's a category. When we broke it down, there were actually seven distinct workflows hiding inside "automate the sales process": lead capture, lead routing, meeting scheduling, proposal generation, contract creation, deal notification, and handoff to onboarding. Each one is a separate workflow with a separate trigger and a separate outcome. Trying to build them as one giant automation would have been a mess. Breaking them into seven clear jobs made each one straightforward.

Step 2: Name the Trigger

Every automation starts with a trigger, the event that kicks things off. Something happens in the real world (or in a software system), and that event says "go."

Name it specifically:

• "New form submission in Typeform" (not "someone fills out a form")
• "Deal stage changed to 'Closed Won' in HubSpot" (not "we close a deal")
• "New row added to Google Sheet" (not "data gets updated")
• "Payment succeeded in Stripe" (not "customer pays")

The more precise you are here, the easier the build will be. Vague triggers lead to vague automations that fire when they shouldn't or don't fire when they should.

Here's a test: could someone else read your trigger description and know exactly where to find it in the source system? If you wrote "new contact," which system? What counts as "new"? Created today? Created and not yet synced? Created with a specific tag? Get specific.

And here's something that trips people up: if you can't name a clear trigger, you might not have an automatable workflow yet. Some processes start with a judgment call. "When I feel like the lead is ready, I move them to the next stage." That "when I feel like" part is a human decision, not a trigger. You can automate what happens after the decision, but you can't automate the decision itself (well, you can with lead scoring rules, but that's a different conversation). Recognizing which parts of a process are automatable and which parts need a human is half the battle.

Step 3: Draw the Steps

Here's the entire notation system you need: circle, arrow, circle.

Each circle is an action that happens in a system. "Create contact in HubSpot." "Send message in Slack." "Add row to Google Sheet." "Create task in Asana." Each arrow is data flowing from one step to the next.

That's it. No swimlane diagrams. No UML. No enterprise architecture notation that requires a certification to read. Circles and arrows.

Walk through the process as if you were doing it manually. Every time you click into a different app or do a distinct action, that's a new circle. If you're processing a new lead right now, you might:

1. See the form submission come in (trigger — first circle)
2. Open your CRM and create a new contact (second circle)
3. Open Slack and post a message to the sales channel (third circle)
4. Open your project management tool and create a follow-up task (fourth circle)

Four circles, three arrows. That's your workflow diagram. It doesn't need to be pretty. It needs to be complete.

One thing we tell people: don't edit while you draw. Get the whole process down first, even if it seems too long or too complicated. You can simplify later. But if you try to simplify while you're mapping, you'll accidentally leave out steps that matter. We've seen people skip what they think are "obvious" steps ("well, of course I check the email first") and then wonder why their automation doesn't work the way they expected.

Draw the whole thing. Then step back and look at it. Then simplify if you need to.

Step 4: Identify the Data

Look at each arrow in your diagram and ask: what information needs to travel along this line?

Write the field names on the arrows. Actually write them. "First name, last name, email, company name, deal amount." This is your field mapping guide, the literal list of "this field in System A maps to this field in System B."

Here's why this matters so much: automation platforms don't move "contacts" or "deals" or "tasks." They move fields. Individual pieces of data. First name goes here. Email goes there. Amount goes in this column. If you don't know which fields need to move, you'll spend an hour clicking around in your automation builder trying to figure it out. If you do know, the build takes ten minutes.

A practical example. Let's say your workflow is: "New Typeform submission creates a contact in HubSpot and sends a Slack notification."

Arrow from Typeform to HubSpot: first name, last name, email, phone number, company name, "How did you hear about us?" response.

Arrow from HubSpot to Slack: contact name, company name, HubSpot contact URL.

See how the data changes between steps? You don't dump everything into Slack. The sales team just needs to know who signed up and a link to go look at the full record. Thinking about data at each step prevents the "everything goes everywhere" problem that makes automations noisy and hard to debug.

▶📋Common data mapping traps to watch for

Watch for the data traps. Here are the ones we see most often:

Fields that exist but are empty. Your form has 10 fields, but only 3 are required. What happens when someone skips the optional ones? Your automation needs to handle blanks.

Fields that don't match across systems. "Company" in Typeform, "Company Name" in HubSpot, "Account" in Salesforce. Same concept, different labels, sometimes different formats.

Fields that need transformation. Your form collects a full name ("Jane Smith") but your CRM has separate first and last name fields. Someone (or something) needs to split that string.

Dates. We could write an entire post about dates in automation. (We probably should.) Different systems store dates in different formats. "01/02/2025" is January 2nd or February 1st depending on where you are. ISO 8601 is your friend. Assume dates will cause you problems and you'll be pleasantly surprised when they don't.

Getting the data right on paper saves you an hour of trial-and-error in the builder. We can't say this strongly enough.

Step 5: Add Conditions (If You Need Them)

Does the flow branch? "If the lead is in the US, route to the US sales team; otherwise, route to international." "If the deal is over $10K, notify the VP; if it's under $10K, just notify the account manager."

Add a diamond shape for decision points. Diamonds are the universal symbol for "if/then" in flowcharts, and automation platforms use the same concept. They just call them "filters," "routers," or "paths."

But here's the thing: only add branching if you actually need it. Most first workflows are linear. Trigger, step, step, done. A straight line from A to B to C.

Conditions add complexity. Complexity is where automations break. Every branch doubles the number of paths you need to test. Two branches means two paths. Three branches means three paths. A branch with a branch inside it means you're building a decision tree, and decision trees in automation platforms are a pain to debug when something goes wrong at 2am on a Saturday.

Start linear. Get it working. Run it for a week. Then look at the data and ask, "Do I actually need branching here, or is the linear version good enough?" You'll be surprised how often "good enough" is, in fact, good enough.

If you do need branching, keep it to one level deep in your first workflows. "If X, do this; otherwise, do that." Save the nested conditions for when you're more comfortable with the platform and you've got a debugging process figured out.

Step 6: Translate to Your Platform

Now, and only now, do you open your automation platform. Zapier, Make, n8n, Power Automate, whatever you've chosen. (Not sure which one? The Automation Platform Decision Matrix can help.)

Take your diagram and translate it:

• Each circle becomes a step in your workflow
• Each arrow becomes a field mapping
• Each diamond becomes a filter or router

The diagram IS your build plan. You're not designing in the tool. You're implementing a design you already finished. This is the difference between "I'll figure it out as I go" (which leads to spaghetti automations that nobody can maintain) and "I know exactly what I'm building" (which leads to clean, documented workflows that still make sense six months from now).

Here's what this looks like practically. You open Zapier, create a new Zap. Step one: Typeform, new submission. You connect your Typeform account, select the right form. Step two: HubSpot, create contact. You map first name to first name, last name to last name, email to email. You're literally reading from the field list you wrote on your napkin. Step three: Slack, send channel message. You compose the message template with the contact name and HubSpot link.

The whole build takes 15-20 minutes because you did 15 minutes of thinking first. Without the diagram, the same build takes an hour because you're making design decisions and implementation decisions at the same time, and your brain doesn't like doing both at once.

Test with real data. Don't just hit "test" in the builder and call it done. Submit an actual form. Go look at HubSpot and make sure the contact was created correctly. Check Slack and verify the message looks right. Check the fields. Check the formatting. Check for edge cases (what happens if someone enters just a first name and no last name?). Testing takes five minutes and saves you from discovering a broken field mapping after 50 records have already flowed through.

Common First Workflows

If you're staring at a blank napkin wondering where to start, here are the workflows we see most often as someone's first build. All of them are linear, low-risk, and high-visibility. Perfect for building confidence and demonstrating what's possible.

Form to CRM. A form submission on your website (Typeform, Google Forms, Gravity Forms, whatever) creates or updates a contact record in your CRM. This is probably the single most common first automation in existence, and for good reason: it eliminates the most universally annoying manual task, which is retyping information that someone already typed into a form.

CRM to email. New contact created in your CRM triggers a welcome email or a sequence enrollment. This is a close second. The contact exists, they've expressed interest, and you want to follow up. Automatically.

Payment to notification. Successful payment in Stripe (or PayPal, or Square) triggers a Slack message to the team. "New payment: $X from Company Y." Simple, satisfying, and it gives the whole team visibility into revenue without anyone checking a dashboard.

Calendar to task. New calendar event creates a task in your project management tool. Meeting with a prospect tomorrow? There's now a follow-up task in Asana with the prospect's name and meeting date. No more "I forgot to create a task for that meeting."

Ticket resolution to survey. Support ticket gets closed (in Zendesk, Freshdesk, or your help desk of choice) and the customer automatically gets a satisfaction survey. This one's slightly more advanced because you're sending something to an external person, so test it carefully. But it's a high-value automation that most support teams want immediately.

The Napkin Is the Point

We want to make something clear: the napkin sketch isn't a shortcut or a hack or a workaround. It IS the methodology. Professional integration developers (hi, that's us) do this same process, just with fancier tools and more detailed diagrams. The underlying discipline is identical: understand the job, name the trigger, map the steps, identify the data, add conditions only when necessary, then build.

The diagram forces you to think through the workflow before you're distracted by dropdown menus and configuration screens. It reveals gaps in your thinking. ("Wait, what happens if the contact already exists in HubSpot? Do I create a duplicate or update the existing record?" — a question that's easy to ask on paper and easy to miss in a builder.) It gives you something to show to a colleague and say, "Does this look right?" before you've invested any build time.

And when something breaks six months from now (and something will break), that diagram tells you exactly where to look. Step three failed? Go look at the Slack message step. Field mapping wrong? Check the arrows. Trigger not firing? Look at step one.

Fifteen minutes with a pen. That's the investment. Everything after that is just implementation.

---

This post is part of The SMB Automation Playbook, a series on practical automation for small and mid-size businesses.