您的Telegram体验应该从何处开始？
从用户需要完成的一个任务开始。这个选择有助于我们设计机器人对话或TON迷你应用界面。机器人适合引导式交互或可重复的任务。迷你应用适合需要屏幕和控件的操作。
我们使用以下5步流程来规划首次发布：
- 明确用户。 确定谁会打开这个体验以及他们已知什么。
- 描述任务。 用日常语言写下他们应该完成的操作。
- 绘制路径。 记录每个问题、屏幕、确认和可能的转交。
- 检查连接。 列出每个步骤所需的API、钱包或产品服务。
- 设定终点。 商定我们将测试什么以及谁批准用户旅程。
例如，一个交易团队可能希望用户在采取行动前查看信息。我们会规划界面显示什么以及哪个服务支持该操作。我们还会确定用户在哪里确认。如果该体验属于一个更大的去中心化产品，它可以与dApp开发一起规划。这使Telegram旅程与产品保持连接，也避免让聊天承担所有工作。
让首次交流对您的社区显得清晰
社区机器人在处理特定、可重复的需求时效果最佳。它还需要知道何时应由人工介入。我们在实施之前规划其欢迎语、回答、版主控制和人工转交。
设想一位拥有少量粉丝的NFT艺术家，为其社区添加一种新的市场语言。新成员可能会带着他们从未见过的术语问题到来。我们可以设计一个3步欢迎流程。首先，介绍新语言。接着，指向正确的项目信息。最后，在问题需要谨慎处理时提供联系版主的途径。这是一个假设的例子，并非关于成员如何回应的承诺。
对于社区工作流，我们可以定义常规回答、审核操作以及工作人员需要看到的信息。当产品需要比聊天流程更复杂的功能时，TON迷你应用可以为成员提供交互式任务的屏幕。当用户旅程依赖于链上操作时，我们还可以协调体验与智能合约开发。
在开始之前，请准备好已批准的答案、升级联系人和工作人员权限。一位能够确认这些选择的指定人员有助于我们保持审核的聚焦。
您的团队可以跟进的交接文档
您将获得一个可运行的Telegram体验、针对约定用户路径的检查，以及帮助您的团队运营的说明。具体内容取决于我们在开发开始前商定的功能和连接。
| 您获得的内容 | 何时有帮助 |
|---|---|
| 包含角色和错误路径的用户流程说明 | 在构建之前，以便每个人都能检查预期行为 |
| Telegram机器人或TON迷你应用界面 | 一旦用户旅程和所需操作达成一致 |
| 约定的API、钱包或产品连接 | 当文档和访问权限可用时 |
| 支持路径的测试说明 | 在审核期间，包括相关的边界情况 |
| 操作说明和交接材料 | 当您的团队准备管理该体验时 |
对于连接钱包的迷你应用，我们首先明确网络、连接步骤和用户确认。当钱包体验也需要开发时，我们可以与crypto钱包开发协调该工作。您的团队可以通过分享测试访问权限和集成说明来简化审核。还请指定一位能够确认产品行为的人员。
我们在交接前一起检查约定的旅程。这意味着查看预期结果和可理解的错误状态。我们还会检查计划中设定的工作人员控制。
Telegram体验的哪些部分不受您的团队控制？
一个合理的构建计划将您的产品决策与Telegram和连接服务控制的行为分开。这使我们能够就我们可以实施和测试的工作达成一致。
Telegram控制其客户端体验和平台访问。连接的钱包提供商和API控制它们自己的可用性。我们可以测试和交接约定的流程，但无法保证Telegram的发现性、不间断的访问或第三方响应。
在开发之前，请检查每个用户操作背后是否有一个指定的服务。否则，为该操作不可用时定义一个清晰的响应。明确谁拥有API凭证和平台配置。对于交易操作，定义界面显示什么以及哪些步骤需要用户确认。如果涉及智能合约，请保持其职责与Telegram界面分开。确认谁审核每个部分。
假设一个迷你应用在显示屏幕之前需要来自外部服务的信息。我们会记录该依赖关系，并决定如果信息缺失用户会看到什么。我们会将该路径纳入测试。这为您的团队提供了一个实际的审核点。它不会将外部服务视为界面可以控制的东西。
提供使首次发布可行的产品细节
一个有用的启动会给我们足够的细节来规划一个用户旅程。它还能让我们检查其连接并商定团队如何审核。简短的需求文档即可。清晰的职责比完善的文档更重要。
请准备：
- 用户群体以及他们需要完成的任务。
- 任何现有的屏幕、命令、产品流程或已批准的内容。
- API、钱包或服务文档，以及联系管理访问权限的人员的途径。
- 产品行为的决策者以及将测试构建的人员。
我们可以使用2个审核点来保持决策的可见性。第一个在实施前覆盖规划的流程。第二个检查工作体验是否符合该流程。如果Telegram工具是更广泛产品的一部分，Web3开发可以帮助构建其各部分如何配合。对于Telegram之前或之后的网页步骤，我们还可以将旅程与Web3网站和落地页开发对齐。
将您的产品需求文档、主要用户任务和任何技术说明分享给Brand Community。我们将审核依赖关系并澄清未决的选择。然后我们会带着构建计划回来；从关于您项目的对话开始。
如何操作
- 分享用户任务告诉我们谁将使用Telegram体验以及他们需要做什么。包括任何现有的产品流程或技术说明。
- 审核连接我们检查API和钱包需求、访问途径以及谁可以批准产品决策。
- 商定首次发布我们记录用户路径、界面行为、包含的功能以及团队将如何审核构建。
- 构建与审核我们实施约定的体验，并与您的团队对照规划的用户旅程进行检查。
- 测试与交接我们审核支持路径，记录操作说明，并将约定的材料移交给您的团队。
常见问题
如何在Telegram机器人和TON迷你应用之间做选择？
选择Telegram机器人用于引导式交互或可重复的社区任务。当用户需要屏幕、控件或几个连续操作时，TON迷你应用是更好的选择。例如，常规欢迎可以是对话，而带有钱包步骤的产品流程可能需要迷你应用。我们可以在推荐格式之前规划用户旅程。
Telegram界面能否融入加密货币交易工作流？
可以，我们可以围绕定义的操作和支持它们的产品服务构建界面。需求文档应指明网络、API、用户权限和确认步骤。例如，我们可以规划用户在操作前看到什么以及哪个服务处理它。界面计划与产品底层安全模型保持分离。
社区应该为欢迎机器人准备什么？
准备欢迎文本、已批准的答案、工作人员权限以及用于需要人工处理的问题的版主联系人。一个简单的3步欢迎流程可以帮助我们明确新成员首先看到什么，接下来是什么信息，以及何时提供转交。我们还可以审核哪些常规请求适合自动化工具。
TON钱包连接在界面工作之前需要什么？
我们需要预期的网络、钱包连接要求以及用户应采取的操作的清晰说明。如果您有钱包或合约文档，请与负责该集成的人员分享。然后我们在实施相关界面之前映射连接、确认和错误状态。
您如何设定交付时间？
我们在审核用户路径、集成访问和决策流程后设定时间。具有一个约定旅程和可用文档的首次发布比存在未解决的产品选择或几个新连接的发布更容易规划。计划在实施开始前设定构建顺序和审核点。
您能保证我们的迷你应用在Telegram内被发现吗？
不能。Telegram控制平台访问及其客户端体验，而连接的服务控制它们自己的可用性。我们可以交付和测试约定的迷你应用流程，记录依赖关系并提供交接说明。我们无法保证发现性、不间断的访问或来自钱包提供商或API的特定响应。
告诉我们您的项目
回答四个简单问题，经理会在1小时内为您发送方案、时间表和价格范围。全程保密。
正在加载表单…