How to Build an Open-Weight AI Client Onboarding Agent for Support Teams

A customer support AI agent can answer onboarding questions, verify account data, and book implementation calls in under five minutes. In 2026, an open-weight AI enablement build in Southeast Asia can run for about $80 to $250 per month. It can sit on a small GPU VPS or route through a low-cost inference API. The system takes a new client event from the CRM. It reads the client context, drafts a precise reply, and escalates only edge cases to a human. It gives a support team coverage outside office hours without adding headcount. The build is a controlled pipeline, not a public chatbot. It uses a private knowledge base, fixed response rules, and a human review queue. This article shows the architecture, the build steps, the tools, and the failure modes. It is written for a B2B service founder who wants a support asset that runs on company infrastructure and stays under company control.

The problem

New clients send questions the moment a contract is signed. They ask for login details, account requirements, document formats, and next steps. A human support team answers during office hours only. The client waits. The delay creates anxiety. The client sends another message. The inbox fills with duplicate questions. The support team spends time on repeat work. The founder absorbs the overflow.

The root cause is not poor effort. The root cause is a manual intake path. Every onboarding question enters a human queue. Every answer depends on one person. The system has no coverage at night, on weekends, or during travel. The business pays for that gap in stalled starts, repeated emails, and founder time.

The cost is visible in the calendar. Kickoff calls slip because documents are missing. The sales team promises a fast start. The operations team spends days chasing files. The client reads silence as poor delivery. The team reads silence as a busy client. Both are wrong. The system has no follow-up engine.

A support agent fixes this when it is built as a controlled pipeline. It reads the client event. It retrieves the correct policy. It drafts a reply in the client language. It books the next call. It escalates only the cases that need a human. The rest runs without waiting.

Who this is for

This build is for a B2B service founder in Southeast Asia with recurring client onboarding. The company may run an agency, a professional service, or a support-heavy product. Revenue sits between $500k and $5M. The team already uses a CRM and a shared inbox. The founder wants coverage without adding another night shift.

The build also fits a company that wants to keep data in-house. The model can run on private infrastructure. The knowledge base stays in a controlled repository. The system does not train on public chats. It executes a private procedure.

The founder should own the policy repository. The support team should own the review queue. The agent should own the first response.

Is this the right fit

Fit: the business has repeat onboarding questions, a defined next step, and a knowledge base that can be written down. Fit: client messages arrive through email, WhatsApp, or a web form. Fit: a human can review edge cases in a queue.

Non-fit: the business has no documented onboarding policy. Non-fit: every client request is unique and requires partner judgment from the first message. Non-fit: there is no CRM or no place to store client context. In those cases, document the process first. The agent cannot fix an undefined process. It can only execute a defined one.

System architecture

The system has five parts. The trigger is a client event. The data store holds client context and policy. The orchestrator controls the sequence. The model drafts the reply. The channels deliver the message and book the call.

The architecture separates retrieval from generation. The retrieval step selects the policy section. The generation step writes the message. The review step catches uncertainty. This separation makes the system auditable. A reviewer can trace a message to a policy section and a client record.

The same pattern can run in Singapore, Vietnam, or the wider region. The language layer changes. The control pattern stays the same.

The system also produces logs. Every message stores the trigger, the retrieved section, the model version, and the human decision. The logs make calibration possible. A founder can review ten messages per week and find weak policy sections. The fix is usually a policy edit, not a model change. This keeps maintenance cheap.

Inputs:

A new client event from the CRM webhook.
Client profile data, contract type, and onboarding checklist.
Incoming client messages from email, WhatsApp, or a web form.

Outputs:

A first response sent within five minutes.
A drafted answer grounded in the knowledge base.
A booked implementation call on the calendar.
A human review task for uncertain cases.

Flow:

The CRM webhook sends a client-created event to the orchestrator.
The orchestrator writes the event to PostgreSQL.
The orchestrator retrieves the onboarding policy for that contract type.
The model drafts a welcome message and a document request.
The message is sent through email or WhatsApp.
Incoming replies are classified by intent.
Safe intents receive an automatic answer.
Uncertain intents create a Slack review task.
A positive reply creates a calendar link and books the call.

Build steps

Client event capture

Capture the client-created event from the CRM webhook and send it to n8n. The webhook must include client name, contract type, and start date. The orchestrator should reject missing fields and write an error log. This step creates the trigger for every later action. Test the webhook with a fake client before launch. Log the payload for 14 days.

Context storage

Store the client record in PostgreSQL with contract type, owner, and onboarding stage. Use one table for clients and one table for message events. The database gives the agent a memory. It also gives the human reviewer a full history. Add timestamps for every state change. Use the timestamps to measure latency.

Knowledge grounding

Load the onboarding policy from a Markdown knowledge base hosted in a private Git repository. Split the policy into sections such as access, documents, billing, and timeline. The model reads only the section that matches the intent. This keeps answers narrow and factual. Keep each policy file under 500 words. Use clear headings. The model retrieves better from short sections.

Model serving

Route the client context to an open-weight model served by Ollama on a GPU VPS. Use a small model for classification and a larger model for drafting. Keep temperature low. Lock the prompt fields to client name, policy section, and required next step. Pin the model version. Record the prompt template in the repository. Run ten test cases after each change.

First touch

Generate a welcome message and a document checklist with fixed prompt fields. Send the first touch through the WhatsApp Business API or SMTP email within five minutes. The message must state the next step and the documents required. It must not promise dates that are not in the policy. Store the sent message in the database. Attach the policy section used. This creates an audit trail.

Reply handling

Classify each incoming reply with an intent model and store the intent in PostgreSQL. Use intents such as document help, access help, scheduling, and escalation. Safe intents receive a drafted answer. Unknown intents go to a human queue. Store confidence scores. Review low scores weekly. Update intents when new patterns appear.

Risk control

Create a Slack review task when confidence is below 0.8 or when the client asks for pricing changes. The task includes the client message, the draft answer, and the policy section. A human approves, edits, or rejects the draft. Set a service level for review. A human should clear the queue twice per day.

Call booking

Book the implementation call with a Calendly webhook when the client replies with a positive intent. The orchestrator checks calendar availability and writes the call time to PostgreSQL. It then sends a confirmation message with the call link and the agenda. Send a reminder one day before the call. Include the document status.

Stall recovery

Run a daily reconcile job in n8n that checks for stalled clients. If a client has no reply for two days, the system sends one nudge. If a client remains stalled for five days, the system creates a founder review task. This prevents silent drop-offs. Send the weekly summary to the founder. Include stalled clients, review queue age, and call bookings.

Tools and costs

What does the stack cost?

Use this stack as a baseline. Costs are estimates for a small B2B team in 2026.

CRM webhook: native feature, $0 per month.
n8n self-hosted: open source, $0 license, runs on the VPS.
PostgreSQL: open source, $0 license, runs on the VPS.
GPU VPS for Ollama: about $80 to $250 per month, estimate based on region and GPU memory.
Open-weight model: $0 license, plus inference compute cost.
WhatsApp Business API: per conversation, varies by country.
SMTP email: $0 to $20 per month for a small sending plan.
Slack: free tier for review tasks, or standard seat pricing.
Calendly: free or paid plan, $0 to $20 per month.

The first build can run on one GPU VPS. A production build may separate the database and the inference server. The main cost is the GPU instance. The main saving is human time on repeat questions. Do not buy a large cluster before the first 100 client events. Start with one node. Measure latency and error rate. Add capacity only when the queue grows.

The stack can be replaced by equivalents. The database can be MySQL. The orchestrator can be another workflow tool. The model server can be vLLM. Keep the same contract: trigger, context, retrieval, generation, review, delivery.

Track cost per sequence weekly. Store token counts in PostgreSQL. Set a budget alert at $3 per sequence.

Failure modes

What breaks first?

The model invents policy details. Fix: lock the prompt to retrieved policy sections. Add a validation step that checks the draft for banned claims such as custom pricing or delivery dates.
The CRM webhook misses events. Fix: add a daily reconcile job in n8n. Compare active clients in the CRM with client rows in PostgreSQL. Create missing events with a backfill flag.
The client asks for an edge case. Fix: route low-confidence intents to Slack. Do not force an answer. The human review queue is part of the system, not a failure of the system.
WhatsApp templates get rejected. Fix: submit templates before launch. Keep the first message transactional. Avoid sales language in the onboarding window.
The knowledge base drifts from reality. Fix: assign one owner to the policy repository. Require a pull request for every policy change. Rebuild the retrieval index after each merge.
The model latency spikes. Fix: set a timeout and fall back to a template message. The client still gets a fast first response. The queue flags the draft for later review.
The database fills with stale records. Fix: archive closed clients after 90 days. Keep the active table small. The orchestrator runs faster and the reports stay clear.

What good looks like

The installed system has measurable properties. The first response goes out within five minutes of the client event. The answer cites the correct policy section. The client receives one clear next step. The support team sees only edge cases. The founder reviews a weekly summary instead of an inbox.

The founder can inspect the system with one report. The report shows response time, review rate, stalled clients, and cost per sequence. The report is the control panel. It replaces inbox anxiety with a weekly operating review.

The team can copy the build into a second department after the first process is stable. The same pattern works for support, onboarding, and client success.

The operating rhythm is simple. The system handles routine work. The team handles judgment work. The founder handles direction.

Operating state:

First response time: under five minutes.
Coverage: 24 hours per day, seven days per week.
Human review rate: below 15 percent of messages after calibration.
Cost per onboarding sequence: about $1 to $3, estimate.
Stalled clients: flagged after two days, escalated after five days.

The system is an asset. It runs on company infrastructure. It uses company policy. It hands control back to the founder. The support path no longer depends on one person being awake.