快速入门指南生成

订阅管理后台快速入门指南

1. 文档目的与适用读者
本指南帮助新用户在最短时间内完成订阅管理后台的基础配置与首个订阅收款，从零到上线可运行。适用于：
- 系统管理员（配置权限、环境与安全）
- 财务/运营（税务、发票、对账策略）
- 产品/增长（产品与价格建模、试用与优惠）
- 开发与集成（Webhook、API 接入）

2. 前提条件
在开始前，确保具备以下条件与资料：
- 访问权限：管理员账号（能访问“设置”“计费”“开发者/集成”模块）
- 环境准备：沙盒与生产环境的区分策略、切换流程
- 业务策略：
  - 货币与汇率策略（单币种/多币种）
  - 税区覆盖与税务规则（如增值税、消费税、GST 等；是否反向计税）
  - 发票抬头、编号规则、出具与发送方式
  - 试用与优惠策略（是否需要信用卡开始试用）
  - 计费策略（预付/后付、按比例计费、账单日对齐）
  - 失败重试与停用策略（Dunning）
- 支付渠道：至少一种支付服务开通并可用（例：信用卡、转账、钱包；准备好网关商户号与密钥）
- 邮件发送：发信域名与认证（SPF/DKIM）准备（如需发送发票与支付通知）

3. 核心概念
- 客户（Customer）：订阅的主体，可包含联系人、地址、税号、默认支付方式。
- 产品（Product）：售卖对象的抽象，不含价格。
- 价格/方案（Plan/Price）：对产品的具体计费定义（周期、货币、金额、计量方式）。
- 订阅（Subscription）：客户在某时刻对某产品价格的激活关系，包含生命周期与账单节奏。
- 账单周期（Billing Cycle）：生成发票与收款的时间节奏（如每月/每年，账单日）。
- 发票（Invoice）：对一次或一周期计费的账单凭证，含税费、折扣、应收与状态。
- 支付方式（Payment Method）：客户用于支付的方式（卡、银行账户、钱包等）。
- 试用（Trial）：订阅开始前或初期免计费期。
- 折扣/优惠（Coupon/Promotion）：对价格的减免策略（一次性或周期性）。
- 税率（Tax Rate）：按区域适用的税百分比及计算方式（含税/不含税）。
- 失败重试（Dunning）：支付失败后的自动重试与通知策略。
- Webhook：将订阅事件推送到你方系统的回调机制（如 invoice.paid、payment.failed）。

4. 快速入门路径总览
- 步骤1：创建组织与权限
- 步骤2：基础配置（公司信息、货币、税务、发票）
- 步骤3：连接支付渠道与收款验证
- 步骤4：建模产品与价格
- 步骤5：创建客户与支付方式
- 步骤6：创建订阅、生成发票与收款
- 步骤7：通知模板、Webhook 与系统集成
- 步骤8：测试与上线切换

5. 详细步骤与验收标准

步骤1：组织与权限
- 操作要点
  - 创建或确认组织资料（法定名称、注册地址、税号）
  - 新增角色与权限策略（最小权限原则；区分管理员、运营、财务、只读）
  - 启用 SSO/MFA（如可用）提升后台访问安全
- 验收标准
  - 指定团队成员能按职责访问相应模块
  - 管理员可查看审计日志（登录、配置变更）

步骤2：基础配置（公司、货币、税务、发票）
- 操作要点
  - 公司信息：名称、Logo、客服邮箱、账单联系邮箱
  - 货币：启用目标币种；确认默认币种；明确跨币种换算策略（如仅展示，不自动换算）
  - 税务：按销售区域配置税率（含税/不含税）、反向计税规则、是否根据客户地址自动判定税率
  - 发票：编号规则（前缀、流水长度）、抬头与页脚、显示税号、账单条款
  - 邮件设置：发票、收款、失败重试通知的发件人、Reply-To；配置发信域名认证
- 验收标准
  - 新建发票预览显示正确抬头、编号格式与税额
  - 不同区域客户能获得正确税率计算

步骤3：连接支付渠道
- 操作要点
  - 在“设置 > 支付渠道”（具体导航以实际系统为准）新增渠道
  - 填写并验证商户号、API Key、证书或公私钥
  - 启用支持的支付方式（信用卡/借记卡、银行转账、电子钱包等）
  - 配置回调/通知 URL（用于支付状态回传）
  - 开启测试模式并完成一次小额测试支付
- 验收标准
  - 能在沙盒完成从发票到支付成功的闭环
  - 收到并记录支付网关回调，发票状态自动更新为已支付

步骤4：建模产品与价格
- 操作要点
  - 创建产品：名称、描述、可售卖区域
  - 创建价格/方案：
    - 周期：月度、年度、按用量（如按量计费需定义计量单位与聚合周期）
    - 金额与货币：多币种需逐一设定
    - 试用期：天数与是否需支付方式
    - 计费策略：预付/后付、账单日对齐、按比例计费（升级/降级时是否按比例计算）
  - 可选：创建优惠券/折扣（百分比或固定额；使用次数限制；生效范围）
- 验收标准
  - 价格在订阅创建界面可见且可选择
  - 试用与折扣规则在发票预览中正确呈现

步骤5：创建客户与支付方式
- 操作要点
  - 新建客户：名称、联系人、账单地址、送货地址（如适用）、税号
  - 添加默认支付方式：发起支付方式绑定流程（托管表单或后台录入，遵守合规要求）
  - 设置账单与通信偏好（发票语言、抄送邮箱）
- 验收标准
  - 客户详情页显示默认支付方式且状态有效
  - 发票发送至期望的邮箱地址并成功送达

步骤6：创建订阅、生成发票与收款
- 操作要点
  - 选择客户与价格方案，设置开始日期、账单周期锚点、试用期
  - 确认税务与优惠是否正确应用
  - 生成发票，触发支付或等待自动扣款
  - 校验发票状态变化（已开票 → 已支付/已部分支付/失败）
- 验收标准
  - 订阅状态为激活（或试用中），下次账单日期正确
  - 发票金额、税额、折扣精确无误；支付成功后状态同步

步骤7：通知模板、Webhook 与对接
- 操作要点
  - 配置邮件模板：发票开出、支付成功、支付失败、订阅即将续费/到期
  - 设置 Webhook：订阅、发票、支付相关事件；校验签名验证机制
  - 对接内部系统：CRM/工单/数据仓库（如通过 Webhook + API）
  - 配置失败重试策略（间隔、次数、最终动作：暂停/取消订阅）
- 验收标准
  - 模拟事件可触发通知并被正确接收
  - 网络异常下具备重试与幂等处理

步骤8：测试与上线
- 操作要点
  - 覆盖关键用例的端到端测试（见下文测试清单）
  - 完成上线清单：关闭测试模式、切换真实密钥、通知与税务规则最终校验、权限最小化
  - 创建首批真实订阅，监控关键指标与告警
- 验收标准
  - 所有测试用例通过；无数据不一致或计税异常
  - 监控面板显示正常，事件与日志完整

6. 常见操作速查

升级/降级订阅
- 即时生效：按比例计算当期差额（启用按比例计费时），生成调整行项目或贷记/补收
- 到期生效：在下个账单周期切换，无当期差额
- 验证：变更后下次账单金额符合预期；发票或调整凭证正确记录

暂停与恢复
- 暂停动作：停止生成新发票，保留订阅与权益状态规则依据业务设定
- 恢复动作：恢复账单生成，必要时对齐账单日
- 验证：状态流转与通知正确触发

取消与退款
- 取消时点：立即取消或到期取消
- 退款处理：通过原路退回或生成信用凭证后抵扣
- 验证：退款金额、税额与手续费规则符合财务策略，相关发票状态更新

支付失败处理
- 手动重试：在发票页触发
- 自动重试：按 Dunning 策略执行，并发送提醒
- 验证：失败原因记录、重试时间表与最终动作清晰

发票与对账
- 重发发票：支持邮件重发与PDF下载
- 会计导出：周期性导出发票明细、税额、收款记录
- 验证：账实相符，跨系统金额一致

数据导入
- 客户/订阅导入：使用 CSV 模板或 API
- 注意：导入历史订阅需携带起始日期、累计用量（如有）、发票与收款状态
- 验证：抽样核对关键客户与订阅余额

7. 测试用例清单（建议最小集合）
- 计费与税务
  - 同一价格在不同税区的发票税额正确
  - 多币种价格的账单金额与显示准确
- 生命周期
  - 试用转正自动计费
  - 升级（即时与到期两种）与降级场景
  - 取消（立即与到期）与退款
- 支付与重试
  - 成功支付、部分支付、失败重试直至暂停/取消
- 通知与集成
  - 发票开出、支付成功/失败邮件发送成功
  - Webhook 触发、签名校验、重复投递幂等通过
- 安全与权限
  - 非管理员无法访问敏感配置
  - 审计日志包含配置变更与导出操作

8. 上线清单
- 关闭沙盒/测试模式，启用生产密钥
- 确认发票编号规则不可逆冲突
- 核对税率与区域映射，启用必要的税收豁免规则（如适用）
- 确认邮件域名与发信信誉正常
- 启用告警：支付失败率、Webhook 投递失败、发票未结清超期
- 权限最小化与MFA要求生效
- 备份与导出策略确认（客户、发票、支付记录）

9. 故障排查指引

支付失败
- 检查：卡组织返回码/网关错误码、3DS/强认证状态、风控拦截
- 动作：调整重试节奏、提示更换支付方式、联系发卡行

税额异常
- 检查：客户税务信息与地址、含税/不含税配置、税区匹配规则
- 动作：修正客户档案与税率映射后重新开票

发票未生成
- 检查：订阅状态与账单日、试用到期时间、任务队列/批处理状态
- 动作：手动触发生成；如失败，查看后台任务日志与错误详情

Webhook 未触发/验证失败
- 检查：事件是否启用、回调 URL 可达性、防火墙、签名配置
- 动作：使用重发工具；在接收端实现幂等与重试

10. 安全与合规注意事项
- 遵循最小权限原则，定期审计用户与角色
- 支付数据处理遵从相关安全标准（例如对支付卡信息使用托管方式，不在后台存储明文敏感数据）
- 税务规则需经财务核对并定期更新
- 对外通知与导出接口启用签名/加密，保留审计日志

11. 术语与数据示例（示意）
- 示例产品：Cloud Storage
- 示例价格：
  - 月付：USD 10.00/月，试用14天，含税价
  - 年付：USD 100.00/年，试用14天，按比例计费启用
- 示例税率：US-CA 7.25%，EU 标准 20%（请以实际税务要求配置）
- 示例 Dunning：第1天失败→第3天重试→第7天重试→第14天暂停

12. 参考实施顺序（建议）
- 周一：权限、公司信息、发票与邮件配置（沙盒）
- 周二：支付渠道与闭环测试（沙盒）
- 周三：产品与价格建模、试用与折扣策略（沙盒）
- 周四：Webhook 与内部系统对接、用例回归
- 周五：生产切换、首批真实交易监控

注：本指南为产品中立的实施步骤与最佳实践模板。具体导航名称与字段可能因系统版本而异，请以实际界面为准，并在上线前由财务与合规负责人最终复核配置。

Quickstart Guide: Generate Your First Document with <ProductName>

1. Purpose
This guide walks you through generating a document from a template and data using <ProductName>. You will:
- Install or access the tool
- Configure authentication
- Create a template
- Provide data
- Render a document via CLI and REST API

2. Audience
- Developers and technical writers integrating <ProductName> into build pipelines or applications
- Requires basic knowledge of command-line tools and JSON

3. Prerequisites
- A <ProductName> account and API key or access token
- Supported runtime for the CLI or SDK (for example, shell environment and curl; language runtime if using an SDK)
- Network access to <ProductName> API (if using cloud)
- Permissions to install and run local binaries (if using CLI)
- Optional: PDF viewer if generating PDFs

4. Install or Access <ProductName>
Choose one of the following:

Option A: Use the CLI
- Obtain the CLI binary or package as directed by your distribution channel.
- Verify installation:
  Command: <cli> --version
  Expected: Prints the installed version

Option B: Use Docker
- Pull the container image if provided by <ProductName>.
  Command: docker pull <registry>/<product-image>:<tag>

Option C: Use SDK (Optional)
- Install the SDK for your language.
  Example: npm install <package-name> or pip install <package-name>

5. Authenticate
Set your API key as an environment variable. Replace the placeholder with your actual key name and value.

- Unix-like shells:
  Command: export <PRODUCTNAME>_API_KEY=your_api_key

- Windows PowerShell:
  Command: setx <PRODUCTNAME>_API_KEY "your_api_key"

If using self-hosted mode with no API key, ensure the service endpoint is reachable and, if applicable, set:
- <PRODUCTNAME>_BASE_URL (for example, https://api.example.com)

6. Prepare a Working Directory
Create a project folder with the following files:
- template file (for example, invoice.template)
- data file in JSON (for example, data.json)
- optional assets (images, CSS)

Example structure:
- quickstart/
  - template.invoice.html
  - data.json
  - assets/
    - logo.png
    - styles.css

7. Create a Template
Use the token syntax supported by your template engine. Replace the placeholders below with your engine’s syntax (for example, {{variable}} or ${variable}).

Example HTML template (template.invoice.html):
<!doctype html>
<html>
  <head>
    <meta charset="utf-8">
    <title>Invoice {{invoice.number}}</title>
    <link rel="stylesheet" href="assets/styles.css">
  </head>
  <body>
    <header>
      <img src="assets/logo.png" alt="Logo" width="120">
      <h1>Invoice {{invoice.number}}</h1>
      <p>Date: {{invoice.date}}</p>
    </header>
    <section>
      <h2>Bill To</h2>
      <p>{{customer.name}}<br>{{customer.address}}</p>
    </section>
    <section>
      <h2>Items</h2>
      <table>
        <thead><tr><th>Description</th><th>Qty</th><th>Unit</th><th>Total</th></tr></thead>
        <tbody>
          {{#each items}}
          <tr>
            <td>{{description}}</td>
            <td>{{quantity}}</td>
            <td>{{unit_price}}</td>
            <td>{{total}}</td>
          </tr>
          {{/each}}
        </tbody>
        <tfoot>
          <tr><td colspan="3">Subtotal</td><td>{{summary.subtotal}}</td></tr>
          <tr><td colspan="3">Tax</td><td>{{summary.tax}}</td></tr>
          <tr><td colspan="3"><strong>Grand Total</strong></td><td><strong>{{summary.grand_total}}</strong></td></tr>
        </tfoot>
      </table>
    </section>
  </body>
</html>

Note: If your engine uses a different syntax, replace {{...}} and {{#each}} blocks accordingly.

8. Create a Data File
Create data.json aligned with your template variables.

Example data.json:
{
  "invoice": {
    "number": "INV-1001",
    "date": "2025-09-19"
  },
  "customer": {
    "name": "Example Co.",
    "address": "123 Market St, Springfield"
  },
  "items": [
    { "description": "Service A", "quantity": 2, "unit_price": 100, "total": 200 },
    { "description": "Service B", "quantity": 1, "unit_price": 150, "total": 150 }
  ],
  "summary": {
    "subtotal": 350,
    "tax": 35,
    "grand_total": 385
  }
}

9. Generate a Document via CLI
Use the CLI to merge the template with your data and produce an output file. Replace flags with the actual CLI options provided by <ProductName>.

Command:
<cli> render \
  --template template.invoice.html \
  --data data.json \
  --assets ./assets \
  --format pdf \
  --out ./output/invoice-1001.pdf

Notes:
- --format can be pdf, html, or docx based on your product’s supported outputs.
- --assets points to local files referenced by the template.
- Ensure the output directory exists, or provide a flag to create it if supported.

10. Generate a Document via REST API
If your product offers a REST endpoint, submit a multipart or JSON request. The following is an example pattern; adjust to match your API’s specification.

Example with multipart form:
Command:
curl -X POST "<BASE_URL>/v1/render" \
  -H "Authorization: Bearer $<PRODUCTNAME>_API_KEY" \
  -F "template=@template.invoice.html;type=text/html" \
  -F "data=@data.json;type=application/json" \
  -F "assets=@assets/logo.png;type=image/png" \
  -F "assets=@assets/styles.css;type=text/css" \
  -F "options={\"format\":\"pdf\"};type=application/json" \
  --output invoice-1001.pdf

Example with JSON and remote assets:
Command:
curl -X POST "<BASE_URL>/v1/render" \
  -H "Authorization: Bearer $<PRODUCTNAME>_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
        "template": {"content_base64": "<base64-encoded-html>"},
        "data": { ... same as data.json ... },
        "assets": [{"url": "https://example.com/logo.png"}],
        "options": {"format": "pdf"}
      }' \
  --output invoice-1001.pdf

11. Verify the Output
- Open the generated PDF or HTML and confirm variable substitution, loops, and asset loading.
- Check fonts and encoding (for example, non-Latin characters) appear correctly.

12. Common Errors and Resolutions
- Missing variable: A placeholder remains unreplaced.
  Action: Ensure the data key exists and matches the template’s variable name; check case sensitivity.
- Template syntax error:
  Action: Validate template against your engine’s syntax; remove unsupported constructs.
- Malformed JSON:
  Action: Validate data.json with a JSON linter.
- Asset not found:
  Action: Confirm relative paths and that CLI/API includes the assets directory or accessible URLs.
- Permissions denied when writing output:
  Action: Verify the output directory permissions or run with appropriate privileges.
- PDF rendering issues (layout overflow, missing fonts):
  Action: Add a font that supports required glyphs; apply CSS for page breaks; embed fonts if required by the renderer.

13. Security Considerations
- Do not commit API keys or secrets to version control. Use environment variables or a secret manager.
- Sanitize or validate template input if accepting user-provided templates to prevent template injection.
- Restrict network access if remote asset loading is enabled.

14. Automation and CI
- Run the CLI in CI pipelines to produce artifacts on merges or releases.
- Cache dependencies and assets for faster builds.
- Store outputs as build artifacts or publish to a document repository.

15. Next Steps
- Explore template partials, layouts, and helpers provided by <ProductName>.
- Configure page settings (margins, headers/footers, page size) for PDF outputs.
- Set up localization and currency formatting.
- Integrate webhooks or callbacks for asynchronous rendering.
- Use version control for templates and establish a review process.

16. Support
- Refer to the <ProductName> API reference for parameter details and limits.
- Contact support with the following information: request ID (if available), CLI version, API endpoint, and a minimal reproducible example (template and data).

Replace <ProductName>, <cli>, <BASE_URL>, and any placeholders with your actual product values. Ensure flags and endpoints match the versions you deploy.

Guía de inicio rápido: Base de conocimiento para gestión de tickets

Objetivo
Proveer instrucciones precisas para poner en marcha, en corto tiempo, una base de conocimiento (KB) integrada al flujo de tickets de soporte, con controles de calidad, gobernanza y medición de valor.

Alcance
- Creación inicial de estructura, roles, flujos y plantillas.
- Publicación del primer contenido reutilizable.
- Habilitación de vínculos KB↔ticket y ciclo de mejora continua.

Audiencia
- Propietarios de proceso de soporte/ITSM.
- Administradores de la plataforma de KB.
- Editores/Agentes de soporte.

Requisitos previos
- Acceso a la plataforma de tickets y a la KB con permisos de administración.
- Definición mínima de catálogo de servicios o categorías de incidentes.
- Aprobación de políticas de seguridad de datos (PII, credenciales, información confidencial).
- Acuerdos de ANS de publicación (p. ej., revisión en 2 días hábiles).

Terminología clave
- Artículo: unidad de conocimiento publicable.
- Metadatos: atributos que facilitan búsqueda, filtrado y gobierno.
- Flujo de trabajo: estados y transiciones (borrador, en revisión, aprobado, publicado, archivado).
- Reutilización: veces que un artículo resuelve o ayuda a resolver tickets.

Roles y permisos (modelo recomendado)
- Administrador de KB: configura estructura, flujos, permisos y metadatos.
- Editor/Autor: crea y actualiza artículos.
- Revisor/Aprobador: valida exactitud técnica, cumplimiento y estilo.
- Agente: consulta y vincula artículos a tickets, sugiere mejoras.
- Consumidor final: lee artículos publicados (según visibilidad).

Pasos de puesta en marcha (aprox. 60–90 minutos)

1) Configurar roles y permisos
- Crear grupos por rol (Administrador, Editor, Revisor, Agente).
- Establecer visibilidad por audiencia: interna (agentes) y externa (usuarios finales), según necesidad.

2) Definir estructura de la KB
- Crear 5–10 categorías iniciales alineadas al catálogo de servicios (p. ej., Acceso/Identidad, Estaciones de trabajo, Redes, Aplicaciones corporativas).
- Limitar profundidad a 2–3 niveles para facilitar navegación.

3) Establecer metadatos obligatorios
- Título, Resumen, Categoría, Etiquetas, Audiencia, Idioma, Propietario, Fecha de revisión próxima, Versión, Estado.
- Opcionales recomendados: Prioridad, Impacto, Productos/Versiones afectadas.

4) Configurar flujo de trabajo
- Estados: Borrador → En revisión → Aprobado → Publicado → Archivado.
- Reglas: aprobación por Revisor; expiración y recordatorio de revisión cada 6–12 meses.
- Requisitos de transición: validación técnica, verificación de seguridad (datos sensibles), conformidad de estilo.

5) Crear plantillas de artículo
- Plantilla estándar (incidentes conocidos y procedimientos de resolución).
- Plantilla de cómo hacer (How-to) para guías paso a paso.
- Plantilla de aviso conocido (Known Error) con causa raíz y workaround.

6) Implementar políticas de contenido
- Prohibir credenciales, PII y datos de tarjetas en el cuerpo del artículo o adjuntos.
- Lenguaje claro, oraciones cortas, voz activa.
- Pasos numerados, un paso por acción, resultados esperados y validación.
- Capturas de pantalla anonimizadas; adjuntos con control de versión.

7) Crear el primer artículo (prioridad alta y de alta recurrencia)
- Seleccionar el ticket resuelto más frecuente de los últimos 30–90 días.
- Convertir el ticket a artículo usando la plantilla estándar y completar metadatos.
- Vincular el artículo a incidentes resueltos como evidencia de reutilización.

8) Habilitar sugerencia de conocimiento en tickets
- Activar sugerencias automáticas por título/síntomas del ticket.
- Configurar el campo “Artículo vinculado” y “Resultado” (útil/no útil).
- Registrar automáticamente la reutilización al cerrar el ticket con el artículo.

9) Publicar y comunicar
- Publicar en entorno de producción con visibilidad adecuada.
- Comunicar a agentes el enlace y criterios de uso del artículo.
- Añadir al inicio de sesión del portal o a colecciones destacadas.

10) Medir y mejorar
- Habilitar paneles de métricas: tasa de reutilización, tiempo de publicación, calificación de utilidad, tasa de rebote, cobertura de categorías.
- Programar revisión quincenal de feedback y actualizaciones.

Plantilla base de artículo (recomendada)

- Título: Acceso a VPN falla con error “X.509: certificate expired”
- Resumen: Error al conectar a VPN en Windows 10/11 debido a certificado expirado. Se describe diagnóstico y corrección.
- Alcance/Versiones aplicables: Windows 10/11, VPN Cliente vX.Y.
- Síntomas:
  - Mensaje “X.509: certificate expired”.
  - Conexión se corta a los 5–10 segundos.
- Causa probable:
  - Certificado de usuario expirado o almacén de certificados corrupto.
- Requisitos previos:
  - Permisos locales de administrador.
  - Conectividad a la CA interna.
- Procedimiento:
  1) Abrir “certmgr.msc”.
  2) Validar certificado en Personal > Certificados; verificar fecha de expiración.
  3) Si expirado, solicitar renovación en Portal de Certificados.
  4) Importar certificado renovado al almacén Personal.
  5) Reiniciar el servicio del cliente VPN.
- Validación:
  - Conexión estable > 2 minutos sin errores.
- Riesgos/Impacto:
  - Interrupción temporal de acceso remoto durante la renovación.
- Tiempo estimado: 10–15 minutos.
- Solución permanente/Seguimiento:
  - Configurar renovación automática 30 días antes de la expiración.
- Enlaces relacionados:
  - Guía de instalación del cliente VPN.
  - Procedimiento de renovación automática.
- Seguridad/Privacidad:
  - No adjuntar certificados ni claves privadas.
- Propietario: Equipo de Redes.
- Fecha de última revisión: AAAA-MM-DD.
- Próxima revisión: AAAA-MM-DD.
- Historial de cambios: v1.0 creación; v1.1 actualización de validación.

Buenas prácticas de contenido
- Titulación: clara y orientada a problema/acción; evitar acrónimos no definidos.
- Primeros 160–200 caracteres del resumen deben describir el problema y la solución en lenguaje simple.
- Etiquetas: añadir términos usados por los usuarios (sinónimos, nombres comunes).
- Capturas: resaltar solo elementos relevantes; incluir texto alternativo.
- Internacionalización: un artículo por idioma; no mezclar idiomas en un mismo artículo.
- Enlaces estables: usar URLs permanentes; evitar rutas locales.

Control de calidad y revisión
- Lista de verificación previa a publicación:
  - Exactitud técnica verificada.
  - Pasos reproducibles y validados en entorno aplicable.
  - Metadatos completos y correctos.
  - Cumplimiento de seguridad (sin PII/secretos).
  - Lenguaje claro, sin ambigüedad.
- Revisión periódica:
  - Revisar artículos de alta reutilización cada 3–6 meses.
  - Archivar o fusionar artículos duplicados o obsoletos.
- Feedback:
  - Activar “¿Fue útil?” y campo de comentarios.
  - Definir SLA de respuesta a sugerencias (p. ej., 5 días hábiles).

Políticas de seguridad y cumplimiento
- Clasificación de artículos: Interno confidencial / Interno / Público.
- Redacción:
  - Enmascarar datos sensibles en ejemplos.
  - No incluir direcciones IP internas salvo que sea imprescindible y esté autorizado.
- Adjuntos:
  - Tipos permitidos, tamaño máximo, escaneo antivirus obligatorio.

Métricas clave
- Reutilización: número de tickets resueltos con un artículo.
- Tasa de deflexión: consultas resueltas sin creación de ticket.
- Tiempo de publicación: desde borrador hasta publicado.
- Porcentaje de artículos con revisión vigente.
- Utilidad percibida: calificación promedio > X.
- Cobertura: porcentaje de categorías con al menos N artículos vigentes.

Mantenimiento continuo
- Rutina semanal: revisar feedback nuevo, actualizar 10% de artículos más usados.
- Rutina mensual: análisis de brechas (categorías con baja cobertura), limpieza de duplicados.
- Rutina trimestral: auditoría de cumplimiento y accesos, revisión de taxonomía.

Lista de verificación de puesta en marcha
- Roles y permisos creados.
- Categorías y metadatos definidos.
- Flujo de trabajo activo con aprobaciones.
- Plantillas cargadas y comunicadas.
- Primer artículo publicado y vinculado a tickets.
- Sugerencias automáticas habilitadas.
- Panel de métricas configurado.
- Políticas de seguridad aplicadas.
- Calendario de revisión establecido.

Con esto, la base de conocimiento queda operativa, conectada al ciclo de tickets y con controles para asegurar calidad, seguridad y mejora continua, alineada con prácticas de gestión del conocimiento ampliamente aceptadas (p. ej., centradas en reutilización y mantenimiento sistemático).