We use what we sell

How we run Minimolo on n8n

Six workflows are active on our own n8n instance today. Four of them run the studio; two are public demos. Each one is described below from its live configuration, step by step, with the checks and safeguards each one runs.

See the agency package

Active today

  1. Inbox triage
  2. Website lead intake
  3. Daily website health check
  4. Page watcher
  5. Demo: agency lead routing
  6. Demo: hotel enquiry

01 · Every 10 minutes

10 min · schedule trigger, all day 1. Every 10 minutes (schedule trigger); 2. Connect to our mailbox (a fresh access token on every run); 3. Read recent messages (Inbox, Notification, Newsletter and Spam); 4. Skip what we've already seen (and anything sent from our own domain); 5. Classify each message (human message, unsubscribe, bounce, auto-reply, system mail); 6. Email an alert (human messages, unsubscribes and bounces only) Workflow n8n 10 min schedule trigger, all day 01 Every 10 minutes schedule trigger 02 Connect to our mailbox a fresh access token on every run 03 Read recent messages Inbox, Notification, Newsletter and Spam 04 Skip what we've already seen and anything sent from our own domain 05 Classify each message human message, unsubscribe, bounce, auto-reply, system mail 06 Email an alert human messages, unsubscribes and bounces only From our live n8n instance · 19 October 2026

Inbox triage

Our shared inbox is triaged automatically. Every ten minutes the workflow reads new mail and separates human messages, auto-replies, bounces, unsubscribe requests and system mail. Only what needs a person, a human message, an unsubscribe request or a bounce, triggers an alert; auto-replies and system mail stay silent.

Why we built it

Real messages do not always land in the inbox; some end up in spam or notification folders. An unsubscribe request should be honoured promptly, and a bounce should be noticed the same day, not found days later.

What it saves us

Nobody has to open four folders several times a day, and auto-replies such as “thanks for your message” no longer look like real answers.

From the run log: Because this workflow reads mail, it does not store the data of successful runs; only failures are kept for debugging.

02 · On every enquiry

Each form · webhook trigger, key required 1. A site enquiry arrives (our form server forwards it to n8n); 2. Clean and validate (required fields, email format, spam trap); 3. If invalid: reject with reasons (HTTP 400, nothing is saved); 4. Save to a data table; 5. Email an alert (up to 3 tries, 5 seconds apart); 6. Record the alert status (“notified” or “failed after 3 tries”); 7. Confirm receipt to the form Workflow n8n Each form webhook trigger, key required 01 A site enquiry arrives our form server forwards it to n8n 02 Clean and validate required fields, email format, spam trap 03 If invalid: reject with reasons HTTP 400, nothing is saved 04 Save to a data table 05 Email an alert up to 3 tries, 5 seconds apart 06 Record the alert status “notified” or “failed after 3 tries” 07 Confirm receipt to the form From our live n8n instance · 19 October 2026

Website lead intake

Every enquiry sent through our contact form also enters this workflow. It cleans and checks the fields, rejects invalid submissions with the reasons, saves valid ones to a table and sends an alert. If the alert still fails after three tries, the record says so instead of the enquiry silently disappearing.

Why we built it

A lead form is only as good as the follow-up. We wanted every enquiry recorded before anything else happens, and a visible trace when an alert does not go out.

What it saves us

No copying enquiries from one place to another, and no wondering whether an alert was missed: each row carries its own alert status.

From the run log: Every enquiry is recorded before any alert goes out, and each record carries its own alert status.

03 · Daily at 09:00 (Istanbul time)

09:00 · every day, Istanbul time 1. Every day at 09:00 (schedule trigger); 2. Request both site addresses (minimolo.net and www.minimolo.net); 3. Read HTTP status and certificate (trust, expiry date, days left); 4. Problem found? (untrusted certificate, under 21 days left, failed request or HTTP 400 and above); 5. Yes: email an alert; 6. No: stay silent Workflow n8n 09:00 every day, Istanbul time 01 Every day at 09:00 schedule trigger 02 Request both site addresses minimolo.net and www.minimolo.net 03 Read HTTP status and certificate trust, expiry date, days left 04 Problem found? untrusted certificate, under 21 days left, failed request or HTTP 400 and above 05 Yes: email an alert 06 No: stay silent From our live n8n instance · 19 October 2026

Daily website health check

Checks once a day that our website answers and that its TLS certificate is trusted and not close to expiry. It only speaks up when something is wrong.

Why we built it

An expired certificate or a broken page is the kind of problem you hear about from a visitor first. A daily check means we hear about it before they do.

What it saves us

No manual daily look at the site, and no alert noise on good days.

From the run log: On a normal day both addresses answer, the certificates are well within their validity and no alert is sent.

04 · Daily at 09:15 (Istanbul time)

09:15 · every day, Istanbul time 1. Every day at 09:15 (schedule trigger); 2. Load the last snapshot (from an n8n data table); 3. Fetch the watched pages (KVKK announcements and our own guides); 4. Compare the matching links; 5. New link or error: email an alert (up to 3 tries); 6. Save the new snapshot (after the alert has gone out) Workflow n8n 09:15 every day, Istanbul time 01 Every day at 09:15 schedule trigger 02 Load the last snapshot from an n8n data table 03 Fetch the watched pages KVKK announcements and our own guides 04 Compare the matching links 05 New link or error: email an alert up to 3 tries 06 Save the new snapshot after the alert has gone out From our live n8n instance · 19 October 2026

Page watcher

Compares today’s links on a few pages with yesterday’s and reports new ones with their titles. If a page can’t be fetched, that is reported too. The snapshot is only updated after a successful alert, so a failed alert is retried on the next run instead of being lost.

Why we built it

We watch announcements from KVKK, the Turkish data protection authority, because they affect how forms and customer data should be handled, and our own guides page to confirm new guides are live.

What it saves us

Nobody has to revisit the same pages every morning to spot what changed.

From the run log: On a quiet day nothing new is found and no alert is sent; a new link or a failed fetch is reported the same morning.

05 · Public demo

Demo · public page, nothing stored 1. A visitor opens the demo page (the page is served by n8n itself); 2. They send an example enquiry; 3. Validate (name, email, message, spam trap); 4. Score and choose an owner (budget, company, email domain, message); 5. Draft CRM record, alert and reply; 6. Show it all on screen (nothing is stored or sent) Workflow n8n Demo public page, nothing stored 01 A visitor opens the demo page the page is served by n8n itself 02 They send an example enquiry 03 Validate name, email, message, spam trap 04 Score and choose an owner budget, company, email domain, message 05 Draft CRM record, alert and reply 06 Show it all on screen nothing is stored or sent From our live n8n instance · 19 October 2026

Demo: agency lead routing

A working example of the lead handoff we build for agencies: an enquiry is validated, scored and routed to an owner, and the page shows the CRM record, the owner alert and the auto-reply the workflow would produce.

Why we built it

Describing a workflow is weaker than letting someone run one. This lets an agency try the logic with its own example before talking to us.

What it saves us

Fewer calls spent explaining what a lead handoff looks like.

Open the lead-routing demo →

From the run log: Keeps no execution data; nothing a visitor types is stored or sent.

06 · Public demo

Demo · public page, nothing stored 1. A visitor opens the demo page (in Turkish, served by n8n itself); 2. They send an example booking request; 3. Validate (name, email or phone, dates); 4. Build the record (reference number, nights, guests, room); 5. Draft staff note and guest reply; 6. Show both on screen (nothing is stored or sent) Workflow n8n Demo public page, nothing stored 01 A visitor opens the demo page in Turkish, served by n8n itself 02 They send an example booking request 03 Validate name, email or phone, dates 04 Build the record reference number, nights, guests, room 05 Draft staff note and guest reply 06 Show both on screen nothing is stored or sent From our live n8n instance · 19 October 2026

Demo: hotel enquiry

A booking request from a hotel website becomes a record with a reference number, a short note for the staff and a reply to the guest. The dates are checked, so a check-out before check-in or a date in the past is rejected.

Why we built it

Small hotels lose requests between the phone, WhatsApp, email and the website form. The demo shows the first step of fixing that.

What it saves us

For us: a concrete thing to show hotels instead of a description. For a hotel: no hand-typed replies to the same kind of question.

Open the hotel enquiry demo (in Turkish) →

The guest-facing side is described on the hotel guest assistant page.

From the run log: Keeps no execution data; nothing a visitor types is stored or sent.

Published on n8n.io

A template anyone can import

We published one of our hotel workflows as a free template in the n8n.io library: Log hotel booking enquiries to Google Sheets with WhatsApp and Gmail. It is the same kind of enquiry handling the hotel demo above shows, packaged for any n8n account.

The three studio workflows above (health check, lead intake and page watcher) can also be downloaded as templates from our n8n automation page.

Client delivery

Every client workflow ships with five acceptance tests and a failure alert

What we learned running our own workflows goes into what we deliver. Before handover we agree five acceptance tests with you, and we run them together. For a lead handoff they are:

  1. A valid new lead goes all the way through.
  2. The same email again updates the record instead of creating a duplicate.
  3. An invalid email is rejected with a reason.
  4. A filled-in spam trap is rejected.
  5. When a connected system is down, the failure alert fires and the enquirer is still acknowledged.

The failure alert is part of the workflow, not an add-on: if a step fails, someone hears about it on a channel you choose.

Want this kind of workflow for your clients, under your brand?

See the agency package