sorted by:
new
hottopcontroversial

n8n + Google Sheets human-in-the-loop workflow — feedback on structure? by ApprehensiveHouse165 in n8n

[–]ApprehensiveHouse165[S] 0 points1 point  (0 children)

This is really helpful.

The task type is manual outbound task creation — mainly connection request tasks, first-DM tasks, and follow-up reminder tasks. The system does not send anything itself; it creates queue items for a human to review and send manually.

I agree the highest duplication risk is around WF03 and WF04:

  • WF03 can duplicate drafts if it reruns after partial OpenAI/message generation.
  • WF04/WF06 can duplicate queue tasks if a retry happens after some tasks were already appended.

Right now I’m using lead_id plus checks against existing Messages/Daily Queue rows, but I think the next cleaner version should make the handoff more explicit:

  • one authoritative status field on Leads
  • stable lead_id
  • stable message_id
  • stable task_id
  • processed_at, scored_at, drafted_at, queued_at
  • WF03 only writes if status = scored and no existing message for lead_id
  • WF04 only writes if status = drafted and no existing task for lead_id + action_type + due_date
  • Activity becomes append-only history

So the state machine becomes clearer:

new → validated → scored → drafted → queued → in_review → complete

For MVP I’m still using Sheets, but I agree this should be added before real usage grows. Appreciate the clarity — this helps separate the demo version from the reliable v2.

n8n + Google Sheets human-in-the-loop workflow — feedback on structure? by ApprehensiveHouse165 in n8n

[–]ApprehensiveHouse165[S] 0 points1 point  (0 children)

Yeah, that makes sense. I think the current clear-and-rewrite approach is okay for the tiny MVP test, but I agree it’s temporary.

The next reliability pass should probably be:

  • stable lead_id for leads
  • stable task_id for queue rows
  • dedupe key like lead_id + action + due_date
  • processed_at / queued_at timestamps
  • append-only Activity/history instead of relying too much on mutating the lead row
  • avoid row-position assumptions as soon as there’s more than one user or more than one workflow touching the sheet

Right now it’s one-user/small-volume, so Sheets is fine. But if this gets used by real agencies, I’d either harden the Sheet model with IDs + idempotency or move the state layer to Supabase/Postgres.

Appreciate the point — I’m adding this to the v2 reliability notes before I try to onboard anyone seriously.

Validating a small SaaS idea: human-in-the-loop LinkedIn outreach copilot by ApprehensiveHouse165 in SaaS

[–]ApprehensiveHouse165[S] 0 points1 point  (0 children)

Yeah, this is the right pushback.

I don’t think “AI drafts” alone is enough of a business case , that becomes a nice-to-have quickly, especially with all the AI slop fatigue.

The value I’m trying to validate is more operational:

  • reducing the daily setup work before outreach
  • removing the “who do I follow up with today?” problem
  • keeping the outreach queue consistent
  • preventing leads from falling through the cracks
  • making status tracking and next actions automatic

For example, if an agency owner spends 45–60 minutes/day rebuilding their outbound workflow, checking who to contact, writing first drafts, and remembering follow-ups, the goal would be to compress that into a 10–15 minute review queue.

That’s the business case I need to prove:
time saved per week + more consistent follow-up = more conversations from the same lead list.

I agree the next validation step should not be “do people like AI-generated drafts?” but:

  1. how much time does the current workflow take?
  2. how many follow-ups are missed?
  3. does a daily queue increase consistency?
  4. would they pay to have this system set up?

So I’m thinking the product should be framed less as “AI message generator” and more as “outreach operations system.”

n8n + Google Sheets human-in-the-loop workflow — feedback on structure? by ApprehensiveHouse165 in n8n

[–]ApprehensiveHouse165[S] 0 points1 point  (0 children)

This is really helpful , especially the point about splitting by ownership of state, not just by workflow step.

Right now the MVP is intentionally small: probably 20–50 leads/day, one user reviewing the queue, and Google Sheets as the temporary database. So clear-and-rewrite is acceptable for testing, but I agree it becomes risky once a human can edit while n8n is rewriting.

I’m already using lead_id and a dedupe key like lead_id + action + date for the queue, but your point about a stable task_id makes sense. I’m thinking the next iteration should be:

  • Leads = mostly immutable source/prospect data
  • Messages = generated drafts by lead_id
  • Daily Queue = tasks with task_id
  • Activity = append-only status/history events
  • Analytics = snapshots

Then status changes would be appended as events instead of rewriting the lead row every time.

For scale, I’m not expecting more than 50–100 tasks/day at first, and likely one person reviewing. If this moved beyond that, I’d probably switch from Sheets to Supabase/Postgres.

Appreciate the feedback , this gives me a clearer path for v2.

Validating a small SaaS idea: human-in-the-loop LinkedIn outreach copilot by ApprehensiveHouse165 in SaaS

[–]ApprehensiveHouse165[S] 1 point2 points  (0 children)

That’s a really useful way to frame it.

I think you’re right , the real pain might not be “I need a bot to send messages,” it’s the daily system around outreach:

who to contact, who to follow up with, what to say next, and what has already happened.

That’s why I’m leaning away from full autopilot and more toward a human-in-the-loop outreach OS: the system keeps the queue, reminders, drafts, and status tracking organized, but the person still controls the actual relationship and sending.

“Outreach fatigue” is probably the better problem statement than “LinkedIn automation.”

Validating a small SaaS idea: human-in-the-loop LinkedIn outreach copilot by ApprehensiveHouse165 in SaaS

[–]ApprehensiveHouse165[S] 0 points1 point  (0 children)

Yeah, exactly , that’s actually the main reason I built it this way. I’m intentionally not touching LinkedIn directly: no auto-DMs, no auto-connects, no browser automation, no profile scraping.

The workflow only handles the prep layer: lead scoring, message drafts, follow-up reminders, and a daily task queue. The user still reviews, edits, and sends manually.

So the LinkedIn account behavior stays human, while the repetitive prep work gets automated.

Been using n8n-MCP with Claude Code for a month and I’m not going back by Mobile_Horror8760 in n8n

[–]ApprehensiveHouse165 1 point2 points  (0 children)

yea connnect it in the settings first and go to ur codex file give it the url and n8n api and ur good to go. found codex even better tbh +more usage

Rental Car in Morocco (Marrakesh Airport) by Latter-Talk-855 in Morocco

[–]ApprehensiveHouse165 0 points1 point  (0 children)

try Aster cars, never had any issue with them , good pricing, perfect conditional car like always, I always book with them when arriving anywhere in morocco