Your First 30/60/90 Days of Automation

If we walked into your company tomorrow (sales, ops, marketing, whatever the role) here's exactly what we'd do about automation in the first three months. Not theory. Not "it depends." This is the actual playbook we've used across a dozen companies over 12+ years of building integrations.

The temptation is always to start building on day one. You see the mess, you know how to fix it, and your fingers itch to open Zapier and start wiring things together. Don't. The companies that get automation right follow a pattern, and it starts with keeping your hands off the keyboard.

We covered the big-picture thinking in The SMB Automation Playbook: what to automate, how to prioritize, how to choose a platform. This post is the tactical version. The "what do I actually do on Monday morning" version.

Days 1-30: Observe and Document

Don't touch anything yet. Seriously. We know that sounds painful, especially if you were hired specifically to "fix things." But the single most expensive mistake in automation is building the wrong thing confidently. And you will build the wrong thing if you don't understand the business first.

Your job in the first month is to watch, ask questions, and build what we call your "architecture view" of the business.

Map the landscape. List every tool the company uses. Not just the ones on the official tech stack. The shadow IT, too. The Google Sheet that accounting uses because the reporting in QuickBooks isn't flexible enough. The personal Trello board the ops manager set up because Monday.com felt like overkill for their task list. The shared inbox that three people monitor but nobody owns. All of it.

Map the people. Who uses what? Who's the power user of HubSpot? Who barely logs into the CRM? Who has the institutional knowledge about why things work the way they do? (There's always one person who knows where the bodies are buried. Find that person. Buy them coffee.)

Shadow the workflows. Sit next to people while they work. Not in a creepy way. Just ask if you can watch them do their job for 30 minutes. You'll learn more from watching someone process an order than from reading a process document. Process documents describe how things should work. Shadowing shows you how things actually work. The gap between those two things is where your best automation opportunities live.

Listen for the magic phrases. Every time someone says one of these, write it down:

• "I hate doing this"
• "This takes forever"
• "I do this every single day"
• "I wish there was a way to..."
• "We tried to fix this once but..."
• "I just copy it from over here and paste it over there"

That list is gold. It's not a list of automation ideas. It's a list of pain points ranked by emotional intensity. The things people complain about most are usually the things worth fixing first.

Build your process inventory. By the end of month one, you should have a document (a spreadsheet works fine) with columns for: process name, who does it, how often, which tools are involved, how long it takes, and a pain rating from 1-5. This inventory is the foundation for everything that comes next.

▶💬Real story: When the biggest pain point isn't what you think

We had a client once, a 30-person professional services firm, where the founder swore the biggest time sink was proposal generation. "We spend hours on proposals," he told us. When we actually mapped the workflows, the real time sink was the intake process after a deal closed. The proposal took an hour, sure. But the post-close intake process involved seven people, four tools, and roughly six hours of cumulative work per new client. Nobody noticed because the pain was distributed across the team. The founder only felt the proposal pain because he was the one writing proposals.

That's why you observe before you build. The loudest pain isn't always the biggest pain.

Skip this step and you'll automate the wrong things. We've seen it happen more times than we can count. Someone shows up, builds a beautiful automation for a process that runs twice a month, and ignores the one that runs 200 times a month because it wasn't as visible. Thirty days of observation saves you from months of misdirected effort.

Days 31-60: Quick Wins

Now you build. But small. You've got your process inventory. You've got your pain ratings. You know where the real bottlenecks are. Time to pick your first targets.

Choose 2-3 automations from your list. Not the biggest, most complex ones. The ones that are high-impact and low-effort. Think of it as the bottom-right quadrant of an effort/impact matrix: stuff that doesn't take long to build but makes a noticeable difference to someone's day.

Here's the kind of thing we're talking about:

• Notifications. A Slack message when a deal closes in Salesforce. An email to the project manager when a new client is added to the CRM. A Teams notification when a support ticket has been open for more than 48 hours. These are dead simple to build (usually one trigger, one action) and they make information visible that was previously buried in a tool someone checks twice a day.

• Simple data syncs. New contact in HubSpot automatically creates a contact in your email marketing tool. New deal in your CRM creates a row in the revenue tracking spreadsheet. New calendar event creates a task in your project management tool. Two systems that should share data but currently require someone to type the same information twice.

• Status updates. When a project status changes in Asana, update the corresponding record in your CRM. When a payment comes through in Stripe, mark the invoice as paid in your accounting tool. These eliminate the "I forgot to update the other system" problem that plagues every team running on multiple tools.

The key word is non-destructive. Nothing that deletes data. Nothing that sends emails to customers (not yet). Nothing that touches billing. You want automations where the worst-case failure mode is "we got an extra Slack notification" or "there's a duplicate record we need to clean up." Not "we accidentally emailed 500 clients" or "we deleted last month's invoices."

Show, don't tell. When your first automation works, demo it to the team. Not a formal presentation. Just pull someone over to your screen and say, "Hey, watch this. When I mark this deal as closed, look what happens in Slack." People's eyes light up when they see it. That's not just nice to have. It's how you build organizational buy-in for the bigger stuff that comes later.

Document as you go. For every automation you build, write a one-paragraph description: what it does, what triggers it, what systems it touches, and what to check if it stops working. This doesn't need to be fancy. A shared Google Doc is fine. But it needs to exist, because you're building the foundation for the next phase.

Days 61-90: Systems and Habits

This is where most people stall out, and it's the phase that separates one-off automation from a real capability. You've proven the concept. You've built some quick wins. People are starting to get it. Now you need to make it sustainable.

Build your backlog. Take your process inventory from month one, add the ideas that came up during month two (and they will — once people see automation working, they start generating ideas), and organize everything into a ranked backlog. We use a simple scoring system: impact (1-5) multiplied by frequency (1-5), divided by estimated effort (1-5). The highest scores float to the top. It's not scientific, but it's better than guessing or building whatever the loudest person in the room wants.

Set up a review cadence. This is the single most important thing you do in month three, and it's the thing most people skip. Set a recurring 30-minute meeting, every two weeks, where you review your automations. Are they still running? Have any failed? Has a process changed that makes an automation obsolete? Are there new opportunities? Without this meeting, your automations will slowly drift out of alignment with reality, and six months from now, half of them will be silently broken.

Train at least one other person. This is non-negotiable. If you're the only person who understands the automations, you haven't built a capability. You've built a dependency. You don't need to turn someone into an automation expert. You need someone who can look at a Zapier workflow, understand what it does, and know how to check if it's working. Think of it as the "hit by a bus" test (or the less morbid "won the lottery and quit" test). If you disappeared tomorrow, could someone keep the lights on?

Connect automation to business metrics. This is how you justify expanding the effort. "We automated the client intake process and reduced average onboarding time from 8 days to 3 days." "We automated lead routing and response time dropped from 4 hours to 12 minutes." "We eliminated 15 hours per week of manual data entry across the team." Real numbers. Real outcomes. The kind of thing that makes a CFO stop raising their eyebrows when you ask for budget.

Start thinking about governance. We know, "governance" sounds like a big-company word. But even in a 10-person team, you need basic rules: Who can create automations? Where do they live? How are they named? Who gets notified when one fails? What's the process for requesting a new one? You don't need a 40-page policy document. You need a half-page set of ground rules that everyone can follow.

The Anti-Pattern: What Not to Do

We want to be explicit about the failure modes because we've seen every single one of them.

Don't try to automate everything in week one. We've watched people build 15 Zaps in their first week, each one a little house of cards that nobody else understands. Each one built without understanding the data, the edge cases, or the downstream effects. By week three, half of them are broken and the other half are producing garbage data that someone has to clean up manually. The net time saved is negative.

Don't build complex multi-step flows before you understand the data. You'll get field mappings wrong. You'll miss edge cases. You'll discover that "company name" in the CRM doesn't match "account name" in the billing system because one sales rep types "Acme Corp" and another types "ACME Corporation" and a third types "acme." Data is messy. Understand the mess before you try to automate around it.

Don't be the automation hero who disappears. If you build a web of workflows and leave no documentation, no training, and no one who can troubleshoot them, you haven't automated anything. You've just created a new single point of failure: yourself. The whole point of automation is to make the business less dependent on any individual person. If your automation makes the business more dependent on you, you've done it backwards.

Don't skip the boring stuff. Naming conventions. Error notifications. Documentation. Testing with real data before going live. None of this is exciting. All of it is essential. The difference between an automation that runs reliably for two years and one that breaks after two months is almost always in the boring details.

What This Looks Like in Practice

The 30/60/90 framework scales to any role. Here's how it plays out for different people:

The ops manager spends their first 30 days mapping the order-to-fulfillment pipeline. They discover that order confirmation, inventory check, shipping notification, and delivery tracking involve five different tools and two manual handoffs. In month two, they automate the status notifications (order confirmed, shipped, delivered) so the team stops checking three dashboards. In month three, they build a simple ops dashboard that pulls automation run data and connects it to operational KPIs — average fulfillment time, error rate, customer satisfaction scores.

The sales rep documents their lead follow-up process and realizes they spend 45 minutes every morning updating the CRM with notes from yesterday's calls. In month two, they automate CRM data entry from their call tool and set up Make to automatically schedule follow-up tasks based on deal stage. In month three, they work with marketing to set up lead scoring triggers that surface hot leads before they go cold.

The marketing coordinator maps the campaign launch checklist and finds 14 steps, 8 of which are "copy this thing into that tool." In month two, they automate asset distribution (new blog post triggers social media drafts, email newsletter inclusion, and Slack announcement) and set up automated reporting pulls. In month three, they build a repeatable campaign-launch workflow that the whole marketing team can use.

The founder wearing all hats? Same pattern, just compressed. Observe for a week instead of a month. Build one automation in week two. Systematize it in week three. Repeat. The framework doesn't change — the timelines just shrink to match the pace.

The Bigger Point

The 30/60/90 approach works because it respects a truth that most automation advice ignores: you can't fix what you don't understand. Tools are easy. Understanding is hard. And the understanding phase is the part that everyone wants to skip because it doesn't feel like progress.

But it is progress. It's the most important progress you'll make. Because the difference between a company that automates well and one that automates badly isn't the platform they chose or the number of workflows they built. It's whether they took the time to understand their own business before they started rewiring it.

Start by watching. Build trust with quick wins. Then make it sustainable. That's the playbook.

---

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