sales-qwilr-automation

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Automate Qwilr with CRM & Tools

实现Qwilr与CRM及工具的自动化集成

Help the user build automations that connect Qwilr to their CRM and other tools — via the Qwilr REST API, Zapier, or native integrations.

帮助用户构建Qwilr与CRM及其他工具的自动化集成——可通过Qwilr REST API、Zapier或原生集成实现。

Qwilr API overview

Qwilr API 概述

The Qwilr REST API lets you create pages from saved blocks with token substitutions, manage quote sections with interactive pricing, and subscribe to webhooks for real-time engagement signals.

Quick reference: Base URL

https://api.qwilr.com/v1

, JWT Bearer auth. Key endpoints:

POST /pages

(create),

GET /blocks/saved

(discover templates),

POST /webhooks

(subscribe to events).

For the complete API reference — endpoints, curl examples, token mapping, quote block structure, and testing checklist — consult

references/qwilr-api-reference.md

Qwilr REST API支持通过已保存区块结合令牌替换创建页面、管理带交互式定价的报价板块，以及订阅Webhook以获取实时互动信号。

快速参考：基础URL

https://api.qwilr.com/v1

，采用JWT Bearer认证。核心端点：

POST /pages

（创建页面）、

GET /blocks/saved

（发现模板）、

POST /webhooks

（订阅事件）。

如需完整的API参考（包括端点、curl示例、令牌映射、报价区块结构及测试清单），请查阅

references/qwilr-api-reference.md

。

Step 1 — Gather context

步骤1 — 收集上下文信息

Ask the user:

What do you want to automate?
- A) Auto-create proposals when a deal reaches a certain stage
- B) Sync proposal status/acceptance back to CRM
- C) Get notified when prospects view or accept proposals
- D) Full round-trip: create from CRM data + sync engagement back
- E) Something else — describe it
What CRM/tools are you using?
- A) HubSpot
- B) Salesforce
- C) Pipedrive
- D) Zoho CRM
- E) Other CRM (specify)
- F) No CRM — just API/webhooks
What automation platform do you prefer?
- A) Zapier
- B) Make (Integromat)
- C) Direct API (code/scripts)
- D) Native Qwilr integration (HubSpot/Salesforce/Pipedrive)
- E) Not sure — recommend what fits
What Qwilr plan are you on? (affects API access and native integrations)

If the user's request already provides most of this context, skip directly to the relevant step. Lead with your best-effort answer using reasonable assumptions (stated explicitly), then ask only the most critical 1-2 clarifying questions at the end — don't gate your response behind gathering complete context.

询问用户以下问题：

你想要实现什么自动化需求？
- A) 当交易进入特定阶段时自动创建提案
- B) 将提案状态/接受情况同步回CRM
- C) 当潜在客户查看或接受提案时收到通知
- D) 完整闭环：从CRM数据创建提案 + 同步互动数据回CRM
- E) 其他需求——请描述
你正在使用哪些CRM/工具？
- A) HubSpot
- B) Salesforce
- C) Pipedrive
- D) Zoho CRM
- E) 其他CRM（请说明）
- F) 未使用CRM——仅需API/Webhook
你偏好哪种自动化平台？
- A) Zapier
- B) Make（Integromat）
- C) 直接调用API（代码/脚本）
- D) Qwilr原生集成（HubSpot/Salesforce/Pipedrive）
- E) 不确定——请推荐合适的方案
你使用的是Qwilr哪个套餐？（会影响API访问权限和原生集成功能）

如果用户的请求已提供大部分上述信息，可直接跳至对应步骤。 先基于合理假设给出初步方案（需明确说明假设内容），最后仅询问1-2个最关键的澄清问题——不要要求用户提供全部信息后才给出回应。

Step 2 — Architecture recommendation

步骤2 — 架构方案推荐

Based on the user's answers, recommend the right approach with trade-offs:

根据用户的回答，推荐合适的实现方案并说明利弊：

Native integrations (simplest)

原生集成（最简单）

HubSpot: Qwilr's native integration auto-populates templates with HubSpot deal/contact data, syncs acceptance status back to deal properties
Salesforce: Native integration maps Salesforce opportunity fields to Qwilr tokens, creates proposals from opportunity records
Pipedrive: Native integration connects deal data to Qwilr templates
Best for: Teams that want zero-code setup and use a supported CRM
Limitation: Less customizable than API, limited to supported field mappings

HubSpot：Qwilr的原生集成可自动用HubSpot交易/联系人数据填充模板，并将接受状态同步回交易属性
Salesforce：原生集成可将Salesforce商机字段映射到Qwilr令牌，从商机记录创建提案
Pipedrive：原生集成可将交易数据与Qwilr模板关联
适用场景：希望零代码搭建、且使用支持的CRM的团队
局限性：自定义程度低于API，仅支持预设的字段映射

Zapier / Make (medium complexity)

Zapier / Make（中等复杂度）

Best for: Multi-tool workflows (e.g., create proposal when Stripe payment received, or notify Slack when proposal viewed)
Approach: Use Qwilr's Zapier triggers (page viewed, accepted) and actions (create page)
Limitation: Slower execution, may hit rate limits at scale, costs per task

适用场景：多工具联动工作流（例如，收到Stripe付款时创建提案，或当提案被查看时发送Slack通知）
实现方式：使用Qwilr的Zapier触发器（页面被查看、被接受）和操作（创建页面）
局限性：执行速度较慢，大规模使用时可能触发速率限制，按任务量收费

Direct API (most powerful)

直接调用API（功能最强大）

Best for: Custom workflows, high volume, complex logic (conditional sections, dynamic pricing calculations)
Approach: Call Qwilr REST API directly from your backend, serverless functions, or scripts
Limitation: Requires development effort

适用场景：自定义工作流、高交易量、复杂逻辑（条件板块、动态定价计算）
实现方式：从后端、无服务器函数或脚本直接调用Qwilr REST API
局限性：需要开发投入

Step 3 — Build the automation

步骤3 — 搭建自动化流程

The build process follows four stages. For curl examples, JSON payloads, and token mapping details, consult

references/qwilr-api-reference.md

搭建流程分为四个阶段。如需curl示例、JSON请求体及令牌映射详情，请查阅

references/qwilr-api-reference.md

。

3a. Discover available blocks

3a. 发现可用区块

List saved blocks via

GET /blocks/saved

to find the

savedBlockId

values for page creation.

通过

GET /blocks/saved

列出已保存区块，获取用于创建页面的

savedBlockId

值。

3b. Create pages from CRM data

3b. 从CRM数据创建页面

Use

POST /pages

with saved block IDs, token substitutions (CRM fields →

{{token}}

values), and quote sections for interactive pricing.

使用

POST /pages

接口，传入已保存区块ID、令牌替换（CRM字段 →

{{token}}

值），以及带交互式定价的报价板块。

3c. Subscribe to webhook events

3c. 订阅Webhook事件

Subscribe to

pageFirstViewed

pageViewed

pageAccepted

, and

pagePartiallyAccepted

events to get real-time engagement signals.

pageFirstViewed

、

pageViewed

、

pageAccepted

和

pagePartiallyAccepted

事件，以获取实时互动信号。

3d. Check page status

3d. 检查页面状态

Use

GET /pages/{id}?expand=acceptance,metadata

to poll page details and acceptance status.

使用

GET /pages/{id}?expand=acceptance,metadata

接口轮询页面详情和接受状态。

Step 4 — Token/substitution mapping

步骤4 — 令牌/替换映射

Design the mapping between CRM fields and Qwilr template tokens. Common tokens include

{{company_name}}

{{contact_first_name}}

{{deal_amount}}

{{rep_name}}

, etc. For the full token reference and guidelines, see

references/qwilr-api-reference.md

Key principles:

Always auto-populate: company_name, contact names, rep info, deal amount
Semi-auto (verify after population): industry, company_size, product
Always manual: executive summary, pain points, custom scope
Set fallback values for optional tokens so pages don't show raw
```
{{token}}
```
text

设计CRM字段与Qwilr模板令牌的映射关系。常见令牌包括

{{company_name}}

、

{{contact_first_name}}

、

{{deal_amount}}

、

{{rep_name}}

等。如需完整的令牌参考及指南，请查看

references/qwilr-api-reference.md

。

核心原则：

始终自动填充：company_name、联系人姓名、销售代表信息、交易金额
半自动填充（填充后需验证）：行业、公司规模、产品
始终手动填写：执行摘要、痛点、自定义范围
为可选令牌设置默认值，避免页面显示原始
```
{{token}}
```
文本

Step 5 — Testing checklist

步骤5 — 测试清单

Walk through end-to-end before going live: auth verification, block discovery, token rendering, quote block accuracy, webhook delivery, CRM sync, error handling, and publish flow. Full checklist in

references/qwilr-api-reference.md

上线前需完成端到端测试：认证验证、区块发现、令牌渲染、报价区块准确性、Webhook投递、CRM同步、错误处理及发布流程。完整清单请见

references/qwilr-api-reference.md

。

Common automation recipes

常见自动化场景

Three common patterns (detailed implementation in

references/qwilr-api-reference.md

Auto-create proposal when deal hits Stage 3: CRM trigger →
```
POST /pages
```
→ update CRM with Qwilr URL
Notify Slack when proposal is viewed:
```
pageFirstViewed
```
webhook → Slack message → rep follows up
Update CRM when proposal is accepted:
```
pageAccepted
```
webhook → update deal stage to Closed Won → trigger onboarding

三种常见模式（详细实现请见

references/qwilr-api-reference.md

）：

当交易进入阶段3时自动创建提案：CRM触发 → 调用
```
POST /pages
```
→ 将Qwilr链接更新至CRM
当提案被查看时通知Slack：
```
pageFirstViewed
```
Webhook → 发送Slack消息 → 销售代表跟进
当提案被接受时更新CRM：
```
pageAccepted
```
Webhook → 将交易阶段更新为“已成交” → 触发入职流程

Gotchas

注意事项

Don't overcomplicate with custom API when Zapier works. If the user's automation is a simple trigger-action (deal hits stage → create proposal), Zapier or the native integration is faster to set up and maintain. Reserve direct API work for custom logic, high volume, or complex conditional workflows.
Don't forget webhook retry and deduplication. Qwilr webhooks may retry on failure, sending the same event multiple times. Any webhook handler must be idempotent — check for duplicate event IDs before processing. Claude often generates webhook handlers without this.
Don't assume CRM field names without checking. Salesforce custom fields end in
```
__c
```
, HubSpot uses internal property names that differ from display names, and Pipedrive uses custom field keys. Always tell the user to verify their actual field names/IDs before building the mapping.
Don't skip testing with sandbox/test data. Claude tends to generate API code that goes straight to production. Always recommend creating test pages with
```
isPublished: false
```
first, using test deals in the CRM, and verifying token substitutions render correctly before going live.
Don't hardcode API tokens in scripts. Use environment variables (
```
$QWILR_TOKEN
```
) for authentication. Claude sometimes generates examples with placeholder tokens inline — make sure the user knows to use env vars or a secrets manager.

当Zapier可满足需求时，无需过度依赖自定义API。如果用户的自动化需求是简单的触发-动作（交易进入特定阶段 → 创建提案），Zapier或原生集成的搭建和维护效率更高。仅在需要自定义逻辑、高交易量或复杂条件工作流时，才使用直接API调用。
不要忘记Webhook的重试和去重机制。Qwilr Webhook在失败时可能会重试，导致同一事件被多次发送。任何Webhook处理程序必须具备幂等性——处理前需检查重复事件ID。Claude生成的Webhook处理程序通常会遗漏这一点。
不要未验证就假设CRM字段名称。Salesforce自定义字段以
```
__c
```
结尾，HubSpot使用与显示名称不同的内部属性名，Pipedrive使用自定义字段键。务必告知用户在构建映射前验证实际的字段名称/ID。
不要跳过沙箱/测试数据测试。Claude生成的API代码通常直接面向生产环境。务必建议用户先使用
```
isPublished: false
```
创建测试页面，使用CRM中的测试交易，验证令牌替换显示正确后再上线。
不要在脚本中硬编码API令牌。使用环境变量（
```
$QWILR_TOKEN
```
）进行认证。Claude有时会生成包含占位符令牌的示例——需确保用户知晓应使用环境变量或密钥管理器存储令牌。