# API Source: https://docs.autonudge.dev/api/overview Drive your workspace from your own code, or from an AI assistant Every Nudge workspace has a REST API. Anything an admin can do in the app, a key can do over HTTPS: read and write contacts, import a book of leads, create and toggle triggers, manage templates, send WhatsApp messages. What it deliberately cannot do is change your configuration, your schema, or the app itself. The common uses: pushing leads in from a website or another system, syncing contact data with a tool Nudge has no native integration for, and pointing an AI assistant at your workspace so you can ask it to do the boring parts. ## Getting a key Go to **Settings → API** and click **New key**. Name it after whatever will use it, for example "website" or "Claude". The full key is shown once, at creation. Copy it then. Afterwards the table shows only the last four characters, and there is no way to reveal it again. Lost a key? Revoke it and make a new one. Revoking cuts access immediately. Keys are never deleted, so the record of what existed and when it was last used survives. ## Making a request The same screen shows your workspace's **base URL**. Every key goes in an `Authorization` header: ```bash theme={null} curl "$BASE/contacts?limit=20" \ -H "Authorization: Bearer nk_live_..." ``` A quick connectivity check: ```bash theme={null} curl "$BASE/me" -H "Authorization: Bearer nk_live_..." ``` Responses are JSON. Errors come back as `{"error": "..."}` with a 400, 401 or 404, and the message says what was actually wrong rather than "bad request". ## What you can call ### Contacts | Request | Does | | ------------------------------ | ----------------------------------------------------------------------------------------------------- | | `GET /contacts` | List contacts. Supports `limit`, `cursor`, `possibility` and `search`. | | `GET /contacts/:id` | One contact with all its fields. | | `POST /contacts` | Create one contact. Deduplicates by phone and email, and fires triggers like a form submission would. | | `POST /contacts` with an array | Bulk import. Up to 100 per call, deduplicated the same way, but triggers stay quiet. | | `PATCH /contacts/:id` | Update fields, state or owner. | | `DELETE /contacts/:id` | Remove a contact and its history. | | `GET /contacts/:id/messages` | That contact's messages and calls. | The bulk import deliberately does not fire triggers. Importing four thousand old leads should not message four thousand people. When you do want an import enrolled in a trigger, enable that trigger afterwards with **Also send to contacts that matched recently**, using a window that covers the import. ### Triggers | Request | Does | | ---------------------- | --------------------------------------------------- | | `GET /triggers` | List triggers with their state and channels. | | `POST /triggers` | Create or update a trigger, matched by name. | | `PATCH /triggers/:id` | `{"enabled": true}` or `false`. | | `DELETE /triggers/:id` | Delete a trigger and cancel anything it had queued. | Because `POST /triggers` matches on name, running the same request twice updates rather than duplicates. That makes it safe to keep your triggers in version control and replay them. ### Templates and messages `GET`, `POST`, `PATCH` and `DELETE` on `/templates` manage the library. `POST /messages` sends WhatsApp to one contact or up to 500: ```bash theme={null} curl -X POST "$BASE/messages" \ -H "Authorization: Bearer nk_live_..." \ -H "Content-Type: application/json" \ -d '{"to":"nudge:d5f38225-...","body":"Hi [name], following up on your quote."}' ``` Variables resolve per recipient, exactly like a template send. API sends join the same paced queue as everything else. A script cannot make your reps' numbers send faster than the safety settings allow, which is the point. ## Things worth knowing * **One key, full access.** There are no per-key permissions yet. Treat a key like an admin password and give each integration its own, so you can revoke one without disturbing the others. * **Creating contacts is standalone-mode only.** If your workspace syncs with HubSpot, contacts come from HubSpot and creating them through the API is refused. Reading, updating and sending work in both modes. See [Standalone vs HubSpot](/crm/native-mode). * **WhatsApp only, for now.** Email sending through the API is not built yet. * **Contact ids** are stable. In HubSpot mode they are the HubSpot contact id; standalone they look like `nudge:` followed by a uuid. ## Watching what happens **Settings → API** lists the last 100 requests: when, which key, what was called, the status, and the error for anything that failed. It keeps 30 days. When an integration misbehaves, look here first. It usually tells you the answer without needing anyone to reproduce anything. ## Using it with an AI assistant You do not need a REST key for this. **Settings → API** opens with an **AI connectors** card: click **Connect Claude** or **Connect ChatGPT**, and you get a connector URL and a one-time key to paste into that app's own connector settings. From then on you can work the CRM by asking — "import these leads", "which contacts replied this week and got no follow-up", "turn off the reactivation trigger". A connector key is not the same thing as a REST key, and the difference matters: * A **REST key** says *a program may do admin things*. It belongs to the workspace. * A **connector key** says *this person's assistant acts as them*. It belongs to whoever created it, every action it takes lands in the activity feed under their name, and reversible ones can be undone. So give each person their own connector rather than sharing one, and revoke it the same way you revoke any key. ### Adding contacts by asking Paste a list, forward a spreadsheet, or describe someone you just got off the phone with, and the assistant can put them in — up to 100 at a time. Four rules govern it: * **Nothing gets sent.** New contacts arrive as data. No workflow runs and no message goes out, however the contact is staged. Putting a batch through a workflow is a separate decision: enable the workflow in backfill mode. * **Running the same list twice is safe.** Contacts are matched on phone number, then on email address, so someone already on file is updated instead of duplicated. A contact with neither is refused and named back to you — there would be no way to recognise them next time. * **The stage applies to new contacts only.** Someone already on file keeps the stage they have — the assistant will tell you which ones it left alone, and you can ask it to move them. * **Standalone workspaces only.** If your contacts sync from HubSpot, they are created in HubSpot and arrive here on the next sync. Ask it to undo and it deletes what it created, as long as nothing has happened to those contacts since — one that has picked up a message, a note or a deal is kept, and the assistant says which. ### Bringing your history in An assistant can also record what has already happened: calls you had, emails from a thread, WhatsApp exchanges, notes, follow-up tasks and deals. This is how a workspace that has been running somewhere else arrives with its past intact rather than starting empty — and it is how you log a call the moment you put the phone down. **Nothing is sent.** These are records of things that already occurred, written in a finished state that the sending machinery cannot see, so there is no way for a logged message to go out to anybody. Two consequences worth knowing: * **A logged reply behaves like a real one.** It puts the conversation in your Inbox and marks the contact as having replied — which also pauses any chase automation for that contact, exactly as a genuine reply would. That is usually what you want; it is worth knowing before you import a year of history into a workspace with live automations. * **Messages that went out as one campaign can say so.** Tell the assistant they were a campaign and they are grouped on the Bulk Action tab as a single send, with per-recipient results, instead of scattered across timelines. Deals follow the pipeline you already have: one open deal per contact, so recording a deal on someone who already has one updates it rather than putting a second on the board, and a stage the board has no column for is reported back rather than silently dropped. # Bulk Action Source: https://docs.autonudge.dev/automation/bulk-send One message, or one data change, across a whole segment Bulk Action does something to a segment in one go: a promo, a reactivation, an announcement, or a straight data fix across hundreds of contacts. It uses the same templates, variables and safety rails as everything else. The bulk send composer: define the segment, then compose per channel ## Where things are The tab opens on the record: every bulk action you have run, newest first. **New bulk action** starts a new one, and the back arrow returns you to the list. Anything you start is kept in your browser until you apply it or save it as a draft, so switching tabs or reloading the page will not lose it. An unfinished one waits at the top of the list with **Continue** and **Discard**. ## Define the segment Pick owners and add conditions, the same condition builder triggers use. **Find contacts** counts the matches and loads them into the recipient list below, where you tick who receives it. You can also start from the contacts table: select rows there and act on just those. ## Compose Add a WhatsApp, email or call step and pick a template or write a one-off. Variables resolve per recipient, so a bulk message still opens with `[firstname]`. Choose Send now or Schedule, then send. Park it as a draft in the Drafts list if you are not ready. A send with no title takes its name from the message you picked. ## Property actions A campaign does not have to send anything. Alongside the message steps you can set contact properties: possibility, owner, or any field in your registry. A run with only property actions and no messages is a pure data change, which is the fastest way to fix a few hundred contacts that were tagged wrong. Property actions are available on standalone workspaces. On HubSpot-synced workspaces they are switched off, because a burst of writes that large would fight with the ongoing HubSpot sync. ## The trigger dry-run Changing a property can arm a trigger, which means a data fix can quietly turn into a thousand messages. So before a run that writes properties, Nudge simulates the result and checks it against your enabled triggers. If nothing would fire, it just runs. If something would, you get a dialog naming each trigger and how many contacts it would newly hit, and you decide. This is the safety net between "I relabelled some contacts" and "why did everyone get texted". ## What keeps it safe A bulk send goes out from a **Cloud API number**, and the picker offers nothing else. Volume down a personal number is the fastest way to get that number blocked, and the Cloud API is the lane built to carry it. The list narrows further to the numbers whose account has an approved version of the message you picked, since anything else Meta refuses. If it comes up empty, the message has no approval yet — submit it from the template editor first. Bulk messages join the same per-number queue as everything else. If the template has language tabs, a **Send in** picker appears on the action. The default sends each contact the tab matching their owner's language, and skips anyone whose owner speaks a language the template doesn't cover, or who has no owner at all. Pick one language to send that tab to everyone in the segment instead. The same picker exists on trigger actions. A reply does not cancel a bulk send: you chose the segment, so everyone in it gets the message even if they wrote in recently. That is different from triggers, which stand down for a contact who replied. If a campaign has several steps and you want later steps to stop for people who answered, that is a trigger's job. ## Tracking The list shows each campaign with live counts and either its state (Scheduled, Sending, Paused, Cancelled) or, once it has finished, when it went out. Click one to open it. **Delete** on a finished send removes it from this list; the messages it sent stay on each contact's timeline. Inside you get the segment it ran against, the message it sent, and every recipient with what actually happened to them: | Result | Means | | --------- | ------------------------------------------------------------------------------------------ | | Replied | They wrote back | | Read | They opened the email | | Answered | They picked up, and the call went as intended | | No answer | The call did not connect — voicemail, busy, or nobody home | | Sent | It went out. WhatsApp has no read receipt, so this is as much as we can honestly say there | | Applied | No message — this contact was part of a property-only run | | Failed | It did not go out. Hover for the reason | You can pause a running campaign, resume it, cancel it outright, or rename it from its own page. Loading a past campaign back into the composer lets you re-run it against a fresh segment. Every sent message also appears on its contact's timeline like any other touch. An open campaign has its own link, so you can send one to a colleague. # Templates Source: https://docs.autonudge.dev/automation/templates Message content, written once, personalized per lead Templates own the message content in Nudge. Triggers and bulk sends reference a template; the template decides the words, the language and the attachment. The template library with channel and language columns ## Variables Write `[firstname]` and every send resolves it per lead. Built in: `[name]`, `[firstname]`, `[lastname]`, `[fullname]`, `[salutation]` and `[phone]` for the contact, plus `[owner]` and `[owner_firstname]` for the assigned rep. Beyond those, **every field in your registry is a variable**: open the variable picker in the editor and each field is listed under its label with the token to type, so `[bill]` or `[rooftype]` resolves the moment the field exists. List fields can map raw values to display text, so a stored `gable_roof` renders as "Gable roof" in the message. Adjacent tokens space themselves correctly and empty values collapse cleanly, so a missing last name never leaves a double space. ### When a contact's value is empty A variable with nothing behind it disappears from the sentence. Fine for a missing last name; not fine for `Courses in [course_type]`, which becomes `Courses in`. Underneath the message body, **Variable defaults** lists every variable you've used with a box for its fallback. Fill in `education` for `[course_type]` and contacts without one still read a complete sentence. Leave it blank and the variable keeps disappearing, exactly as before. The boxes belong to the message, not to the field, so each language tab has its own — the Turkish tab falls back to Turkish wording and the English tab to English. If you've set the same fallback elsewhere, the box suggests it as you type. On WhatsApp **business templates** (the approved kind used to start conversations), an empty variable doesn't just drop a word — WhatsApp refuses the message entirely. So a variable from your field registry needs a fallback before you can submit one for approval, and the editor names the ones still missing. Built-in variables are exempt: `[firstname]` and the rest come from the contact's own name, so they can't turn up empty. Filling a fallback in never sends the template back for review; the approved wording is unchanged. Workspace setup shows the fallbacks a variable has, and which messages set them, so you can check without opening each one. They're only editable in the message editor — one place decides, one place lists. ## Languages A template can hold one body per language. The rule is strict on purpose: * **No language tabs**: the template is language-agnostic and sends to everyone. * **With language tabs**: each contact gets the body matching their language. If no tab matches, **Nudge holds the send** rather than deliver the wrong language. A Turkish lead never gets the German version because "something is better than nothing" loses deals. Two rules follow from that, and both show up when a template is approved for WhatsApp cold outreach: * **A template with one language tab sends that language to everyone by default.** With a single tab there is no second language to match a contact against, so matching by owner could only ever skip people. Trigger actions default to "for everyone" and you can still switch back to matching each contact's owner for a genuinely single-audience campaign. * **A language tab can't be removed while it is approved.** Removing it wouldn't withdraw the approval — it would leave it stranded, and first messages from that number would start failing. Remove the approval first under **Meta template**, then the tab. ## What Meta holds Once a WhatsApp template is approved, Meta keeps its own copy, and three things belong to Meta from then on: the **body**, the **header** and the **buttons**. Everything else — tags, course type, country, the assistant toggle, variable defaults — is yours to change freely and saves without a word. Change one of Meta's three and **Save asks whether to resubmit**. That is not bureaucracy: saving on its own would leave Meta delivering the old wording while this page showed the new one, with no way to see the difference. Saving and resubmitting keeps them the same — the approved version keeps going out until Meta reviews the new one, so nothing stops in the meantime. Cancelling loses nothing. Your edits stay as unsaved changes, and **Discard** puts the approved wording back. **A template's language can't be changed at Meta.** A template is identified by its account, its name and its language together, so there is no "switch this to Turkish". You add the right language alongside the wrong one under the same name, then remove the old one. That is what **Submit for approval** on a second language row does. ## Media Attach an image or document from the shared asset library, or paste a public URL. On WhatsApp the body becomes the caption. Assets in use by a template are protected from deletion. ## Tags Tags are free-form. Add one with **+ Add**, type it, and it exists; the library filters by them and the template pickers group by them. Existing tags are suggested as you type, and typing one that already exists in different capitals reuses it rather than creating a near-duplicate. Click a tag's name to rename it. A rename applies **everywhere that tag is used**, not just on the template you are looking at — the ✕ beside it is what removes it from this one template. They are yours to organize with and have nothing to do with trigger categories, so naming a tag "Onboarding" does not create or rename anything else. ## WhatsApp and Email are separate tabs The library opens on **WhatsApp**, with **Email** beside it. They are split because the two channels need different columns: an email has a subject line, a WhatsApp template has Meta approvals, and neither means anything to the other. While you are searching, both tabs show how many matches they hold — so a template on the tab you are not looking at is never silently hidden. An email template with no name of its own is listed by its **subject**, with the subject shown underneath the name when the two differ. Name it whatever helps you find it; the subject is what the recipient reads. ## The Meta column On the WhatsApp tab, **Meta** shows where each template is approved — one row per WhatsApp account, with the message category underneath. A template with nothing submitted is simply blank. Most of the time an account name on its own means approved and working. Anything else says so: * **in review** — submitted, waiting on Meta * **rejected** — Meta declined it; the reason is under **Meta template** * **edited** — the wording has changed since approval, so cold sends still deliver the approved version * **wrong language** — approved, but in a language this template never sends in, so the approval can never be used Both the account names and the category are clickable, and they filter the library. The column's own funnel adds the states above, so "show me everything still in review" or "everything not submitted" is one click. ## Filtering the library Tags sit as a row above the table, each with the number of templates behind it. Click one to filter, click it again to release. Pick two and you get templates carrying either. The WhatsApp accounts and the Utility/Marketing categories sit in the same row, after a divider. The rows filter too: click a tag in the **Tags** column, or an account or category in **Meta**, and the library narrows to it. It is the same filter either way, so clicking a row's tag lights up its chip above. **Clear filters** appears next to **Columns** with a count of how many are on. One thing to know about the Tags column: the tag names filter, while the **+** that appears when you hover a row is what edits that template's tags. ## Writing an email The editor is what the email will look like — no separate preview to keep in step with it. To see it as a particular contact will receive it, with their name and other variables filled in, type their name into **Preview** at the top right. Clear it to go back to editing. Changes are held as a draft until you press **Save**, so a half-written edit is never sent: contacts keep getting the last saved version until then. **Save** and **Discard** sit at the top and bottom of the editor, and **Discard** keeps you in the editor with the last saved version restored — only the back arrow leaves. ## Quick chat Every WhatsApp template also appears in the menu beside a contact's phone number, which opens WhatsApp Web with the message filled in for that contact, from your own WhatsApp rather than a Nudge number. Language tabs apply as usual: a template with no tab for the contact's language shows greyed out. See [Quick chat](/channels/whatsapp#quick-chat) for the opener the mark itself uses. ## Housekeeping Each template tracks how often it fired and when it last fired, so the library shows you what actually gets used. Email templates also track replies, as in "4 of 60 sent emails got a reply", which is the number that tells you whether the copy works. A template can **set the contact's state on send**, which is how a sent message arms the next trigger in a chain. The library also imports and exports, so a set of templates can move between workspaces instead of being retyped. # Triggers Source: https://docs.autonudge.dev/automation/triggers Rules that read like sentences and chain into workflows Triggers are the heart of Nudge. One trigger is one rule: **when a contact matches these conditions, take these actions**. Chains of small triggers replace the do-everything flowchart. The trigger list, each row showing its state, actions and follow-up states as a readable chain ## What starts a trigger Three different things can set a trigger off, and you pick which when you create it: * **Lead state**, the default. The contact's fields changed and now match your conditions. This is the classic "possibility became Quote sent" rule. * **Call outcome**. An AI call finished. The trigger can read whether it was answered, which agent ran it, and what the call collected, so "no answer, try WhatsApp tomorrow" is one rule. * **Reply received**. A contact wrote back. You can scope it to specific mailboxes, which is how "anyone who replies to info@ gets tagged for review" works. Only lead-state triggers decide which contacts get pulled from HubSpot. Enabling one is what turns intake on for its audience. The other two react to contacts you already have. ## Anatomy of a trigger The trigger editor with owner audience, conditions and a WhatsApp action * **Owners**: which reps' contacts this trigger covers. A trigger can serve the whole team or one rep. * **Conditions**: field-based rules, grouped with AND/OR. "Possibility is Quote sent" is the classic, but any registry field works: postcode starts with 6, budget above X, homeowner is Yes. **Phone country** is available too — see [Filtering by the phone's country](#filtering-by-the-phones-country). * **Message actions**: one or more sends, each with its own channel (WhatsApp, email or call), delay, and send window. A single trigger can call immediately AND queue a WhatsApp for two days later. * **CRM writes**: what to set when the trigger fires, when its last message has been sent, or when a call ends. This is how chains form: the call action's "on failure set possibility to No answer" is what arms the no-answer follow-up trigger. * **Notes**: a trigger can also write a note on the contact, explaining in plain words what it did and why. See [Notes a trigger writes](#notes-a-trigger-writes). ## Send windows Each WhatsApp action picks when it is allowed to fire: **Business hours** holds until the owner's working hours, **Anytime** sends immediately, **Off-hours only** deliberately waits for the evening. Calls always clamp to the calling agent's hours; emails send any time. ## Delayed messages are re-checked before they go out A message queued for tomorrow is not sent blindly tomorrow. Just before it goes out, Nudge refreshes that contact from your CRM and checks the trigger's conditions again. If the contact no longer matches, the message is cancelled instead of sent. This is automatic and always on — it is what stops a three-day drip from messaging someone who was reached on day one. Sometimes the rule that lets a contact in is not the rule that should keep the send alive. **Re-check before sending** lets you write a separate, narrower check for that moment. The case it exists for: a callback trigger enters on "call-back time is set **or** status is Call Back", because either signal means the contact asked to be called. Two hours later only the status still means anything — the call-back time is a record of what was said on the call and never goes away. Without a separate check, moving that contact's status by hand wouldn't stop the call. With **Re-check before sending** set to just "status is Call Back", it does. Turn it on and it starts as a copy of your conditions, which you then cut down. Turn it off and you are back to re-checking the conditions themselves. ## Seeing what is queued **Activity → Queued** lists everything scheduled and not yet sent, soonest first, across every channel. Each row shows when it fires, who it goes to, and which trigger queued it. Hover a row for **Cancel** to stop that one send. The rest of Activity is a record of what already happened, so a message waiting on a two-day delay never appeared there. Queued is the other half: what is about to happen. The Dashboard's **Queue** count links straight to it. To see everything one trigger has done, open the trigger's row and click **View all in Activity**, or pick the trigger in the **Source** column's filter on the Activity tab. The same menu lists your colleagues under **People**: pick one to see only what they did by hand. The menu has a search box. Either way you get that trigger's events across the whole log, newest first, fifty at a time. To see everything that happened with one person, type their name in the search box at the top of Activity and pick them from the list. The feed narrows to that contact, a pill above the table says so, and the pill's × brings the whole feed back. The link in your address bar keeps the scope, so you can send it to a colleague. The first tab is **General**: everything, manual actions and trigger actions alike. On the **Calls** tab the **Agent** and **Result** headers filter too, so "every call the student agent handled that went unanswered" is two picks. The Source column names what did each row: the trigger, a reply, HubSpot's dialler, or the colleague who did it by hand. ## When CRM writes happen A trigger's property writes normally land the moment it fires. On a trigger that sends a sequence, that is often too early — "we tried three times and got nothing" isn't true until the third message has actually gone. Set **Apply** to **After the last message is sent** and the writes wait for the final message in the trigger to go out. If the sequence stops early, they never happen at all: the contact replied, the contact stopped matching, the send failed. That is the point of the setting. Use **When the trigger fires** for anything that marks the *start* of something, like flagging a contact as awaiting a callback. ## Notes a trigger writes A trigger can write a note on the contact alongside its property writes. Add one with **Write a note** in the CRM writes area, and type it in the same editor you use for emails — `[firstname]` and the other variables work. A note is for the colleague who opens that contact weeks later and asks "why does this say that?". A status tells them *what* the record is; the note tells them *why*. A rule that marks someone as outside your calling area, for example, can say so in a sentence instead of leaving a status nobody can explain. Notes follow the same timing choice as property writes: when the trigger fires, or after the last message has been sent. If your workspace has an OpenAI key connected (Settings → Connections), a **Suggest** button appears under the note. It drafts a sentence from the rule's own conditions and actions — never from contact data, since a trigger is written before any particular contact matches it. It only ever fills the box when you click it, and never overwrites what you have already typed. Read it before saving: the note becomes a permanent record on every contact the rule touches. ## Filtering by the phone's country **Phone country** is a condition like any other, but it reads the country from the contact's phone number rather than from a field you maintain. Pick a country from the list and use **is** or **is not**. It exists for the case where geography decides what should happen: a voice agent that can only dial certain countries, a team that only handles one market. "Phone country is not Ireland → mark them and write a note explaining why" is the shape it was built for. Two things worth knowing: * **A contact with no phone number matches neither** *is* **nor** *is not*. "Is not Ireland" does not quietly include everyone you have no number for. Add **Phone country is unknown** as a separate condition if you want those too. * **Your CRM cannot filter on this**, so it is checked in Nudge after contacts are pulled in. In practice that means the **Check matches** count shown against your CRM is a wider number than what will actually fire — the page says so where it applies, and the "in Nudge" figure beside it is exact. Always pair phone country with at least one ordinary field condition so the rule still has a sensible scope. ## Enabling a trigger This is the single most important choice in the editor, and the one that surprises people. New triggers start disabled. When you switch one on, you decide what happens to the contacts who already match: * **Only new matches** (the default). The trigger fires from here forward. Everyone currently sitting in that state is skipped, on purpose. * **Also send to contacts that matched recently**. The trigger also fires, the moment you switch it on, for contacts that started matching inside a window you pick: the last 1, 3, 7 or 30 days. Seven is the default. The window is the point. A trigger is forward-looking, and "everyone who matches" with no bound is five-year-old contacts that a workflow happened to touch. Those are a Bulk Action job, not a trigger's. The window is measured on when the contact last changed in your CRM, not when it was created, so an old contact whose details just changed still counts. Before you switch on, **Check for current matches** asks your CRM directly and lists every contact that would receive the message, with their phone numbers, and marks the ones Nudge doesn't hold yet (they're pulled in first). That list is the list that sends. Use it every time; it costs a click and it has saved more than one accidental blast. Two guardrails sit behind it. Above 100 contacts, switching on asks you to confirm the number first. Above 5,000, it refuses, and you narrow the conditions or the window. And every queued message is re-checked right before it sends, so a contact who was assigned an owner or scored in the meantime is skipped rather than messaged. ## Pausing on reply By default a trigger's queued messages are cancelled when the contact replies, so nobody gets automated at while a rep is mid-conversation. Each trigger has its own toggle for this. Turning it off is right in one specific case: the contact asked for the thing. A callback they booked should still happen even though they just wrote to you. ## Once per contact A trigger fires **once** per contact, ever. A contact bouncing back into the same state does not get the same message twice. Editing a trigger resets this, so your corrected version reaches the audience again; still-queued sends from the old version are cancelled at the same time. Call-outcome triggers re-arm after 30 days of silence, so a lead who re-engages months later gets the retry chain again instead of being permanently used up. ## Categories Trigger categories are yours to define. They all live under the single **Triggers** tab — the picker at the top left of that page switches between them, so adding a category never grows the sidebar. The demo ships with Lead qualification and Newsletter; add categories like Reactivation or Onboarding in Workspace setup. New triggers start disabled so you can review them before they touch live contacts. # WhatsApp assistant Source: https://docs.autonudge.dev/channels/assistant An assistant that answers your WhatsApp messages, drafts replies, or stays out of the way People message you at ten at night, at the weekend, and while your team is on a call. The assistant answers them — in their language, using what you already know about them — or writes the reply and waits for you to press send. It is not a chatbot menu. It reads the conversation and the contact's record, answers the question, and hands over to a person when the answer is not one it should be giving. ## One assistant per number The number someone messages already says which desk they reached: a market, a language, an audience. So each **Cloud API number** gets its own assistant, with its own name and its own instructions. That is what lets a Turkish line and a Malaysian line answer completely differently, and it is what lets you switch one on while the other stays off. Find them under **Settings → Agents**. Every Cloud API number is listed whether or not it has an assistant yet. The assistant runs on **Cloud API numbers only**, and the number has to be set to **two-way**. Personal numbers paired by QR are deliberately left alone: those are a rep's own line for warm one-to-one conversations, which is the last place an automatic reply belongs. A number that isn't two-way doesn't keep incoming messages, so there would be nothing for the assistant to read — the row tells you so and won't let you switch it on. ## Off, Suggest, Live Every assistant is in one of three states, set on its row or on its page. * **Off** — nothing happens. This is where every number starts. * **Suggest** — when a contact writes, a draft reply appears in the conversation, visible only to your team, with **Send** and **Discard**. Nothing goes out on its own. * **Live** — it replies by itself, about fifteen seconds after the contact stops writing. **Start on Suggest.** Read a week of drafts before you let anything reach a customer by itself. Suggest is useful on its own — a reply written and waiting is faster than one you have to think of — and the assistant's page shows what share of its drafts your team actually sent, which is the number that tells you whether it's ready. Editing a draft before you send it still counts as sent. What that percentage measures is whether the draft was worth having, not whether the wording was perfect. ## Writing its instructions Click the assistant's name to open its page. **Instructions** is where you say how this desk answers: who it's talking to, what it should offer, what it must never say, and when to get a person involved. Instructions do not save as you type. A half-written sentence would otherwise be live on the very next message a customer sends. The page says when you have unsaved work and offers **Save** or **Discard changes**. A short brief that is specific beats a long one that is vague. The most useful lines are usually the refusals — the figures it may not quote, the promises it may not make. ## What it knows You don't have to tell it who it's talking to. Before it writes anything it already has: * **The contact's record** — their name, and the details on their card, in plain wording rather than raw values. * **What your calls collected** — the answers your voice agents captured, plus a short summary of recent calls. A chat can pick up where a phone call left off. * **The last ten messages** in the conversation. * **What the business knows** — see below. It deliberately does **not** see your internal notes, the contact's status, their emails, or full call transcripts. Those are how your team talks about someone, not how you talk to them. Ten messages is short on purpose. The conversation is short-term memory; the contact's record is the long-term memory. A person picking up a chat scrolls back a screen, not a year. ### What the business knows Under the instructions is a shared list of facts: opening hours, parking, refund policy — the answers you give twenty times a week and that don't live in a field or a template. It is **shared by every assistant**, so write it once rather than into each one's instructions. Don't retype things Nudge already holds, like a contact's own details: prose that repeats a record can contradict it, and the contradiction is invisible until someone is told the wrong thing. Write it in whatever language you think in. The assistant replies in the customer's. ## Saved messages it can send The assistant can send your saved messages — a price list, a booking link, a brochure — but only the ones you allow. On a WhatsApp template, tick **The assistant can send this**. You can add one plain line saying when it applies, like *"send when they ask about opening times"*. That is guidance, not a keyword rule: "what time do you open" and "are you open Sundays" both land on it. Nothing is offered by default, and that is the point. Most of a library is outreach copy, and one of those going out in the middle of a live conversation is exactly what this prevents. ## When it hands over Sooner or later someone asks for something the assistant shouldn't answer — an exact figure, a commitment, or simply a person. **When it hands over** decides what happens next. * **Keep answering** — it flags the conversation for your team, says so once, and carries on helping with everything else. Not being able to quote a price is no reason to stop answering the opening hours. * **Stop replying** — it says a colleague will follow up and then goes quiet until someone hands it back. The right choice when half an answer is worse than none. On **Keep answering**, a flagged conversation shows a line above the composer saying it needs a person, and when. It says it once — a conversation that announces a colleague on every message is the thing this is designed to avoid. Either way, **a person typing in the conversation takes it over immediately.** No setting, no confirmation: the reply is the instruction. ## Changing it for one conversation The setting on the number is a **default**. Any single conversation can disagree with it, from the strip above the message box: the same **Off / Suggest / Live**, for this chat only. That covers the ordinary cases — a delicate conversation you want to write yourself on an otherwise live number, or one straightforward chat you're happy to let run while the rest are drafts. To put a conversation back to normal, pick whatever the number itself is set to. There's no separate "back to default" button because there doesn't need to be: a conversation you never touched follows the number, including when you change it later, and one you set by hand keeps your choice. ## Introducing itself **Introduce itself** is off by default. Switch it on and the first reply a contact ever gets opens with a line naming the assistant as a digital one. Whatever you choose, it will never claim to be a person, and if a contact asks outright whether they're talking to a bot it says so plainly and carries on helping. That part isn't a setting. Some markets and some industries expect the disclosure. If you're messaging people in the EU, or in a regulated field, turning it on is the safer read. ## Trying it before anyone sees it **Try it** on the assistant's page talks to the real assistant with your saved instructions. Nothing is sent and no contact is involved. It answers "does this sound the way I want", which is the question you ask twenty times while writing a brief. It does not answer "will this handle my customers" — there's no contact record behind it. Suggest mode on real conversations answers that one. ## What it costs Replies are charged by the AI provider you connected, per message, and it is small — fractions of a penny for a typical reply. **Recent replies** on the assistant's page shows every turn with its cost, and the month's total against your budget. The budget is workspace-wide, because the bill is. It's checked before each reply, so the ceiling can be passed by at most one reply's worth rather than found out about afterwards. If the page says **spend not counted**, the model you've selected has no price on file, so the total isn't accumulating and your budget can't be reached. Pick a listed model, or treat the cap as off until it is. ## What it won't do Worth knowing, because these are deliberate: * **It never changes the contact's record.** If someone tells it something worth keeping, it acknowledges and carries on — your team reads the conversation and records it. * **It answers at most ten times an hour per contact.** A loop can't run away with your budget or your customer's patience. * **It waits about fifteen seconds** after the contact's last message, so three messages typed in a row get one answer to all of them rather than three replies to a question nobody finished asking. * **It can't see attachments.** Sent a photo or a voice note, it says so and gets a person rather than guessing. * **If the AI provider fails, the contact gets nothing** — never an error message from a system they didn't know was there. The conversation just stays unread and your team answers it. * **Meta's 24-hour rule still applies.** The assistant answers people who have messaged you, so it is almost always inside the window — but a reply that lands outside it needs an approved template like any other. See [WhatsApp](/channels/whatsapp). ## Getting started **Settings → Connections**, then add an OpenAI or Anthropic key. Without one the assistant has nothing to think with. You can leave the model blank: the field shows which one will run, and the picker offers what your key can reach. **Settings → WhatsApp**. Incoming messages have to be kept for the assistant to read them. **Settings → Agents → Set up**. Give it a name your customers would find natural, write its instructions, and save. Read the drafts for a week. Watch the share your team actually sends. When the drafts read the way you'd write them, switch that number to **Live** — one number, not all of them. # AI voice calls Source: https://docs.autonudge.dev/channels/calls An agent that calls, qualifies and routes the outcome Nudge places real phone calls through AI voice agents. The agent has an actual conversation in the lead's language, asks your qualification questions, and the outcome routes the next step. ## Agents and numbers An **agent** is a configured voice, script and language, and its phone setup has two sides, shown as two columns in the agents list: the **inbound numbers** — the numbers a caller dials to reach this agent, picked from your account's numbers right in the list; a number answers for one agent, so choosing it here moves it off whichever agent had it — and its **outbound numbers**, the pool it calls out from. The outbound pool is ordered: for each contact, a number in the contact's own country is dialled first; otherwise the pool's order decides, and a number is never used for a country it isn't allowed to call — so a contact with no local line goes out on whichever of your lines may call their country. Each agent also has its own calling hours. Each contact owner gets a **default calling agent**, so "call this lead" always knows which voice and which number to use. ## Editing an agent Click an agent's name to open its page. Everything the agent is lives there: * **Prompt and opening line** — what the agent says and how it behaves. Anything in `{{double braces}}` is a placeholder that gets filled per call; it shows as a blue chip so you can see at a glance what the agent will know. * **When we've spoken before** — the first sentence for someone the agent has already talked to. The opening line is fixed text, so without this a person who said yes on Tuesday hears "you clicked our ad" again on Friday. Write it once with placeholders in square brackets: `[first_name]`, `[when]` (becomes "earlier today", "yesterday", "on Tuesday", "a while back") and any value the agent collects, such as `[room_type]` or `[address]`. Wrap a clause in double square brackets, `[[ about your [room_type] in [address]]]`, and it drops out cleanly when a value is missing. Then put `{{opener}}` in the opening line where the sentence belongs, and give `opener` a before-call default for first calls. This field saves when you leave it, unlike the rest of the page, because it lives in Nudge and not on the agent. * **Voice** — swap it any time, with a preview button to hear it first. * **Language** — the language the agent listens and speaks in. It also sets how speech is recognised, so a line in Ireland belongs on British English, not American, or place names come out wrong. Most voices speak several languages. Run a test call after changing it. * **Voicemail** — what the agent does when it reaches an answering machine instead of a person. * **Variables** — the answers this agent collects. Open a variable's type and you can also set what the agent assumes for it before the call, for a caller Nudge doesn't know yet; leave it blank and the agent simply asks. Every assumption you've set is listed once under the table. Under voice and call handling the page also says, in a line, what else the agent can do on a call: whether it may end the call itself, which other agents it hands callers to, and which number it transfers them to. That line is read from the agent's setup and is not edited here; if you need a hand-off or transfer added or changed, ask us. One **Publish** button covers all of it, and it takes effect on the agent's very next call. Nothing saves as you type: a half-finished edit would otherwise go live mid-sentence. While you have unsaved work the page says so and offers **Discard changes**. Leaving the page is safe. Your unfinished edits stay in this browser, so you can go and look something up and come back to them. They are yours alone until you publish — a colleague opening the agent sees the version that's live, not your draft. **Discard changes** is the one deliberate way to throw work away. Use the search box at the top to find your way around a long prompt. It highlights matches in the text and filters the variable list, and tells you how many variables it's hiding so a filtered list never looks like a short one. ## When nobody picks up Turn **Voicemail** on and the agent listens for an answering machine during the first three minutes of a call. Then pick what it should do: * **Hang up** — the agent ends the call without speaking. This is where the toggle starts, because it needs nothing written. * **Leave a message** — the agent speaks, then hangs up. A message can be written two ways. **Exact words** are spoken as you wrote them. **Instructions** describe the message and let the agent word it itself. Either can use `{{placeholders}}`, so a voicemail can greet someone by name. Exact words is the safer default: a voicemail is one shot, with nobody on the other end to correct a phrasing you didn't intend. You can't publish an empty message — an agent that answers the machine and says nothing leaves a recording of silence, which is worse than hanging up. Pick **Hang up** instead if that's what you want. ## What the agent collects Each variable has a name, a description telling the agent what to capture, and a type: text, number, yes/no, or a list of choices. A list needs at least one choice before you can publish. When a variable is captured is decided by **which section you add it to**, and each section has its own **+ Add variable**: * **During the call** — captured the moment the caller says it, so it survives even if the call drops. For anything expensive to mishear, like a callback time or a budget, open the type dropdown and turn on *Caller confirms first*. * **After the call** — read out of the call analysis once the call ends. This is right for most answers. * **Before the call** — not captured at all. These are the fallback values the agent starts with when a call carries nothing better, so the script still reads naturally. If your opening line says "Hello " and a contact has no first name on file, a default of `there` keeps the agent from opening with an awkward pause. To move an existing variable between *During* and *After*, remove it and add it again in the section you want. Per-contact values always beat the defaults. Nudge sends the contact's real name and number with every call, so the default only fills a genuine gap. **In a standalone workspace, an answer can be saved on the contact.** Each variable row has a **Contact field** mark. An outline circle means the answer is kept on the call only, under its own `retell_` name, still usable in trigger conditions. Click it and Nudge creates a contact field with the same name and type and saves the answer there from the next call on; a green check shows it. Click the check to stop; the field and its data stay, the agent just no longer writes it. If a field of that name already exists but is people-only, the circle's hover text says so, and clicking it lets the agent write it instead of creating a second field. Going the other way, **Seed from contact fields** adds a variable row for every field an agent may already write. The choice is per agent: one agent can save Company on the contact while another keeps it on the call. A contact's core fields (name, email) are always saved and can't be switched off; the phone number is never written by an agent, because it's how the call was matched. Two things worth knowing: * Fields left as *Staff* are off-limits to the agent even if it heard an answer. A voicemail still returns a full set of guesses, and those must not overwrite what a person typed. * An answer with no matching field still lands, namespaced, so you can use it in trigger conditions. **In HubSpot mode it works the other way round:** you declare the variables on the agent, and Nudge mirrors them into a read-only list under Workspace setup so you can label them and use them in conditions. ## Placing calls Calls happen two ways: * **Automated**: a trigger's call action, for example "new lead in state Contacted: call within business hours". Call timing clamps to the agent's calling hours. * **Manual**: the **Place call** button on a contact page or inbox thread. The dialog pre-selects the owner's default agent and number, and prints the last call that connected (when, how long, what came of it) before you dial, so a person who said yes three days ago is not cold-called by accident. If the person has asked not to be called again, the dialog says so in red and asks you to tick **Call anyway**. A person can always place a call; automated calls to that person are not placed, and the timeline says why. To hear an agent yourself, use **Test call** on the agent page — open it by clicking the agent's name. It rings a number you type, from that agent's own number. Real minutes are billed, and it always runs the published version — publish first if you want to hear an edit. ## Outcomes drive the workflow Every call ends with an outcome: reached, no answer, voicemail, not interested, and so on. A trigger can map outcomes to states, for example call succeeded sets possibility to `Qualified`, call failed sets `No answer`, which arms the WhatsApp follow-up trigger. That call, no answer, message, close chain is the canonical Nudge workflow. After each call, the summary, outcome and sentiment land on the contact's timeline. Repeated no-answers are counted per contact, so a rule like "3 failed attempts: close the file" is one condition, not custom logic. Two things a call does get flagged rather than trusted. If a call replaces an answer you already had, say "wants to proceed" going from Yes to No, the new value is written and every admin gets a notification naming the change and the call length, so a 30-second "it's just a machine" does not quietly close a good lead. And if an agent hands a call to another agent that then finds the caller is not the kind of person it serves, nothing from that call is saved, the call card says so, and admins are told. Give an agent a `do_not_call` variable (Yes or empty) and Nudge honours it everywhere: automated calls stop, and a person dialling by hand is asked first. ## Listening back The contact's Calls tab shows every call as its own card, newest first — the outcome, the recording ready to play, and the summary are right there without a click. Each card also names the numbers the call was on — which of your lines it went out from, or which one the caller dialled — so a workspace with several numbers can always tell, and says where the call came from: a trigger by name, HubSpot's own dialler, or the colleague who placed it. **Details** on a card unfolds the answers the agent collected and the **full transcript** laid out as a conversation. That last one is what you want when a summary reads oddly or an answer came back empty: you can see exactly what was asked and what the person said. Opening a call from Activity lands you on its card with the details already unfolded. The [live demo](https://demo.nudgecrm.dev) simulates calls end to end, including summaries and outcomes, so you can watch the routing work without a phone bill. # Email Source: https://docs.autonudge.dev/channels/email The follow-up that documents itself Email is Nudge's paper-trail channel: confirmations, summaries, quotes and newsletters that should sit in an inbox rather than a chat. ## Where email shows up * **Trigger actions**: any trigger can include an email action with its own delay, for example "state is Survey booked: send the confirmation email". * **Bulk send**: email is one of the channels a [bulk send](/automation/bulk-send) can compose. * **Newsletter-style categories**: recurring campaigns are just triggers in their own category, so they get the same conditions and audience controls as everything else. ## Senders Sending addresses live in **Settings → Emails** as a shared list, each with a label, an address and its own HTML signature. Every address has a **Belongs to** field: * **Set to a person**: it is their address, and it gets picked automatically when they compose. * **Left unset**: it is a shared address like info@ or support@, offered to everyone and auto-selected for nobody. Click a sender to open it: the display name, who it belongs to, its signature, and Remove. The address itself is fixed once added, because it has to match what your sending account is authorized to send as. Wrong address means removing the row and adding the right one. **Add sender** opens a short form. One thing to know before you use it: typing an address here does not make it deliverable. The domain has to be verified on the sending account first, which is not something this screen can do, so ask the Autotakt team to set it up and then add it here. ### Editing a signature Settings is admin-only, so signatures are also editable from the signature button in any email editor — the composer, a template, a trigger's email body. The menu lists every sender: click a name to insert its signature, or the cog beside it to edit. Addresses with nothing saved yet appear too, so that button is where you write your first one. The edit is global. A signature belongs to the address, not to the template you happen to have open, so changing it changes what gets inserted for everyone from then on. Emails and templates that already contain a copy keep the old one. A trigger's email action picks its own From address independently. Automated email and hand-written email are separate systems on purpose, the same split HubSpot draws between marketing and sales email, so nobody's personal address gets attached to a campaign by accident. ## Sending a one-off email Open a contact and compose. The From address is on the envelope line next to To, where you see it before you start typing, and it is chosen for you in this order: the address a thread was already using, then the last one you deliberately picked, then your own, then the only one there is. Switching sender swaps the signature rather than stacking a second one underneath. If you have edited the signature by hand, Nudge leaves your version alone; a duplicate signature is annoying, silently eating text you wrote is worse. You can also email an address that is not a contact yet. **+ New contact** has **Add and send email** in its footer, which creates the row and opens the composer in one step. First name, last name and phone are all optional, so this stays type-the-address-and-go. ## Inbound email Email is two-way. Replies land in the [Inbox](/contacts/inbox) alongside WhatsApp and calls, marked with an email pill, and a reply pauses automation for that contact like any other. Settings → Emails also carries the workspace-level switches: an unsubscribe link on automated emails, open tracking, and whether an email from an unknown address should create a contact. ## Templates and languages Email templates support the same [variables](/automation/templates#variables) and language tabs as WhatsApp templates. The same language rule applies: if a template has language tabs and none matches the contact's language, Nudge holds the send rather than deliver the wrong language. Unlike WhatsApp, email actions send at any hour. Nobody's phone buzzes for an email at 22:00, and morning inboxes are read top to bottom. # WhatsApp Source: https://docs.autonudge.dev/channels/whatsapp Two ways to connect, both built to protect your numbers WhatsApp is where leads actually answer, and it is also where careless automation gets numbers banned. Nudge supports two kinds of WhatsApp connections and treats them very differently on purpose. ## Adding a number **Settings → WhatsApp** lists every number your workspace can send from. **+ Add number** asks which of the two kinds you are connecting: * **Personal number** pairs a handset by scanning a QR code, the same way WhatsApp Web does. * **Cloud API number** registers a number you already hold in Meta Business Manager. Hovering a row reveals **Test**, which sends a real message so you can confirm the connection before a campaign relies on it, and the control to remove the number. ## Personal numbers A rep's own WhatsApp number, paired by QR. This is the warm lane: automated follow-ups and one-to-one conversations that look and feel like a person texting, because the number belongs to a person. To keep those numbers safe, Nudge paces them automatically. Admins set this once in **Settings → WhatsApp** and every automated send obeys it: * **Min gap between sends** per number, so messages trickle out at human speed. * **Randomize up to**, which jitters that gap so the rhythm is not machine-perfect. * **Max per hour** and **Max per day** per number, on top of the gap. * **Working hours**: automated messages hold until the owner's business hours. A 3am follow-up closes no deals. * **Pause automation after a reply**, in days. An inbound message cancels that contact's queued automated sends. One setting is worth knowing by name: **Send manual messages instantly**. With it on, a message a rep types by hand skips every gate above and goes straight out. That is why your own reply lands immediately while an automated one waits its turn. Live conversation should never sit in a queue. There is also **Capture chats sent from your phone**, which pulls messages a rep sends from the WhatsApp app on their own device into the contact's timeline. ## Cloud API numbers For traffic that should not ride on a personal number, connect an official Meta number through the **WhatsApp Cloud API**. Meta enforces its own limits on this lane, so Nudge does not add pacing of its own. A Cloud API row carries two Meta identifiers, the phone-number ID and the business account ID that owns it. Both sit behind the arrow next to the number: you need them when you first wire an account up, and almost never afterwards. The business account ID is the one that decides where a template's approval counts, so it is worth checking when a template works on one number and not another. Meta's one hard rule on this lane: a **free-form message only delivers within 24 hours of the contact's last message to you**. Anything outside that window, including all first-touch outreach, must be an **approved template message**. A Cloud API number can also answer on its own, or draft replies for you to send. See [WhatsApp assistant](/channels/assistant). ### Approved templates for cold outreach Nudge handles the approval workflow from the template editor. Open a WhatsApp template and use the **Meta template** section: 1. **Submit for approval.** Nudge sends the template body to Meta for review. Review usually takes minutes to two days. If you still have unsaved edits, submitting saves them first, so what Meta approves is exactly what will send. 2. **Watch the status.** The section shows where things stand for each business account and language: in review, approved, or rejected with Meta's reason. Approvals arrive automatically; **Refresh status** checks on demand. 3. **Send as usual.** Once approved, nothing else changes. Any send that uses this template from a Cloud API number just works: triggers, bulk sends, and a one-off message to a single contact with the template picked in the composer. Inside the 24-hour window Nudge sends your current text directly; outside it, Meta delivers the approved version. A few things to know: * **A field variable needs a fallback before you can submit.** If your message uses something from your field registry, like `[course_type]`, it needs a default: the text that prints for a contact whose value is blank. Set them in the boxes under the message body. Meta refuses the whole message when a variable arrives empty, so without a fallback the send fails for every contact missing that field, one at a time and quietly. Nudge blocks the submission until each one has a fallback. The built-in variables are exempt — `[firstname]` and the rest come from the contact's own name, so they can't turn up empty. * **Approval freezes the wording.** Editing the template after approval does not change what cold sends deliver. The editor shows a "body changed since approval" notice, and clicking **Resubmit** puts the new wording through review. Until it is approved, cold sends keep using the previously approved text. * **Meta decides the category, and it can differ from what you picked.** A message submitted as Utility that Meta reads as promotional is approved as Marketing rather than rejected. Marketing costs more per message and Meta limits how often one contact can receive it. When that happens the template's row shows **Marketing · submitted as Utility**, and workspace admins get a notification (turn the email on under Settings → Notifications). Meta gives no way to check before submitting, in Nudge or in WhatsApp Manager. The category is locked once approved, so the way back to Utility is a new template name: reword the message, then click **Resubmit as Utility under a new name** on that row. Nudge creates the new template at Meta (same name with a number added), every language of the template on that number moves with it, and the approved version keeps delivering until the new one is approved. The button stays disabled until the wording differs from what Meta filed — the same text would get the same verdict. * **When Meta rejects, its reason and recommendation appear under the row.** That is the wording to change before resubmitting. * **Buttons and a header travel with the template.** A template can carry a short header line and up to three buttons (a link, or a quick reply the contact taps). Meta approves them with the template, Nudge sends them with every template send, and a tapped quick reply shows up in the conversation as the button's words, the same as a typed reply. The composer and trigger previews draw the header and buttons so you see what arrives, and the sent message shows them in the conversation exactly as the contact got them. * **A number's business account has to be connected to Nudge for replies to arrive.** Nudge does this itself when you add a Cloud API number or change its business account. If the connection is missing, the number's row on Settings → Accounts reads **Not receiving** with a **Fix** button: sending still works, but replies, delivery receipts and button taps don't reach Nudge until you fix it. * **Approvals are per business account and per language.** A template approved for one WhatsApp Business Account has to be submitted again to use it on a number belonging to another, and each language of a multi-language template is reviewed on its own. * **A template needs a language before it can be submitted.** "Everyone" is not a language, and Meta reviews under exactly one — so a template with no language tab used to go in as English whatever it actually said, which is how messages written in one language ended up approved as another and unable to send. Add a language tab first. Templates already approved that way keep working; they just can't be added to a new number. * **An approval filed under the wrong language shows as "wrong language".** It can never be used — the send looks for the language the template actually sends in, doesn't find it, and Meta refuses the message. It sits under its account in **Meta template** with a ✕ to remove it. The fix is to submit the template again in the right language, which lands under the same name at Meta. * **Picking a template in the composer sends that template.** If you choose one and then edit the words in the box, your edits are not what goes out: the message is sent as the template, so the contact gets the template's current wording (and, outside the 24-hour window, the approved wording). To send something you have typed yourself, clear the template picker first. A cold send with no approved template is rejected by Meta and shows as failed on the contact's timeline, so nothing is silently dropped. A template with an image or document attached can't be submitted yet — remove the attachment first; free-form messages inside the 24-hour window still carry media as usual. ### Header and buttons An approved message can carry more than text. Under the message body (and per language, if the template has language tabs) you can add: * **A header** — one bold line shown above the message, up to 60 characters. * **Up to three buttons** — a **link** the contact can open (a form, a booking page) or a **quick reply** they can tap, which arrives back as an ordinary message. Both go through Meta's review with the template, so add them and submit (or resubmit) for approval. They appear whenever the approved message is delivered from a business number — including inside the 24-hour window, where Nudge deliberately sends the approved version rather than free text so the buttons aren't lost. Messages from a personal number never carry them. Header and buttons are fixed text: variables like `[firstname]` work in the message body only, and a button's link is the same for every contact. ## Which number sends what The sending number is chosen per action. A trigger's WhatsApp action set to **Each lead's owner** sends from the owner's connected number, so the lead hears from the same person who will pick up the conversation. Bulk sends can override with one fixed sender. **The list only offers numbers that can send that message.** On a trigger you get every personal number, plus the Cloud API numbers whose account has an approved version of the message you picked. Personal numbers can send any text to anyone, so they are always there. A Cloud API number can only start a conversation with a message approved on its own account, so it appears for those messages and not for others. If a number was chosen before and it no longer qualifies, it stays in the list rather than disappearing, with a note explaining that it will only reach contacts who wrote to you in the last 24 hours. Bulk sends offer **Cloud API numbers only**. A large send down a personal number is the fastest way to get that number blocked, and the Cloud API exists to carry volume. **Each lead's owner** is the one choice that skips this check, because the number isn't known until the contact is. If an owner's connected number is a Cloud API number and the message isn't approved on its account, that send will fail. Owners on personal numbers are unaffected. Check under Settings → Numbers which owners are on which line before pointing a trigger at an approved template. A reply you type in a conversation goes out from the number the conversation is on: the one the contact last wrote to, or the one that last reached them. That keeps the conversation on one line from the contact's side and keeps a fresh reply inside the free 24-hour session window, which belongs to that number. Every bubble in the thread names its number next to the time, so you can see which line a message travelled on. Only a contact who has never been in touch with any of your numbers is answered from their owner's number. ## Quick chat The contact page shows a WhatsApp mark beside every phone number. One click opens that number in WhatsApp Web, on the person's own WhatsApp, with the **opener** typed and ready. The small arrow beside the mark lists every WhatsApp template instead. Write the opener under **Settings → WhatsApp → Quick chat**, one version per language, for example "Hi \[salutation]" and "Merhaba \[salutation]". Variables work as they do in templates. The contact's owner language picks the version, the same way any send does. If there is no version for that language, or nothing is written, the chat opens with nothing typed rather than in the wrong language. Nudge reuses one WhatsApp Web tab for this: the first click opens it, later clicks switch that same tab to the next contact. If you have WhatsApp Web installed as an app in Chrome, set it to open links in Chrome rather than in the app, or the click will only bring the app window to the front. Nothing here goes through Nudge. The message is sent from the rep's own WhatsApp and is not recorded on the contact's timeline. ## Media Templates can attach an image or a document (PDF, spreadsheet) from the shared asset library; the message body becomes the caption. See [Templates](/automation/templates). When a contact sends **you** something on an official WhatsApp number, it appears in the thread: pictures show inline, voice notes get a player you can hit play on, and everything else arrives as a file you can open. A caption they typed comes through as the message. The remaining attachment types — video and stickers — are noted in the thread as having arrived, but the file itself is not kept. Contacts writing to a QR-linked personal number send text only. If a contact reacts to one of your messages, the emoji appears on that message rather than as a new one in the thread, the same way it does in WhatsApp. Taking the reaction back removes it here too. A reaction counts as them getting in touch, so it pauses any automated follow-up on that contact exactly as a written reply would. A voice note occasionally shows as a file to download rather than a player. That is Safari: WhatsApp records in a format it does not always play in the browser. Downloading it plays fine, and Chrome, Firefox and Edge play it in the thread. # The contact page Source: https://docs.autonudge.dev/contacts/contact-page One contact, every field and every touch Click any contact name anywhere in the app to open its page. The URL is shareable, so you can paste a contact link to a colleague. A contact page with editable fields on the left and the activity timeline on the right ## Left: the record All fields from your [fields registry](/settings/workspace) are editable in place: owner, possibility, phone, email and any custom fields like budget or roof type. Changes save as you go; there is no Save button. Empty fields collapse behind a "Show empty fields" link. Next to any phone number there is a WhatsApp mark. Clicking it opens that number in WhatsApp Web (or the WhatsApp app on a phone) with your opener already typed, "Hi Mehmet Bey" or "Merhaba Ayşe Hanım" depending on the contact. The small arrow beside it lists all your WhatsApp templates instead: pick one and the chat opens with that message filled in for this contact. This uses your own WhatsApp, the one your browser is signed into, so it is the fastest way to send a personal line. Nudge does not send or record these messages; they stay in your WhatsApp. The opener is set once for the workspace under [WhatsApp settings](/channels/whatsapp#quick-chat). Below the fields: * **Deals** shows the contact's open deals, with an add button. * **Skip outreach** exempts this one contact from every trigger. Use it for the lead who asked you to stop, or the edge case you want to handle by hand. You can still write to them yourself. * **Mute** does the opposite job: it stops the contact reaching *you*. Their thread drops out of the [Inbox](/contacts/inbox), and you get no notification and no [dot](/contacts/inbox#the-dots) when they write. Messages still send and arrive normally — you just have to go and look. Good for the customer who sends five messages a day about nothing urgent. Skip and Mute are independent, and it is worth knowing which way each one points. Skip is about what you send them. Mute is about what they can put in front of you. ## Right: the timeline Everything that happened, newest first: WhatsApp messages both ways, AI call summaries with their outcome, emails, notes, tasks and files. The channel icons at the top of the card filter it, and the contact's name sits in the top bar with a **purple dot** beside it — click the dot to pin this conversation for later, or click the arrow to go back where you came from. **Place call** starts an AI call to this contact right now, pre-filled with the owner's default agent and number. Switching to **Email** shows every email as its own card, newest first — the full subject, who wrote it, the message itself, and a quiet note at the bottom saying whether a sent email has been opened. Long emails are trimmed with a **Show more**; **Reply** on any card opens the composer with the subject and sending address already filled in. **Calls** works the same way: one card per call with the outcome, the recording ready to play and the summary in view, and **Details** unfolds the collected answers and the full transcript in place. When a message is queued but not yet sent, the timeline shows a real estimated send time that accounts for the sending number's queue, not a generic countdown. A queued message that never went out stays in the thread, struck through and greyed, labelled with why it was dropped — **they replied**, **no longer qualified**, **trigger edited**. It is the record of what automation *would* have said, and it is never mistaken for something the contact received. # Inbox Source: https://docs.autonudge.dev/contacts/inbox Replies from every channel in one place The Inbox is where conversations live. The left list orders contacts by their latest activity, with unread indicators; the right pane shows the selected contact's thread. The inbox with a WhatsApp conversation and an AI call summary in one thread ## One thread per contact The icons top right switch channel: the WhatsApp back and forth, emails, AI call summaries with their outcome badge. The Inbox opens on one channel at a time — for the whole history in a single stream, open the contact's own page. Opening a conversation lands you on whichever channel the latest message came in on, so an email reply opens the email thread rather than an empty WhatsApp tab. ## Finding a conversation The chips at the top of the list narrow it. **Unread** shows only conversations with a reply you haven't opened (the chip carries the count), **Pinned** shows what you've pinned for later. Nothing lit means you're seeing everything — click a lit chip again to come back to that. The list has no limit. It loads the newest fifty conversations and fetches more as you scroll down, so a campaign that brings in hundreds of replies puts every one of them in front of you, oldest at the bottom. The chips and the owner filter apply to the whole list, not just the part you've scrolled through; a count above five hundred shows as `500+`. To filter by colleague, open the **⋯** at the end of the row and tick one or more owners; **All owners** at the top of that list clears it in one go. Clicking the owner name on any row does the same thing in one step — click **Aysu** on a row and the list shows only Aysu's conversations, click it again to release. While an owner filter is on, a chip appears in the filter row naming who it holds, so the list never narrows without saying so. Search matches the contact's name, phone and email — and the name of whoever owns the lead, so typing a colleague's first name narrows the list to their conversations. Every row shows the owner beside the contact's name, so you can tell whose lead it is without opening it. ## Working through several at once Hover a row and a checkbox appears on its left. Tick one and the filter chips give way to a selection bar: how many you have picked, and what you can do with them. Once anything is ticked the boxes stay visible on every row, so picking a run is not a game of chase. **Shift-click picks a run.** Tick the first conversation, hold shift, click the last, and everything between comes with it — twenty rows in two clicks. It works on the checkbox or anywhere on the row once something is ticked. Went too far? Shift-click back inside the run and it clears from there down. The box at the left of the bar picks everything currently showing, and **Escape** drops the selection. **Read** clears the green dot on everything you picked without opening any of it. This is for the morning where forty replies came in overnight and half of them say "ok, thanks". To clear the unread mark on **everything at once**, use the **⋯** button at the end of the filter row. That one ignores your filters completely — it is the whole reason it exists, since ticking rows can only ever reach the conversations currently showing. The menu item carries the number it would clear, so you can see the scale before you use it — worth a glance, because there is no way to mark something unread again. **Mute** does in bulk what the switch on a contact's page does one at a time: those conversations leave the Inbox and stop notifying you. They go without a confirmation step, because nothing is lost — unmute any of them from their contact page, and muted contacts sit at the bottom of Contacts wearing a mute icon. ## Replying Type in the thread to answer on WhatsApp from the number the conversation is on — the one the contact last wrote to, or the one that last reached them — or switch to the email composer to answer an email thread on the address it came in on. Every WhatsApp bubble names its number next to the time (`API MY · 06:35`), so you can see which line a message came in on and which line your reply will leave from. A contact who has never written to one of your numbers is answered from their owner's number. Replies you send by hand are just messages; they do not re-trigger automations, and they skip the sending queue so they go out immediately. What the contact's reply DOES do is stop automation: queued automated messages for that contact are cancelled the moment an inbound message arrives, so nobody gets a robot follow-up mid-conversation. The pause lasts a configurable number of days, and an individual trigger can be set to ignore it when the contact explicitly asked for the thing. **Place call** in the thread header starts an AI call without leaving the inbox. ## Everything about the contact, in the thread The icons at the top right of the thread switch what you are looking at for that person: **WhatsApp**, **Email**, **Calls**, **Notes** and **Files**. Hovering an icon names it, and one with nothing behind it fades. Notes and Files are the same ones the contact's own page shows — write a note here and it is on the contact; upload a document here, or send an upload link, and it is filed against them. Answering a message is usually when you want both, so neither is worth leaving the inbox for. ## The dots Each conversation carries a small dot on the right. There are two, and they mean different things. A **green dot** means that contact has written to you and you have not opened the conversation yet. Opening it is the only thing that clears it — not visiting the Inbox, not switching tabs, not a colleague reading it. It is the same green dot the Inbox shows in the sidebar, so the sidebar goes quiet exactly when you have opened everything new, and never before. A reply that arrives while you are sitting in that conversation counts as read; you are looking at it. A **purple dot** means you pinned that conversation because you want to get back to it. Click the dot on any row to pin it, click a purple dot to unpin. It stays until you unpin it — a pin is the one marker that waits for you rather than clearing itself. Pinned conversations keep their normal place in the list, ordered by latest reply like everything else, and they never drop off the bottom no matter how much newer traffic arrives. A conversation that is both pinned and unopened shows purple, since the pin is the one that needs you to act. Pins are yours alone — pinning does not pin for your colleagues, and theirs never show on your list — and the same purple dot appears on the contact page, in Contacts, in Activity and on deal cards, so a conversation you pinned is flagged wherever you run into it. Outside the Inbox and the contact page the dot only reports; you pin and unpin from those two. The green dot is specific to the Inbox and its sidebar entry. ## Muting a conversation A contact you have muted — on their [contact page](/contacts/contact-page), or by picking them here and hitting **Mute** — never appears in this list, never lights the unread dot and never sends you a notification. Nothing else changes: you can still message them, their replies still land on their timeline, and they are still there in Contacts when you go looking. Unmute and they come straight back. # The contacts list Source: https://docs.autonudge.dev/contacts/overview Every lead, its state and its last touch on one line Contacts is the working surface of Nudge. Reps live here. The contacts table with possibility states, owners and last-contact outcomes ## Reading the table * **Name**, with a green **REPLIED** badge when the contact has answered on any channel. * **Possibility** is the contact's pipeline state. Triggers key off this value; changing it by hand also counts and can arm the next automation. * **Owner** is the rep responsible. Automated WhatsApp messages send from the owner's number, and calls use the owner's default calling agent unless a trigger says otherwise. * **Last contact** shows the most recent touch with its outcome: a successful or unsuccessful call, or the last message with its template name. ## Filters, search, columns Filters live on the column headers, not in a toolbar. Click a header's filter icon and pick one or more values; within one filter the values combine with OR. Search (top right) matches names accent-insensitively, so typing "Schonborn" finds "Schönborn". The **Columns** button lets each user pick their own visible columns, including any custom field from the [fields registry](/settings/workspace). ## Saved views A filter set you keep rebuilding should be a view. **Save as view** names the current filters and puts them one click away. Keep a view private, or share it with the team, in which case everyone can use it and only you can change it. "My unworked leads" and "Replied, no follow-up" are the two most teams end up living in. Admins can also export the table to CSV from the bottom of the columns menu. ## Acting on contacts Select rows with the checkboxes to message a whole segment at once (see [Bulk send](/automation/bulk-send)). **+ New contact** adds a lead by hand; contacts also arrive through [web forms](/crm/forms) or the [HubSpot sync](/crm/hubspot). Cells stay blank when there is nothing to show. No walls of zeros and dashes. # Deals and dashboard Source: https://docs.autonudge.dev/crm/deals The money view, fed by the same contacts Deals turn conversations into a pipeline you can count. The deals kanban board grouped by stage with per-stage totals ## The board Deals live on a kanban board grouped by stage, with a value total per column. Stages are yours to define per workspace. Add deals from the board or directly on a contact's page; a deal always belongs to a contact, so the full conversation history is one click away. ## The dashboard The Dashboard reads the same data and answers the owner questions: Dashboard with open pipeline, win rate, revenue by month and lost reasons * **Open pipeline** and its deal count * **Won** value and **win rate** for the selected period, with trend against the previous one * **Revenue won by month** across the last 12 months * **Pipeline by stage** and **lost reasons**, so you see where deals die ## Outreach analytics The **Outreach** tab covers the activity side. Each channel gets its own card showing how much went out and how it landed — calls answered and how many turned positive, WhatsApp messages replied to, emails opened — next to a live queue card that opens the full list of what is still waiting to send. Below that: sends per channel per day, your active triggers, and per-owner pipeline load. A rate only appears once there is something to report. A channel with sends but no measured outcome shows the send count alone rather than a zero, because "0% opened" and "we can't see opens yet" are not the same thing and should not look the same. Outreach analytics: a card per channel with volume and outcome rate, the send queue, and daily volume by channel # Web forms Source: https://docs.autonudge.dev/crm/forms Public lead forms that feed straight into automation Forms are how leads enter Nudge from your website. Each form gets a public URL you can link or embed; a submission creates a contact and, because that contact lands in a state your triggers watch, the follow-up starts immediately. Form filled at 9:02, AI call at 9:41. The forms list with submission counts and active status ## Building a form Pick fields from your [fields registry](/settings/workspace), so a form question writes straight into a real contact field with no mapping step. Toggle a form inactive to stop intake without deleting its history; submission counts and last-submission dates stay on the list. Point different forms at different offers ("Rooftop solar enquiry" vs "Free roof check") and use a form-specific field as a trigger condition to route each audience into its own workflow. # HubSpot mode Source: https://docs.autonudge.dev/crm/hubspot Keep HubSpot as the source of truth; let Nudge work it If your team already lives in HubSpot, you do not migrate. Nudge connects with a private app token and sits on top: HubSpot stays the record, Nudge does the outreach. ## What Nudge pulls Intake is derived from your automations. Nudge pulls exactly the contacts your **enabled triggers** care about, matched by their conditions and owner audiences, and keeps them fresh on a schedule you set. Enable a trigger and its audience starts flowing in; there is no separate import step to keep in sync. The fields Nudge reads are the ones in your [fields registry](/settings/workspace), so a HubSpot property becomes filterable, displayable and usable as a message variable the moment you register it. ## What Nudge writes back Every outcome goes home to HubSpot: * possibility/state changes, from manual edits, sends and call outcomes * sent messages and call results Writes go through a durable queue with retries and backoff. A HubSpot outage delays the sync; it does not lose it. If a write permanently fails, admins get a bell notification — and an email too, if they have turned that on for **Sync failed** in their [notification settings](/settings/users#notifications). ## Conflicts Edits made in Nudge win for a short grace window, so a rep's manual state change is not stomped by the next sync pulling slightly stale data. After that, HubSpot is the truth. ## Working in both Contact pages in Nudge show recent HubSpot notes read-only and link straight to the HubSpot record. A **Refresh** button pulls a single contact on demand when you need the freshest state right now. Standalone (native CRM) workspaces skip all of this: contacts, deals and forms live in Nudge and no HubSpot account is involved. # Standalone vs HubSpot Source: https://docs.autonudge.dev/crm/native-mode Nudge as your CRM, or Nudge on top of the one you have Every workspace runs in one of two modes, chosen at setup. Both give you the full outreach machine: contacts, triggers, templates, WhatsApp, calls, email, inbox, bulk actions. The difference is where contacts come from and who owns the record. ## Standalone Nudge is the CRM. Contacts live here, you create them by hand, through [web forms](/crm/forms), through the [API](/api/overview), or automatically when someone messages you. Notes, tasks, documents and [deals](/crm/deals) are all native. Pick this if you have no CRM, or you have one nobody actually opens. ## HubSpot mode HubSpot stays the system of record. Nudge pulls the contacts your triggers care about, works them, and writes results back: state changes, property updates, and a Note for every message sent. See [HubSpot sync](/crm/hubspot) for how the two-way sync behaves. Pick this if your team already lives in HubSpot and you want outreach on top rather than a migration. ## What differs | | Standalone | HubSpot mode | | --------------------------- | ------------------------------------ | ------------------------------------- | | Contacts come from | Forms, API, manual, inbound messages | The HubSpot sync | | Creating a contact in Nudge | Yes | No, create it in HubSpot | | [Web forms](/crm/forms) | Yes | Not available | | Notes, tasks, documents | Native, fully editable | Recent HubSpot notes, read-only | | [Deals](/crm/deals) | Native board | HubSpot owns your deals | | Bulk property actions | Yes | Not available | | Creating contacts via API | Yes | No, but reads, updates and sends work | Everything not in that table behaves identically. Triggers, templates, the inbox, calling and pacing do not care which mode you are in. Changing mode after setup is not a toggle, it is a migration. Decide during onboarding and we will set the workspace up accordingly. # FAQ Source: https://docs.autonudge.dev/faq Short answers to the questions everyone asks This is the risk Nudge is built around. Personal numbers are paced automatically: a gap between sends, hourly and daily caps, and working-hours gating. The pacing is what keeps a rep's line looking human, so keep broadcast-shaped traffic off it and shrink your segments instead. A Cloud API number carries conversations without that pacing, and with an approved template it can also send cold outreach outside Meta's 24-hour window. See [WhatsApp](/channels/whatsapp). Automation stops for that contact by default. Queued automated messages are cancelled and the conversation continues in the Inbox with a human. How long the pause lasts is a setting, and an individual trigger can opt out of it, which is what you want for something like a callback the contact asked for. No. A trigger fires once per contact, ever. Editing the trigger resets this deliberately, so a corrected message can reach the audience again. The one exception is a trigger that reacts to call outcomes: if the same contact calls or is called again after 30 quiet days, it treats that as a fresh conversation and the retry chain can run once more. That is what you want — someone who comes back months later should not be met with silence because a rule already fired in the spring. Nudge holds the message rather than send the wrong language. A template with no language tabs is treated as language-neutral and goes to everyone. No. Nudge runs standalone with its own contacts, deals and forms, or on top of your HubSpot with two-way sync. See [HubSpot mode](/crm/hubspot). Yes. Every contact page has a **Skip automations** toggle. A fictional solar installer with 200 fake contacts, live triggers, and simulated calls and messages. No real messages are sent, and everything resets nightly. Open it at [demo.nudgecrm.dev](https://demo.nudgecrm.dev). Request a demo at [autonudge.dev](https://autonudge.dev/#demo). Each customer gets a dedicated instance, set up for you, usually within days. # What is Nudge Source: https://docs.autonudge.dev/index A CRM that does the outreach itself: AI calls, WhatsApp and email, chained by your rules Nudge is a CRM built around one idea: most deals die from silence, not rejection. So the CRM itself does the following up. You define the rules once, and Nudge calls new leads with an AI voice agent, sends WhatsApp messages from your team's numbers, and emails what needs a paper trail. The moment a lead replies, automation stops and a human takes over. The Outreach view: a card per channel showing calls placed and answered, WhatsApp sent and replied to, emails sent and opened, plus what is queued to go out That view is the point of the product. Every number on it was produced by rules running on their own — calls placed, messages sent, replies that came back — not by anyone working a list. ## The pieces Every lead with its state, owner and last touch. The whole app runs off this list. Rules that read like sentences: new lead, call within the hour, WhatsApp on no answer. WhatsApp, AI voice calls and email, each used where it works best. A pipeline board and public lead forms, fed by the same contacts. Drive the whole workspace from your own code, or from an AI assistant. ## One state drives everything Every contact has a **possibility**: its state in your pipeline. New lead, Contacted, No answer, Qualified, Quote sent, Customer, whatever fits your process. Triggers watch these states. When a contact enters a state, the matching trigger fires; the outcome of that step (a call result, a sent message) moves the contact to the next state, which can arm the next trigger. That is how one-line rules chain into full workflows without a flowchart editor. ## Your CRM, or your HubSpot Nudge works standalone: contacts, deals and forms live in Nudge and nothing else is needed. If your team already runs on HubSpot, connect it instead. Nudge pulls the leads your automations need and writes every send, call and status change back, durably, with retries. See [standalone vs HubSpot](/crm/native-mode) for what differs between the two. ## See it live The fastest way to understand Nudge is the [live demo](https://demo.nudgecrm.dev): a fictional Tyrolean solar installer with 200 contacts, running triggers and simulated calls. No signup, resets nightly. The [quickstart](/quickstart) walks you through it. # Tour the demo Source: https://docs.autonudge.dev/quickstart Ten minutes in the live demo, no signup The demo at [demo.nudgecrm.dev](https://demo.nudgecrm.dev) is a fictional solar installer called Klarwatt with 200 contacts, four sales reps and live automations. Calls and messages are simulated, so click anything. The whole environment resets every night. Click **Contacts** in the sidebar. Each row shows the lead's possibility state, its owner, and the last touch: a call outcome in green or red, or the last WhatsApp message. Green REPLIED badges mark contacts who wrote back. Click any name. Left side: the contact's fields, deals and automation toggle. Right side: the full timeline, WhatsApp messages, call summaries and emails in one thread. Filter by channel with the icons top right. Click **Lead qualification**. Each row is one rule, and the workflow column reads left to right: the state that arms it, the actions it takes, the state it sets afterwards. Open "Qualification call + no-answer follow-up" to see conditions, actions and delays in the editor. Click **Inbox**. This is where replies land. The demo simulates incoming WhatsApp answers, so threads fill up during the day. **Deals** shows the pipeline board; **Outreach** gives each channel its own card — how much went out and how it landed (calls answered, WhatsApp replied to, emails opened) — plus what is still queued; **Dashboard** shows revenue won and lost reasons. ## Getting your own instance Nudge runs as a dedicated instance per company: your data, your numbers, your sending reputation, nothing shared. Setup is done for you, including number connections and HubSpot if you use it. Request a demo at [autonudge.dev](https://autonudge.dev/#demo) and we will get in touch within a day. # Billing Source: https://docs.autonudge.dev/settings/billing Your call usage, its cost, and a monthly budget with alerts **Settings → Billing** shows what your voice calls cost. Admins only — regular users never see it. ## How calls are priced Calls are billed **per second** at your workspace's per-minute rate. The price of each call is fixed the moment the call ends, so your bill is simply the sum of the calls in the list — a later rate change only affects future calls, and a past month's statement never moves. The rate itself is set by your account manager, not in the app. If no rate is configured, the page still tracks usage; the amounts just show zero. ## Reading the page The header shows the selected month: total spend so far, minutes called, and your rate. The months dropdown holds past statements — each one frozen, each one backed by the call list below it. Every billed call appears as its own line: when it happened, who it was with, whether it was inbound or outbound, how long it ran, and what it cost. Short calls that didn't connect cost almost nothing on their own — a few seconds is a fraction of a cent. Inbound and outbound calls both bill: talk time is talk time, whichever side dialed. ## Monthly budget and alerts Set an optional **monthly budget** on the page. When a month's call spend passes **80%** and then **100%** of it, every admin gets a notification, and an email too if email alerts are switched on in your profile. The budget never stops calls. It is an early warning, not a cap — automation keeps running, inbound keeps answering, and the alert is your cue to look. Each threshold fires at most once per month. # Language Source: https://docs.autonudge.dev/settings/language Reading the app in English, German or Turkish Nudge speaks English, German and Turkish. The choice is yours alone — it changes what *you* see, and nobody else's screen moves. ## Switching Go to **Settings**, where your own profile sits at the top: email, role, your name, and **Language**. Pick one from the dropdown and the app changes immediately — no reload, no save button. It follows your account, not your browser, so signing in on a laptop and a phone gives you the same language on both. And it is yours alone: changing it moves nothing on a colleague's screen. ## What changes, and what deliberately does not The app's own words change: menus, buttons, column headings, the tips behind the ⓘ icons, confirmation dialogs, empty states. Dates and numbers change with them — a German reading gets `65.510`, an English one `65,510`. **Your own data stays exactly as you wrote it.** Contact names, message bodies, template text, trigger names, your pipeline stages, and the labels on your contact fields are yours. Nudge never rewrites them, in any language. That last one has a visible consequence worth knowing about. Contact field labels come from your own field setup, so if your workspace was set up in English, a colleague reading the app in German still sees **First name** on a contact card while the Add-contact form beside it says **Vorname**. The form is our word; the card is yours. If you want both in German, rename the fields in **Workspace setup** — and then they read German for everyone, including your English-speaking colleagues, which is the trade. A few technical terms stay in English on purpose: WABA, Cloud API, E.164, access token, API key, and the names of the services Nudge connects to. Those are the words printed in the consoles you would go and look at, so translating them would leave you searching for something that isn't there. ## What people receive is a separate setting Interface language and message language are two different things, and mixing them up is the easy mistake to make here. * **Language** (this page) decides what *you* read inside Nudge. * **A contact's language** decides which version of a template *they* receive. It comes from the owner assigned to that contact, and it is set in **Contact owners**. So you can read the app in German while your Turkish colleague reads it in Turkish, and both of you send the same contact the same Turkish message. Changing your own language never changes a single thing that goes out. ## Still in English Two screens do not follow the setting, because they appear before you are signed in and Nudge does not yet know who you are: the **sign-in page** and the message you get if a web address isn't linked to a workspace. Emails and bell notifications Nudge sends you — a sync failure, a budget alert, a task reminder — are also still English for now. ## Something reading oddly? The translations are ours, not a machine's, but three languages across a whole CRM leaves room for a clumsy phrase. Tell us through **Help & feedback** in the same menu as the language picker, and say which screen it was on — we fix wording in place, and it reaches you on the next update. # Users and roles Source: https://docs.autonudge.dev/settings/users Who can sign in, and what they can change Nudge is invite-only. An address nobody invited cannot sign in, however valid its Google account is. Manage everyone from **Settings → Users**. ## Inviting someone **Add user** takes an email address and sends the invite. Until they sign in for the first time they sit in a **Pending invites** list, where you can revoke the invite if you sent it to the wrong place. Revoking an invite has no effect on anyone who already has an account. ## The two roles * **Member** works leads. Contacts, inbox, calls, messages, deals: everything the daily job needs. They cannot change settings, edit triggers, or manage people. * **Admin** does all of that plus configuration: triggers, templates, fields, connections, API keys, and inviting or removing users. Give reps Member. Keep Admin for the one or two people who actually own the setup, because an admin can change automation that messages your entire database. Two guard rails you will run into by design: you cannot change your own role, and you cannot remove the last remaining admin — neither by demoting them nor by revoking their access. A workspace with no admin has no way back in. ## Approving and removing access Users you have invited show a status. You approve, reject, deactivate or reactivate from the same table. Deactivating is the one to reach for when someone leaves: it cuts their access immediately while their history stays intact. Nobody is ever deleted, and that is deliberate. Everything a person did — the messages they sent, the notes they wrote, the changes they made — stays attributed to them. Instead, revoked people drop out of the list behind a **Show N revoked** link at the bottom, and searching by name still finds them. Reactivating brings someone back exactly as they were. If a status was set with a reason, hover the status to read it, along with who set it and when. ## Who sends what (standalone) On a standalone workspace everyone in this table is also a **contact owner** — leads get assigned to them, and there is no separate owners list to keep in step. Each row carries their send setup: * **WhatsApp number**, the line their messages send from * **Language**, which decides which template version their contacts receive * **Working hours**, which gate when their contacts get contacted (click the hours to set days, times and timezone) A row marked **No login** owns contacts but has no account — you can still set its send config, or invite the address to give them access. Contacts nobody owns appear as a **No owner** count at the bottom; automation skips them until someone owns them. HubSpot workspaces keep a separate **Contact owners** page instead, because owners come from HubSpot's own directory and may not have a Nudge login at all. ## Notifications Each user chooses what they want to hear about, in-app through the bell or by email, per event. They sit in one table in **Settings**, under your own profile. Six are about your contacts: a new contact arrives, a contact replies, a call completes, a status changes, a document is received, or a task falls due. Task reminders always go only to the person who set the task. Three are about the workspace itself, and all start with the bell already on because they are the ones you would want to hear about unprompted: **Sync failed** when a HubSpot lead pull breaks, **Call budget** when call spend passes 80% and then 100% of the monthly budget, and **Template category changed** when Meta files a WhatsApp template under a different category than the one it was submitted as (usually Utility approved as Marketing, which costs more per message). Sync alerts are throttled to one an hour, so a failure repeating every minute cannot flood you. # Workspace setup Source: https://docs.autonudge.dev/settings/workspace Fields, owners, numbers, agents and connections Admin surfaces live under **Workspace setup** and **Settings**, which splits into sub-tabs: General, WhatsApp, Voice agent, Emails, [Users](/settings/users), [API](/api/overview) and [Billing](/settings/billing). Standalone workspaces also get a Forms entry; HubSpot workspaces get a **Contact owners** entry. ## Fields registry (Workspace setup) The registry defines what a contact IS in your workspace: which fields exist, their labels, their type, and their list options. Everything else derives from it: table columns, contact-page fields, form questions, trigger conditions and message variables. Every field is a message variable: open the variable picker in any template and the field is there under its label, with the `[token]` to type beside it. The **Used in triggers** column names the triggers that read or write each field, so you can see what a field is for and what would stop working without it; removing such a field asks you to confirm and lists them. In a standalone workspace, **Used in agents** names the voice agents that collect each field. Fields with a **Voice** badge are an agent's own variables, mirrored here so triggers can use them: rename or remove them on the agent's page, not here. An archived agent's variables don't appear. Trigger categories are managed here too; each category becomes a sidebar tab. ### Who fills a field (standalone) In a standalone workspace a field is written by people unless a voice agent saves its answer there. That is decided on each agent's page, in the **Contact field** column of its variables: a green check means this agent's answer is saved on the field, and clicking the mark turns it on or off for that agent. It is not set here. See [what the agent collects](/channels/calls#what-the-agent-collects). The permission is a guard, not a note to yourself. A call that goes to voicemail still produces a full analysis, filled with the agent's best guesses, so a field no agent saves to stays untouchable no matter what came back from the call. Core fields (name, email) are always saved; the phone number never is. ## Contact owners Owners are your reps, the people leads are assigned to. Per owner you set: * **Working hours**, which gate automated WhatsApp sends for their contacts * **WhatsApp number**, the personal line their messages send from * **Default calling agent**, so calls to their leads use the right voice and number * **Language**, which drives template language matching for their audience **Where you set it depends on your mode.** Standalone workspaces have no separate owners page: everyone who can sign in is an owner, so their send setup lives on their row in [Settings → Users](/settings/users). HubSpot workspaces get a dedicated **Contact owners** entry in the sidebar, because owners come from HubSpot's owner directory. They are not Nudge logins, and some of them will never have an account here. The contact owners table with working hours and default calling agents ## Numbers and agents Each channel owns its accounts. **Settings → WhatsApp** holds your phone numbers with their connection type (personal or Cloud API) and the pacing controls described in [WhatsApp](/channels/whatsapp). **Settings → Voice agent** holds your AI calling agents: voice, script, calling hours and pinned outbound number. **Settings → Emails** holds sending addresses and signatures. ## Connections and alerts Credentials live in **Settings → Connections**: WhatsApp connections, the HubSpot token, and the rest. Secrets are write-only, so once saved you see that a value is set and its last few characters, never the value itself. A value tagged **managed** was set for your workspace by Nudge and is kept up to date for you. You can still replace it with your own, which stops Nudge updating that field. Connecting an **OpenAI** or **Anthropic** key is optional. OpenAI unlocks the writing help in Nudge, such as suggesting a note for a trigger; either one can power the [WhatsApp assistant](/channels/assistant). Both have a model field, and both offer a list read from your own key, so you are only shown models that key can actually use. Leave a model blank and the field shows the one that will run instead. Sync failures reach admins as a notification — bell by default, email if you turn it on. It is one row in the notifications table like any other event; every user picks their own, per event and per channel. See [Users and roles](/settings/users). Theming is here too: light, dark, or automatic by local sunrise and sunset. ## API keys **Settings → API** mints keys for the [REST API](/api/overview) and shows the last 100 API requests with their status and errors. Nudge autosaves everywhere. If you are looking for a Save button, the change is already saved; watch for the brief "Saved" indicator.