Most SMEs do not fail because they lack software. They fail because work falls between software.
If your team is spending its day copying data between HubSpot, Google Sheets, Gmail and Slack, you already have a workflow. It is just a human one, and it does not retry when it breaks.
The short version
- If a process has duplicate entry or copy paste, it is already an integration spec, you just have not written it down yet.
- The best first automations are low risk and high volume: routing, reminders, approvals and data sync between two systems.
- Plan for failure modes up front: retries, idempotency, rate limits, and a clear owner for ongoing maintenance.
- Estimate impact using three numbers you can collect this week: volume per week, minutes per item, and error or rework rate.
What counts as workflow automation, in practical terms?
Workflow automation is moving a repeatable handoff from a person to a system: a trigger happens in one tool, a defined set of actions runs in one or more other tools, and you can see what happened afterwards.
In n8n and Zapier, that usually means:
- A trigger: webhook received, new email, form submitted, record updated.
- A small amount of logic: filters, lookups, validation, deduplication.
- Actions: create or update a HubSpot record, post a Slack message, write a row in Sheets, send an email.
- Operational hygiene: retries, error alerts, and an audit trail.
That last bullet is where a lot of popular advice is wrong. People talk about automation like it either works or it does not. In reality it works until it hits:
- A rate limit (Slack and HubSpot have method and endpoint limits, Google APIs have quotas). See Slack’s rate limits and Google’s Sheets API usage limits.
- A transient failure (network wobble, API timeout) where you want retry.
- A permanent failure (bad data, missing field) where you want a human in the loop.
n8n supports node level retries and a dedicated error workflow to catch failed executions, which is how you avoid silent failures in production. See n8n’s documentation on error handling.
Ten signs your business is begging for workflow automation
Below are ten signs we see in UK ops, finance and customer service teams. Each one maps to a specific automation pattern you can run with n8n or Zapier.
Use it like a triage list: pick the top one to three that happen most often, in the most critical processes.
1) People copy and paste the same fields all day
Sign: Names, emails, order IDs, ticket summaries, and amounts are being copied from Gmail into HubSpot, or from HubSpot into Sheets.
Automation pattern: Event driven create or update
- Trigger: new email in Gmail, or new HubSpot form submission.
- Steps: parse key fields, validate, then create or update the HubSpot contact, and add a row in a tracking Sheet.
- Where it fails: messy inputs. You need validation and a “needs review” queue.
Impact estimate: volume per week × minutes of copy paste. If it is 200 items at 2 minutes each, that is about 6 to 7 hours a week.
2) Follow ups get missed, especially after handoffs
Sign: A customer asks for something, it gets acknowledged, and then it sits. The team only notices when the customer chases.
Automation pattern: SLA timers and escalations
- Trigger: HubSpot deal stage changes, or a new customer service tag in Slack.
- Steps: set a due date, post a reminder to the owning channel, and escalate if not updated.
- Mechanism detail: HubSpot workflow triggers and enrolment rules matter. You need to be clear what changes should enrol and whether re enrolment is allowed. Start with HubSpot’s guidance on workflow enrolment triggers.
Impact estimate: count missed follow ups per month and tie them to churn risk or refunds. Even a few a month can justify the build.
3) Approvals happen in DMs or email threads, and nobody can find the decision
Sign: Refunds, discounts, write offs, and exceptions are “approved” in Slack messages. Then finance asks, “Who approved this?”
Automation pattern: Approval workflow with an audit trail
- Trigger: a Slack message with a specific format, or a Google Form submission.
- Steps: capture the request in Sheets, notify approver in Slack with buttons, log the decision, and notify the requester.
- Failure mode: duplicates and people clicking twice. You need idempotency, one request ID that you check before acting.
Impact estimate: measure approval cycle time. Automation often saves more time in interruptions than in the raw clicks.
4) The same record exists twice, and nobody knows which one is real
Sign: Duplicate HubSpot contacts, duplicate deals, and multiple Sheet tabs called “Final v3”.
Automation pattern: Master record and deduplication checks
- Trigger: new contact created in HubSpot.
- Steps: search for existing matches, merge or flag for review, then write the canonical ID back to the tracking Sheet.
- Where advice is wrong: “Just sync both ways” creates oscillation and overwrites. Pick a system of record per field.
Impact estimate: count how many times staff have to “fix the CRM” per week, and how often duplicates cause customer facing mistakes.
5) Reporting is slow because it is assembled by hand
Sign: Weekly numbers involve exporting CSVs, pasting into Sheets, and chasing owners for missing data.
Automation pattern: Scheduled data pulls to a reporting Sheet
- Trigger: scheduled run.
- Steps: pull data from HubSpot, append or update a reporting Sheet, then post the snapshot in Slack.
- Mechanism detail: Google Sheets API has quotas and batch requests count towards limits, so build with batching in mind. See Google’s Sheets API limits.
Impact estimate: time to produce the report × frequency, plus the hidden cost of decisions made on stale data.
6) Customer service spends time forwarding and re categorising emails
Sign: “Can you send this to accounts?” “Is this a bug or a how to?” “Who owns this customer?”
Automation pattern: Inbox triage and routing
- Trigger: new email in a shared inbox label.
- Steps: apply rules based on subject, sender domain, and keywords, then notify the right Slack channel and create or update a HubSpot ticket or record.
- Failure mode: email API quotas and concurrency. Gmail’s API enforces usage limits and concurrent request limits, so avoid building a solution that spikes requests per message. See Gmail API usage limits and handling errors.
Impact estimate: count forwards per day. If ten people forward five emails a day and it takes 30 seconds each, that is over an hour a day of pure routing.
7) People are maintaining ‘shadow spreadsheets’ because the CRM is not trusted
Sign: Teams keep their own Sheets because HubSpot is incomplete or out of date.
Automation pattern: Write through updates
- Trigger: change in the spreadsheet, or change in HubSpot.
- Steps: validate, then update the other system, and post a confirmation in Slack.
- Honest trade off: two way sync is hard. If you do not define ownership by field, you will create data fights.
Impact estimate: measure time spent reconciling discrepancies, plus the cost of missing a sales or service action.
8) Every onboarding or renewal looks like a checklist someone remembers from last time
Sign: Customer onboarding relies on someone “doing the usual steps” across HubSpot, Gmail, Slack, and a tracking Sheet.
Automation pattern: Orchestrated checklist with state
- Trigger: deal moved to “Won” in HubSpot.
- Steps: create tasks, create a shared folder or record, post the onboarding brief to Slack, and schedule reminders.
- Mechanism detail: if you are using Zapier, understand task based pricing because each action can consume tasks. Zapier’s own explanation of what a task is is the right starting point.
Impact estimate: compare time to onboard before and after. Also measure “time to first value” for the customer if you can.
9) People are building brittle one off Zaps that nobody owns
Sign: Automations exist, but when someone leaves, they break. Or they quietly stop and nobody notices.
Automation pattern: Operationalise automations: error alerts, retries, and ownership
- For n8n: use node retries and an error workflow. n8n documents how to handle failures with an error workflow.
- For Zapier: prefer webhook style triggers where possible, rather than constant polling, and document the “source of truth” for each field. Zapier’s developer docs explain why webhook style triggers have advantages over polling, see Rest Hooks.
Impact estimate: count incidents per quarter caused by automation breaks, and the time to diagnose. That is where ROI often hides.
10) You keep hitting rate limits, plan limits, or ‘it works on small volumes’ ceilings
Sign: At low volume things are fine. At high volume you see Slack errors, HubSpot API issues, or Sheets throttling.
Automation pattern: Backpressure and batching
- Steps: queue work, batch API calls, and slow down when rate limits are hit.
- Example: Slack’s Web API is rate limited per method, per workspace, with tiered limits. Slack documents this in its rate limits guidance.
- For HubSpot: API rate limits change over time and are exposed via response headers. HubSpot has documented increases to limits and notes these are reflected in `X-HubSpot-RateLimit-` headers, see the HubSpot developer changelog on API limits.
Impact estimate: this is often the sign that you need either a more robust n8n build, or custom code for a high volume edge case.
Which of these should you automate first?
Do not start with the most annoying task. Start with the one that is both frequent and predictable.
A quick decision framework:
- Volume: How many times a week does it happen?
- Time per item: How long does it take end to end, including interruptions?
- Failure cost: What happens when it goes wrong: churn, refunds, compliance risk, or just annoyance?
- Data clarity: Are the inputs structured enough that an automation can decide what to do?
If you want a rule of thumb: pick a workflow where the trigger is unambiguous (for example a HubSpot stage change), and the actions are mostly writes (create update) rather than judgement calls.
Swarm Labs has a small internal product called Time Hive which logs automation runs and works out hours saved. Even if you never use it, the idea is right: you need a ledger of runs, failures, and time saved, not a one off “we think it helped”.
What information do you need to brief an automation build?
If you can answer the questions below, you can brief a build properly, whether you do it in house or with a studio.
A 10 point audit checklist
- What is the trigger, and where does it happen (HubSpot, Gmail, Slack, Sheets)?
- What data must be captured, and what fields are mandatory?
- What is the source of truth per field (email, phone, company name, status)?
- What actions should happen, in what order?
- What should happen on “known bad” inputs (missing amount, unknown customer)?
- What should be retried, and how many times?
- How do we prevent duplicates (idempotency key, check before create)?
- Who gets alerted on failure, and where (Slack channel, email)?
- What are the relevant quotas and rate limits (Slack, Gmail, Sheets, HubSpot)?
- Who owns the automation after go live (and what is the change process)?
The Scorecard lead magnet
We keep a Workflow Automation Readiness Scorecard as a Google Sheet and pair it with the checklist above. It helps you rank candidates by impact and risk, and it forces the “who owns it” question early.
If you want more examples of common patterns across tools, our /integrations/ library is a useful place to browse, even just to name what you want.
Getting it built is not the hard part, keeping it reliable is
The build is usually straightforward: a few triggers, some field mapping, some filters.
Reliability is where you earn the hours back:
- Retries: in n8n, set node retries for flaky network calls, and wire an error workflow so failures do not vanish. n8n’s error handling docs cover the mechanism.
- Backpressure: batch writes to Sheets, and avoid hammering Slack methods that have tight limits.
- Observability: log inputs and outputs. If you cannot explain why an action happened, you will not trust it.
- Maintenance: APIs change. People change fields. Someone needs to own updates.
If your workflow sits at the boundary of a customer experience, treat it like production software.
When you want your first automations to stay working
Swarm Labs is a UK software studio in Manchester. We build internal tools and APIs, and connect business tools with n8n, Make, Zapier or custom code.
Our Workflow Automation Build and Managed Optimisation service exists for teams who want the first one to three automations to be boringly reliable, with retries, alerts, and someone accountable for changes. If you want to talk through your top candidates, talk to us about your integration.
Sources
- n8n Docs: Error handling
- HubSpot Knowledge Base: Set your workflow enrollment triggers
- Zapier Blog: What is a task in Zapier?
- Slack API: Rate Limits
- Google for Developers: Usage limits for Google Sheets API
- Google for Developers: Gmail API usage limits
- HubSpot Developers Changelog: Increasing our API limits
- Zapier Developer Platform: Polling for new data with a trigger (Rest Hooks vs polling)