How We Built a 67-Node AI Inside Sales Agent That Books Appointments While Contractors Sleep

Yashwardhan — Sat, 08 Aug 2026 20:21:26 +0000

Home service businesses — garage door repair, pest control, mobile detailing, moving companies — live and die by response speed. Industry data has shown for years that a lead contacted within 5 minutes converts dramatically better than one contacted an hour later. Most small contractors simply can't hit that window. They're on a roof, under a sink, or driving between jobs.

So we built an AI Inside Sales Agent (ISA) to close that gap. Here's how it works under the hood.

The problem with "just add a chatbot"

Most lead-response tools stop at "send an auto-reply." That's not enough. A real ISA needs to:

Qualify the lead (budget, timeline, service type, location)
Handle objections in natural language
Check real calendar availability
Book the appointment without double-booking
Hand off cleanly to a human when the conversation goes off-script
Log everything somewhere the business owner can actually see That's a workflow problem, not a prompt problem.

The architecture

We built this as a 67-node workflow in n8n, orchestrated around:

GPT-4o-mini for conversation and intent classification — cheap enough to run on every inbound message without blowing up margins
Twilio for SMS-based conversation (most homeowners won't download an app or use a web chat widget for a garage door quote)
Google Calendar API for real-time availability checks and booking
Google Sheets as a lightweight CRM backbone — searchable, exportable, and something a non-technical business owner can actually open and understand
Slack for internal handoff alerts when a lead needs a human The key design decision was keeping the qualification logic outside the LLM prompt as much as possible — structured branching in n8n, with GPT-4o-mini handling only the parts that genuinely need natural language understanding (interpreting free-text replies, detecting objections, tone-matching). This keeps costs predictable and behavior debuggable, instead of relying on one giant system prompt to carry the entire conversation.

Why this matters for contractors specifically

Home service leads are unforgiving. A homeowner with a broken garage door is usually messaging 3-4 companies at once. Whoever responds first — and sounds competent doing it — tends to win the job. An ISA that replies in under a minute, asks the right qualifying questions, and books directly onto the calendar removes the single biggest leak in a contractor's funnel: the lag between "lead comes in" and "someone picks up the phone."

Lessons from building this

Don't let the LLM own scheduling logic. Calendar conflicts are a deterministic problem — hand them to code, not a language model.
Log every message, even failed ones. The failure cases taught us more about real customer language than any amount of prompt engineering.
Build the human handoff path first, not last. The fastest way to lose a contractor's trust is an AI that gets stuck in a loop with a live customer.
Small models are enough for 90% of turns. GPT-4o-mini handled almost everything; we reserved anything heavier for edge cases. ### Wrapping up

If you're building similar lead-response or scheduling automation — whether with n8n, LangChain, or a custom stack — I'd genuinely like to compare notes in the comments.

We do this kind of build for home service contractors and real estate agents at Xmel Automations — feel free to check it out if you're working on something similar.

Why GoFr Deserves a Spot on Every Go Developer's Radar

Yashwardhan — Tue, 14 Jul 2026 11:35:18 +0000

Building microservices in Go is powerful, but it's rarely simple. You end up wiring together a router, a logger, a metrics exporter, a tracer, database drivers, a Pub/Sub client, and health checks — before you've written a single line of actual business logic. GoFr (gofr-dev/gofr), an open-source, opinionated Go framework, exists to remove exactly that friction. Backed by 21K+ GitHub stars, 1.8K forks, and a genuinely active release cadence (112 releases, with v1.57.0 shipped in June 2026), it has quietly become one of the more compelling "batteries-included" frameworks in the Go ecosystem — and it's even listed in the CNCF Landscape, which says a lot about its production-grade ambitions.
1. It gets you from zero to running service in seconds
GoFr's core promise is simplicity. A working HTTP serv
ice is genuinely this short:
_package main

import "gofr.dev/pkg/gofr"

func main() {
app := gofr.New()
app.GET("/greet", func(ctx gofr.Context) (any, error) {
return "Hello World!", nil
})
app.Run()
}
_
No boilerplate router setup, no manual middleware chaining, no separate config loader. That low ceremony is a real advantage for solo developers and small teams who want to ship rather than assemble infrastructure.
**2. Observability isn't bolted on — it's built in*
This is arguably GoFr's biggest differentiator. Logs, traces, and metrics come out of the box, with OpenTelemetry support baked into the framework rather than left as an exercise for the developer. In most Go stacks, observability is the thing teams postpone until "later" (which often means "after the incident"). GoFr flips that by making it a default, not an add-on.
3. It speaks Kubernetes and microservices fluently
GoFr is explicitly designed with Kubernetes deployment and microservice patterns as first-class citizens. It includes:
Health checks for all connected datasources — critical for readiness/liveness probes
Database migrations handled natively
Circuit-breaker-enabled HTTP service calls, so one flaky downstream service doesn't cascade into an outage
Pub/Sub support for event-driven architectures
gRPC support alongside REST, so you're not locked into one communication style
For anyone deploying to a cloud-native environment, this means fewer third-party libraries to evaluate, integrate, and keep version-compatible.
4. Thoughtful developer-experience touches
Beyond the core architecture, GoFr includes details that show real production experience baked into the design:
Remote log-level changes without restarting the service — genuinely useful for debugging live systems
Auto-generated Swagger documentation
Abstracted file systems for consistent file handling across environments
WebSocket support for real-time features
Cron job scheduling built into the framework itself
These aren't flashy features, but they're the kind of thing that saves hours of "let me find a library for that" during real project work.
5. It's genuinely community-driven and well-maintained
With nearly 5,000 commits, 79 open issues being actively triaged, and 45 open pull requests, GoFr shows the signs of a healthy, living project rather than an abandoned side experiment. It's Apache-2.0 licensed, has a clear CONTRIBUTING.md, a code of conduct, and even incentivizes contributions with merchandise — small things that reflect a maintainer team invested in community growth, not just code.
Who benefits most from GoFr
Startups and solo builders who want production-grade defaults (observability, health checks, auth middleware) without assembling them manually
Teams standardizing on Kubernetes who want a framework that treats cloud-native deployment as a default, not an afterthought
Go developers tired of "framework sprawl" — juggling five different libraries for logging, tracing, migrations, and Pub/Sub
The bottom line
GoFr isn't trying to be a minimal, unopinionated toolkit like the standard library — it's making a deliberate bet: that most microservice teams don't want to make a hundred small infrastructure decisions before writing business logic. By baking in observability, database support, auth, gRPC, and Kubernetes-friendly health checks, it lets developers focus on the part of the job that actually differentiates their product. For teams building microservices in Go, it's well worth a serious look.
Repo: github.com/gofr-dev/gofr · Docs: gofr.dev/docs

DEV Community: Yashwardhan

How We Built a 67-Node AI Inside Sales Agent That Books Appointments While Contractors Sleep

The problem with "just add a chatbot"

The architecture

Why this matters for contractors specifically

Lessons from building this

Why GoFr Deserves a Spot on Every Go Developer's Radar