Pacote de suporte após entrega do workflow?

Feedback General
1

Descreva o problema/erro/pergunta

“Para proprietários de pequenos negócios com pouco conhecimento técnico, vocês geralmente vendem um pacote mensal de manutenção/suporte após a entrega do workflow, ou uma transferência única é suficiente?”

Qual é a mensagem de erro (se houver)?

Por favor, compartilhe seu workflow

(Selecione os nós na sua tela e use os atalhos de teclado CMD+C/CTRL+C e CMD+V/CTRL+V para copiar e colar o workflow.)

Compartilhe o resultado retornado pelo último nó

Informações sobre sua configuração n8n

  • Versão n8n:
  • Banco de dados (padrão: SQLite):
  • Configuração n8n EXECUTIONS_PROCESS (padrão: own, main):
  • Executando n8n via (Docker, npm, n8n cloud, desktop app):
  • Sistema operacional:
2

Isso é preferível

No entanto, você deve torná-lo vantajoso para você

3

A partir da minha experiência, depende muito do cliente. Com clientes tecnicamente versados, uma entrega limpa com documentação geralmente é suficiente. Em pequenas empresas sem conhecimento técnico, um pacote de suporte mensal quase sempre faz sentido, porque mudanças de API de serviços externos, expiração de credenciais ou simples mudanças de configuração podem resultar em solicitações de suporte que você atende gratuitamente ou que prejudicam o relacionamento com o cliente.

O que funciona para mim: Um modelo escalonado. Entrega única com 30 dias de garantia inclusos, depois um pacote mensal opcional para manutenção contínua. Assim o cliente tem escolha e você tem um limite claro entre trabalho de projeto e suporte.

O ponto mais importante: Documente explicitamente na conversa de entrega o que está incluído no pacote e o que não está. Clientes com pouco conhecimento técnico tendem a ver qualquer desejo como „suporte‟, até mesmo novas funcionalidades.

1 curtida
4

Hey @ASHIM_DOLEY,

100% sell a monthly maintenance package. If you just do a one-time handoff with a non-technical small business owner, two things will inevitably happen:

  1. An external API will update, a token will expire, or someone will accidentally tweak a setting, causing the workflow to break.

  2. They will panic, call you to fix it urgently, and you’ll end up doing “quick favors” for free just to maintain the relationship.

A good way to handle this is a tiered handoff model:

  • The Safety Net (Included): Give them 14 to 30 days of free post-delivery support to catch any immediate edge cases or bugs in production.

  • The Retainer (Paid): Offer a small monthly maintenance package (e.g., 2 to 5 hours a month) that covers hosting maintenance, credential rotation, checking execution logs for silent failures, and fixing broken API nodes.

The golden rule here: Draw a massive, explicit line between maintenance (keeping the existing workflow alive) and new features (adding new nodes or changing the logic). If they want a new automation step, that’s a new project scope or an extra hourly charge.

Otherwise, you aren’t just selling a workflow; you’re signing up to be their on-call IT department for free!

1 curtida
5

I would sell the monthly maintenance package, especially for small business owners who are not technical. A one-time handoff can work for a technical client, but for most SMB clients the workflow is still a live dependency after delivery: API fields change, credentials expire, rate limits show up, someone changes a sheet column, or a “successful” run quietly produces bad output.

The package should not just be “call me if it breaks.” I would make the included operating loop explicit:

  1. Scheduled checks for the workflows that matter.
  2. Error and silent-failure review, not just failed executions.
  3. Credential/API-change checks.
  4. A clear issue log with status, root cause, resolution, and client impact.
  5. A simple monthly report showing what ran, what broke, and what was fixed.

That is also the gap I am building Maintain Flow around for agencies: post-launch checks, check runs, issues, resolutions, and client-ready reports. Even if you manage it manually in a sheet at first, I would still sell the maintenance package around that loop rather than around loose hourly support.

6

Hi Rory,

I completely agree—framing the maintenance package around an “explicit operating loop” is the key to turning a dreaded task into a value-added service.

It moves the conversation from “fixing broken things” to “proactive health monitoring.” I’ve found that clients appreciate the transparency of a monthly health report (executions, failure rates, and API stability metrics) because it justifies the cost of the retainer while giving them peace of mind.

I am actually building out a similar internal reporting framework for my clients at Swapnil AI Labs. For those who aren’t ready for a full-scale maintenance suite yet, I use a simplified version:

  • Log Reconciliation: A scheduled n8n workflow that audits execution logs across all production instances.

  • The “Silent Failure” Alert: A dedicated node that notifies me if a workflow finishes “successfully” but with anomalous data output.

  • Credential Lifecycle: Tracking token expiry dates within the workflow data itself to trigger a “refresh me” alert before the breakage happens.

It’s great to see more developers pushing for this standard in the community. It protects the client’s ROI and, frankly, keeps our own sanity intact. Are you planning on making Maintain Flow compatible with self-hosted n8n instances as well?

Best,

Swapnil

7

Yes, that is the direction, though I would frame it as self-hosted-compatible rather than a deep native n8n integration at first.

For self-hosted n8n, I think the clean model is:

  1. n8n pushes check results or health events out to the maintenance layer, or the maintenance layer calls explicit health endpoints.
  2. Credentials stay in the client/n8n infrastructure rather than being copied into the maintenance tool.
  3. Locked-down instances can use outbound webhooks instead of opening inbound access.
  4. The maintenance layer stores check status, issues, resolutions, and report history.
  5. The client report is built from that operating trail, not from raw execution logs alone.

That keeps the product above the automation stack: n8n Cloud, self-hosted n8n, Make, Zapier, or custom workflows can all follow the same checks → issues → resolutions → reports loop if they can emit enough health data.

The hard part is not just collecting logs. It is giving the agency and client one trusted place for what ran, what broke, what was fixed, and what needs attention.

8

One thing I should separate more clearly: there are two possible versions of “self-hosted support” here.

The first is a SaaS Maintain Flow account that is compatible with self-hosted or locked-down n8n instances. In that model, the n8n instance sends check results, health events, issue updates, and resolution notes out to Maintain Flow. Credentials and raw execution data stay inside the client/n8n environment.

The second is Maintain Flow itself running fully on-prem or in a client’s private cloud.

The first path is the one I think makes sense to support first and is the direction I am working toward. For your client setup, would that outbound-first self-hosted-compatible model be enough, or would you need the full Maintain Flow app deployed on-prem as well?