Answer every inbound lead in under a minute

Speed of first reply predicts conversion more reliably than almost anything else you can control, and most small businesses answer forms in hours or days. This is the highest return per minute of setup in the whole set, so it goes first.

The finished thing: someone fills in your form, and within a minute they have a real answer to the question they actually asked, plus one qualifying question back. You get a one-line summary with an urgency read.

Steps

Hire the role

Install support-triage from the marketplace and put it in your customer-support department. Paste its AGNT- code into the chat box.

Rename it to something a human would say out loud. "Front Desk" beats "Support Triage Agent v1" when you are reading a digest at speed.

Connect the mailbox it will reply from

Authorise a role mailbox, not your personal one. hello@ or sales@. Replies will come from this address, and the person who answers your form will reply to it, so it needs to be a mailbox somebody actually reads.

Teach it your voice before you teach it the form

Paste three real enquiries you have answered well, along with your actual replies. Then ask it to answer a fourth one you already know the answer to, and compare.

Put the voice rules in the persona, because they are permanent:

Write like a person who is busy and helpful. Four sentences, no greeting boilerplate, no restating their question back to them. Answer the thing they actually asked first, then ask the one question that qualifies them. Never use marketing language about ourselves.

The two tells

Two habits make an otherwise good reply read as machine-written: em dashes, and opening by restating the question. Ban both explicitly in the persona. An em dash in a subject line has a second problem, which is that it can arrive as mojibake in some mail clients.

Mint the webhook key

In the console, open Webhooks and create an endpoint. Bind it to this employee. If you want the payload to fire one specific workflow rather than a general run, bind the workflow name too.

You get back an endpoint id and a key beginning nbwh_. The key is the credential; the id is just a stable, shareable URL segment. Store the key the way you would store a payment secret.

Test the endpoint before touching your website

Send a realistic payload by hand first:

curl -X POST https://api.neboai.com/api/v1/hooks/$ENDPOINT_ID \ -H "Authorization: Bearer nbwh_..." \ -H "Content-Type: application/json" \ -d '{ "name": "Dana Whitfield", "email": "dana@acme.com", "company": "Acme Joinery", "message": "Do you handle commercial fit-outs? We have 40 units." }'

A successful call returns:

{"delivered": true}

Then open the employee and watch the run happen. Known responses:

Response	Meaning
`202` delivered	Working.
`404` not found	The id in the URL does not match the key's endpoint.
`401`	Key missing, malformed, or revoked.
`413`	Payload over 256 KB. Send fields, not attachments.
`429`	Over 60 requests per minute on this endpoint.

Point your form at it

Post from your server, never from the browser. The key must not appear in client side code, where anyone can read it and fire your employee at will.

// server-side form handler await fetch(`https://api.neboai.com/api/v1/hooks/${process.env.NEBO_HOOK_ID}`, { method: 'POST', headers: { 'Authorization': `Bearer ${process.env.NEBO_HOOK_KEY}`, 'Content-Type': 'application/json' }, body: JSON.stringify({ name: form.name, email: form.email, company: form.company, message: form.message, source: 'pricing-page' }) });

Include a source field naming the page. It costs nothing and it is the difference between "we got 40 leads" and "the pricing page outperforms the home page four to one."

Why this is safe to expose to the public

The delivered envelope is stamped as arriving over webhook, and the origin clamp in the tool policy governs what that run may do. A payload from a public form cannot talk its way into a shell, whatever it contains. That is enforcement, not instruction, so it holds even against a message written specifically to manipulate the employee.

Make it always answer

The single most common failure of this recipe is an employee deciding a real lead is not worth a reply. It reads a terse two-line enquiry, judges it unserious, and silently does nothing. Prose guidance is not enough; state it as a hard rule in the persona:

HARD RULE: every enquiry gets a reply. You do not decide whether a lead is legitimate, serious, or worth answering. A short, useful answer always beats silence. If the enquiry is unclear, reply asking what they need.

Set the gate

Stays human

This is the rare recipe where the reply itself should be unattended, because a reply that waits for approval is just a slow reply. Buy that safety back by narrowing the role instead: it should have no ability to quote a price, commit to a date, or promise a scope. Put those in the persona as refusals, and set anything money-shaped to blocked in Controls rather than approval.

Verify

Submit your own form from a phone, on mobile data, and time the reply
Read that reply as though you were the customer, not the owner
Submit a deliberately vague one line enquiry and confirm it still answers
Submit something abusive and confirm it stays professional and flags rather than engages
Check the reply threads correctly if the person answers back

When it goes wrong

The run completes but no email is sent

The run narrated sending instead of sending. Promote the job from a conversation to a declared workflow where the send step must call the mail tool — then a missing call fails the run rather than passing silently.

Replies do not thread, so the customer sees a new conversation each time

Threading breaks when the reply invents its own message identifier or rewrites the subject. The reply must carry the original subject unchanged and reference the original message id verbatim, rather than one reconstructed from an API response. Test by replying to your own test lead twice.

The subject line arrives as garbled characters

An em dash, curly quote, or accented character in a subject header that was not encoded. Ban em dashes in the persona, which fixes the common case, and confirm your mail plugin encodes non-ASCII headers.

It answers, but sounds like a robot

Give it more examples rather than more instructions. Three real threads you wrote yourself outperform a paragraph describing your tone. Voice is imitated far better than it is described.

Nothing arrives and curl returns 404

The endpoint id in the URL must match the endpoint the key is bound to. A mismatch is deliberately reported as not-found rather than unauthorised, so it does not confirm whether a given id exists.

After a week

Read every reply it sent, in one sitting. You are looking for the enquiry it handled badly, not the forty it handled fine. Whatever you find, fix it in the persona, because by definition it will happen again.

Then consider adding sdr behind it: the front desk answers and qualifies, emits when a lead looks real, and the SDR picks up the follow-up sequence.