Support après la livraison du flux de travail ?

Feedback General
1

Décrivez le problème/l’erreur/la question

« Pour les petits entrepreneurs ayant peu de connaissances techniques, vendez-vous généralement un forfait de maintenance/support mensuel après la livraison du workflow, ou un simple transfert unique suffit-il ? »

Quel est le message d’erreur (le cas échéant) ?

Veuillez partager votre workflow

(Sélectionnez les nœuds sur votre canvas et utilisez les raccourcis clavier CMD+C/CTRL+C et CMD+V/CTRL+V pour copier et coller le workflow.)

Partagez la sortie retournée par le dernier nœud

Informations sur votre configuration n8n

  • Version n8n :
  • Base de données (par défaut : SQLite) :
  • Paramètre n8n EXECUTIONS_PROCESS (par défaut : own, main) :
  • Exécution de n8n via (Docker, npm, n8n cloud, application de bureau) :
  • Système d’exploitation :
2

Ceci est préféré

Cependant, vous devez en tirer profit

3

D’après mon expérience, cela dépend vraiment beaucoup du client. Avec des clients techniquement avertis, une simple remise avec documentation suffit généralement. Avec les petites entreprises sans connaissances techniques, un forfait de support mensuel est presque toujours judicieux, car les changements d’API de services externes, l’expiration des identifiants ou de simples modifications de configuration génèrent sinon des demandes de support que tu traites gratuitement ou qui endommagent la relation client.

Ce qui fonctionne pour moi : un modèle échelonné. Une remise unique avec 30 jours de garantie inclus, puis un forfait mensuel optionnel pour la maintenance continue. Ainsi, le client a le choix et tu as une limite claire entre le travail de projet et le support.

Le point le plus important : documente explicitement lors de la réunion de remise ce qui est inclus dans le forfait et ce qui ne l’est pas. Les clients ayant peu de connaissances techniques ont tendance à considérer chaque demande comme du « support », y compris les nouvelles fonctionnalités.

1 « J'aime »
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 « J'aime »
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?