[For Hire] n8n builds — lead intake, enrichment pipelines, and voice agents that book on a live calendar

Jobs
1

Most people who ask me for automation are not asking for a workflow. They are asking why a lead that came in on Saturday sat unread until Tuesday, or why someone on the team is retyping the same data into a CRM every morning.

That is what I build in n8n.

What I ship

Lead intake and qualification. Form, phone, email or webhook into validation, then into your CRM or Sheets, with a notification to whoever actually needs to act on it. AI scoring or tagging when the message is unstructured enough to need it.

Voice agents that book. An agent that answers, qualifies the caller, reads live calendar availability, creates the event with invites, and sends confirmations to both sides. I run one in production on Vapi. It originally booked through GoHighLevel and I migrated the calendar layer to Google Calendar mid-flight, rewriting both tool contracts without changing the agent’s behaviour.

Scraping and enrichment pipelines. Mine pulls from the Google Places API across roughly 450 cities, crawls each company site for contact details, dedupes across runs, and pushes into a sending platform on a daily cron with status written back. About 45,000 businesses addressable.

Integrations against APIs with no n8n node. I use a bridge workflow: a webhook takes a method, path and body and passes them to an HTTP Request node holding the stored credential, which gives full API surface on anything. Running for Smartlead, Stripe, the GA4 Data API and Microsoft Clarity. Stripe needed a code node to flatten nested JSON into form encoding, since their API rejects JSON bodies on most endpoints.

How I work

Fixed price by default, 50% up front and 50% on acceptance. Everything runs on your n8n, self-hosted or cloud, so the workflows are yours if we stop working together. Every build ships with a handover doc covering what each node does and how to extend it. Credentials stay in the credential store and I am happy to build against sandbox keys and hand off documented JSON if you would rather keep production access on your side.

Rates

Scope Price
One production workflow, error handling, handover doc, 14 days of fixes $400
3 to 5 connected workflows, shared error handling, 30 days of fixes $1,100
Voice agent, web or phone, with live calendar booking and confirmations $1,800
Larger systems, staging and prod, architecture doc, monitoring from $2,500
Care plan: monitoring, fixes, small changes, cancel any time $400/mo

If scope is not clear yet, $55/hr with a capped 2 hour discovery block, credited against the build if you go ahead. You send me the current process, I send back a flow sketch and the questions that actually change the price.

Proof, since I am new to this board

There is a live voice agent on my site you can talk to right now rather than take my word for it: https://tryastracore.com. Portfolio of builds at Jeff Bowen — Automation Builder.

Two things I got wrong and now check for

An enrichment workflow of mine fetched four pages per company site and the extraction step only read two of them. Every execution was green. Nothing errored. It just quietly returned half the results it should have for weeks. I now assert on output counts rather than trusting a successful run.

The Vapi web SDK resolves start() successfully when the browser has blocked the microphone. No error, no exception, no call. The widget looks like it is working and no call ever begins. Anything that depends on a browser permission needs a timeout that checks whether the thing actually started.

Based in Vancouver, so I overlap North America all day and European mornings. Calls are fine, and you get a recorded walkthrough at handover either way.

Happy to sketch the flow for your situation before any money changes hands. Reply here or DM.

2

Your first line is the whole problem in one sentence. A lead that never arrives does not complain, so nobody finds it until someone happens to look.

Mine was 27 branches skipped daily, every run green, and weeks before I noticed.

When you hand a client an intake pipeline, what do you give them so they can check it is still working without calling you?

1 « J'aime »
3

Great question and exactly right! A workflow cannot report its own silence. Whatever does the checking has to sit outside the run.

Three things, roughly in order of how much they have saved me.

A scheduled watchdog as its own workflow, querying outcomes instead of executions. Rows written in the last 24 hours, broken down by stage, compared against a floor. Items in versus items out per stage is what would have caught your 27, because a skipped branch shows up as a gap between two stages and never as an error anywhere.

A daily digest so the client knows what a normal day looks like. 142 in, 51 enriched, 3 failed fetches. The digest arriving is itself the health check. If it stops turning up they know to ping me before they know why, which covers the case where the alerting broke along with everything else.

A stats endpoint they can hit whenever they want. Mine is a webhook returning current counts by segment plus the timestamp of the last successful run. Freshness matters as much as volume, since a pipeline stuck on yesterday’s numbers looks healthy on every metric except the clock.

The part I still find awkward is picking the floor. Set it tight and you get paged for a slow Tuesday, set it loose and it will happily sleep through half the pipeline going missing. I have ended up comparing against a rolling median of the last week rather than a fixed number, which handles seasonality but takes a week of data before it is worth anything.

4

The digest is the best idea anyone has given me on this, and it solves something I could not. Everything else in these threads is absence detection, and absence cannot tell you the difference between nothing happened and the detector died. A digest that has to arrive is the only positive signal I have seen anyone describe. If it stops turning up, the silence is the alert.

Items in versus items out per stage is the thing I do not have and should. My engine records what each step received and what it returned, so the data is there, but they are json blobs rather than counts, so I cannot query the gap without parsing every row. That is the next thing to build, and smaller than I thought before you put it that way.

On the floor: someone in another thread landed on the same rolling median as you, and named the same cost, a week of data before it is worth anything. What neither of you has is run one, which is when a condition is most likely to be wrong. My 27 were dead from the first run and no median would ever have flagged them. His answer was to ask the person building the workflow what a normal run should produce and store that. It is manual and ugly and it covers exactly the window your median cannot.

So probably both: a declared expectation on day one, a rolling median once there is a week of it.

1 « J'aime »