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 packageActive today
01 · Every 10 minutes
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
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)
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)
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: 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.
From the run log: Keeps no execution data; nothing a visitor types is stored or sent.
06 · Public demo
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:
- A valid new lead goes all the way through.
- The same email again updates the record instead of creating a duplicate.
- An invalid email is rejected with a reason.
- A filled-in spam trap is rejected.
- 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.