The score starts with an email, not a customer

Workflow 02.02 watches Gmail for a message labelled Lead or a subject containing a common enquiry term. It passes the sender, subject and up to 3,000 characters of the message to a model. The model extracts a contact name, company, requested service, stated budget and timeline. It also returns a score, a reason for that score and a decision on whether the message is a real enquiry.

That last distinction matters. Spam, cold sales pitches and job applications are meant to stop before the reply and lead-sheet branches. A real enquiry continues down both branches. One creates a Gmail draft. The other writes the extracted facts to a Google Sheet and checks whether the score is high enough for a Slack alert.

The score is not a revenue prediction. It is a routing signal from one inbound message. It decides whether the owner gets interrupted, not whether the sender deserves a reply.

The four fields that produce the score

The extraction prompt gives the model an explicit weighting:

• Budget clarity contributes 40 points. The field is budgetStated. If the sender does not state a figure, the model must return null rather than invent one.
• Timeline urgency contributes 25 points. The field is timeline, extracted from whatever the sender says about dates, urgency or desired start.
• Fit to the listed services contributes 25 points. The field is service. It is compared with the services text in Vault Config, which ships with placeholder offerings and must be replaced for the actual business.
• Specificity of the request contributes 10 points. This rewards an enquiry that explains the work rather than merely asking whether the business is available.

Those fields answer practical questions. Can the sender describe the job? Is it work this business sells? Is there a usable time frame and a stated commercial range? Together they separate an actionable brief from a vague opening message.

They are not independent. A detailed request often includes a timeline. A prepared sender may state both budget and scope. Several fields can reward the same quality. It looks like arithmetic, but the inputs remain model judgements about prose.

What happens at the threshold

Every real enquiry reaches the lead sheet. The workflow records received time, name, email, company, service, budget, timeline, score, status and last-contact time. In parallel, it writes a reply that restates the request, answers the obvious next question and ends with the booking link. It stays as a Gmail draft by default, so a person decides whether to send it.

Only the notification is selective. A filter passes scores of 70 or more to Slack. The alert includes contact, company, score reason, service and timeline. A lower score still produces the draft and sheet row. It simply does not claim immediate attention in Slack.

The consequence is limited. A borderline result changes the interruption, not the record. The owner can still see and answer the enquiry.

A score that would be wrong

Imagine a long-standing client refers a new company with this message: “Mara suggested I contact you. We need the same onboarding fix you built for her. Could we talk next week?” It is specific to both people, but sparse on the four scoring inputs. There is no stated budget. “Next week” is a conversation date, not necessarily an urgent delivery timeline. The service is described through a reference that may not match the configured service words. The request omits scope because the sender assumes the referral supplies context.

That can produce a low score even though the referral makes the opportunity credible. The workflow has no field for referrer, relationship, buying authority or CRM evidence. It reads the email and configured service list. A model may mention the referral in scoreReason, but the scheme gives it no points.

The opposite error is possible. A polished cold pitch can state budget, urgent timing and precise scope resembling the service list. The isRealEnquiry gate should reject it, but if that classification fails, its clarity can produce a strong score.

The repair is a rule, not a smarter adjective

Do not ask the model to be “more accurate”. Add evidence the workflow can test. A referral mailbox, a form field for the referrer or a known-client lookup can set a flag before scoring. That flag can trigger its own alert or a review queue. The model still extracts the brief without inferring relationship history from one sentence.

The same applies to service fit. Replace the placeholder services with concrete offers and exclusions. If discovery calls are welcome without a budget, do not let missing budget clarity dominate. Change the weights or add a rule. Points help only when they match how the business qualifies work.

Where this workflow does not fit

If volume is low and the owner reads every enquiry promptly, scoring adds ceremony. A Gmail label and lead sheet may be enough. A CRM is better when referrals, account history, deal stage and several employees determine priority. This workflow sees one message, not shared sales context.

There is another limit. The file was checked against a real n8n installation, but not run end to end with real Gmail, OpenAI, Google Sheets and Slack accounts. Test accounts and controlled messages come first. The score is a documented design, not proof of consistent interpretation.

The useful question behind the points

The four inputs in workflow 02.02 are budget clarity, timeline urgency, fit to the configured services and request specificity. They measure how actionable the email looks. They do not measure trust, relationship or the full value of the opportunity.

Keep that boundary. Use the score to decide which recorded enquiry creates an extra interruption. Keep the draft, sheet row and human decision outside the threshold. Then a wrong score stays visible and recoverable instead of quietly ignoring a customer.

Die Bewertung beginnt mit einer Mail, nicht mit einem Kunden

Workflow 02.02 beobachtet Gmail auf eine Nachricht mit dem Label Lead oder einem typischen Anfragewort im Betreff. Er gibt Absender, Betreff und bis zu 3.000 Zeichen der Nachricht an ein Modell. Das Modell extrahiert Kontaktname, Unternehmen, gewünschte Leistung, genanntes Budget und Zeitrahmen. Es liefert außerdem einen Punktwert, eine Begründung und die Entscheidung, ob die Nachricht eine echte Anfrage ist.

Diese letzte Unterscheidung ist wichtig. Spam, kalte Verkaufsangebote und Bewerbungen sollen vor den Zweigen für Antwort und Lead-Tabelle enden. Eine echte Anfrage läuft in beide Zweige. Der eine erstellt einen Gmail-Entwurf. Der andere schreibt die extrahierten Fakten in eine Google-Tabelle und prüft, ob der Wert hoch genug für einen Slack-Hinweis ist.

Der Wert ist damit keine Umsatzprognose. Er ist ein Signal zur Verteilung, das aus einer eingehenden Mail entsteht. Er entscheidet, ob der Inhaber unterbrochen wird, nicht ob der Absender eine Antwort verdient.

Die vier Felder, aus denen der Wert entsteht

Der Extraktions-Prompt gibt dem Modell eine feste Gewichtung:

• Budgetklarheit bringt 40 Punkte. Das Feld heißt budgetStated. Nennt der Absender keine Zahl, muss das Modell null zurückgeben, statt eine zu erfinden.
• Dringlichkeit des Zeitrahmens bringt 25 Punkte. Das Feld heißt timeline und wird aus Aussagen zu Terminen, Dringlichkeit oder gewünschtem Beginn gewonnen.
• Passung zu den aufgeführten Leistungen bringt 25 Punkte. Das Feld heißt service. Es wird mit dem Text services in Vault Config verglichen, der mit Platzhalter-Leistungen ausgeliefert wird und für den echten Betrieb ersetzt werden muss.
• Konkretheit der Anfrage bringt 10 Punkte. Damit wird eine Anfrage belohnt, die die Arbeit beschreibt, statt nur nach der Verfügbarkeit des Betriebs zu fragen.

Diese Felder sind sinnvoll, weil sie praktische Fragen beantworten. Kann der Absender die Aufgabe beschreiben? Ist es Arbeit, die dieser Betrieb tatsächlich verkauft? Gibt es einen brauchbaren Zeitrahmen? Hat der Absender den finanziellen Rahmen ausdrücklich genannt? Zusammen unterscheiden sie ein handlungsfähiges Briefing von einer vagen ersten Nachricht.

Unabhängig sind sie aber nicht. Eine genaue Anfrage enthält oft einen Zeitrahmen. Wer ein Budget vorbereitet hat, beschreibt womöglich auch den Umfang gut. Der Wert kann dieselbe zugrunde liegende Eigenschaft, gute Vorbereitung, über mehrere Felder belohnen. Er sieht nach Mathematik aus, doch seine Eingaben bleiben Urteile eines Modells über Prosa.

Was an der Schwelle passiert

Jede echte Anfrage erreicht die Lead-Tabelle. Der Workflow protokolliert Eingangszeit, Name, E-Mail, Unternehmen, Leistung, Budget, Zeitrahmen, Punktwert, Status und Zeitpunkt des letzten Kontakts. Parallel schreibt er eine Antwort, die die Anfrage wiedergibt, die naheliegende nächste Frage beantwortet und mit dem hinterlegten Buchungslink endet. Diese Antwort bleibt standardmäßig ein Gmail-Entwurf. Ein Mensch entscheidet also weiter, ob sie gesendet wird.

Nur die Benachrichtigung ist selektiv. Ein Filter lässt Werte ab 70 Punkten zu Slack durch. Der Hinweis nennt Kontakt, Unternehmen, Begründung, gewünschte Leistung und Zeitrahmen und sagt, dass ein Entwurf wartet. Auch ein niedrigerer Wert erzeugt Entwurf und Tabellenzeile. Er beansprucht nur nicht sofort die Aufmerksamkeit des Inhabers in Slack.

Das ist ein guter Einsatz für eine Bewertung, weil die Folge begrenzt bleibt. Ein Grenzfall verändert die Unterbrechung, nicht den zugrunde liegenden Datensatz. Der Inhaber kann die Anfrage weiterhin sehen und beantworten.

Ein Wert, der falsch wäre

Stell dir vor, eine langjährige Kundin empfiehlt den Betrieb an ein neues Unternehmen und die Nachricht lautet: „Mara hat mir empfohlen, mich bei Ihnen zu melden. Wir brauchen dieselbe Lösung für das Onboarding, die Sie für sie gebaut haben. Können wir nächste Woche sprechen?“ Für Menschen ist die Mail konkret, für die vier Eingaben aber dünn. Ein Budget fehlt. „Nächste Woche“ ist ein Gesprächstermin, nicht zwingend eine dringende Lieferfrist. Die Leistung wird über eine Referenz beschrieben, die vielleicht nicht zu den hinterlegten Leistungsbegriffen passt. Der Umfang fehlt, weil der Absender annimmt, die Empfehlung liefere den Kontext.

Das kann einen niedrigen Wert ergeben, obwohl die Empfehlung die Gelegenheit besonders glaubwürdig macht. Der Workflow kennt kein Feld für Empfehlungsgeber, bestehende Beziehung, Entscheidungsvollmacht oder Hinweise aus einem CRM. Er liest den Mailtext und die hinterlegte Leistungsliste. Das Modell kann die Empfehlung in scoreReason erwähnen, aber das Schema gibt ihr keine festgelegten Punkte.

Auch der umgekehrte Fehler ist möglich. Ein sorgfältig formuliertes kaltes Verkaufsangebot kann Budget, dringenden Zeitrahmen und genauen Umfang nennen, der wie die Leistungsliste klingt. Das Tor isRealEnquiry soll Verkaufsangebote abweisen. Scheitert diese Klassifizierung, kann dieselbe Klarheit, die das Angebot überzeugend macht, seinen Lead-Wert stark aussehen lassen.

Die Reparatur ist eine Regel, kein schlaueres Adjektiv

Behebe das nicht mit der Aufforderung an das Modell, „genauer“ zu sein. Ergänze Hinweise, die der Workflow wirklich prüfen kann. Ein Postfach für Empfehlungen, ein Formularfeld mit dem Namen des Empfehlungsgebers oder eine Abfrage bekannter Kunden können vor der Bewertung ein eigenes Merkmal setzen. Dieses Merkmal kann selbst einen Hinweis auslösen oder die Nachricht in eine Prüfwarteschlange geben. Das Modell darf weiter das Briefing extrahieren; es muss nicht mehr die Beziehungsgeschichte aus einem Satz erraten.

Dasselbe gilt für die Leistungspassung. Ersetze den Platzhalter services durch konkrete Angebote und wichtige Ausschlüsse. Wenn Erstgespräche auch ohne Budget willkommen sind, darf fehlende Budgetklarheit die Verteilung nicht beherrschen. Ändere die Gewichte oder ergänze eine Regel für diesen Fall. Eine Bewertung ist nur nützlich, wenn ihre Punkte dazu passen, wie der Betrieb Aufträge tatsächlich qualifiziert.

Wo dieser Workflow nicht passt

Wenn jede Anfrage wertvoll ist, das Aufkommen klein bleibt und der Inhaber jede Nachricht zeitnah liest, schafft eine Bewertung vor allem Zeremonie. Ein Gmail-Label und eine Lead-Tabelle können genügen. Ein CRM ist außerdem der bessere Ort, wenn Empfehlungen, Kundenhistorie, Verkaufsphase und mehrere Beschäftigte die Priorität bestimmen. Dieser Workflow sieht eine Nachricht; er ersetzt keinen gemeinsamen Vertriebskontext.

Es gibt eine zweite Grenze. Die Datei wurde gegen eine echte n8n-Installation geprüft, aber noch nicht Ende zu Ende mit echten Gmail-, OpenAI-, Google-Sheets- und Slack-Konten ausgeführt. Der erste wirklichkeitsnahe Lauf gehört in Testkonten mit kontrollierten Nachrichten. Bis dahin ist der Punktwert ein dokumentierter Entwurf, kein Beleg dafür, dass das Modell die Anfragen eines bestimmten Betriebs einheitlich versteht.

Die nützliche Frage hinter den Punkten

Die vier Eingaben von Workflow 02.02 sind Budgetklarheit, Dringlichkeit des Zeitrahmens, Passung zu den hinterlegten Leistungen und Konkretheit der Anfrage. Sie messen, wie handlungsfähig die Mail aussieht. Sie messen nicht Vertrauen, Beziehung oder den ganzen Wert der Gelegenheit.

Diese Grenze sollte bleiben. Nutze den Wert, um zu entscheiden, welche protokollierte Anfrage eine zusätzliche Unterbrechung erzeugt. Halte Entwurf, Tabellenzeile und menschliche Entscheidung außerhalb dieser Schwelle. Dann bleibt ein falscher Wert sichtbar und behebbar, statt stillschweigend zur Entscheidung zu werden, einen Kunden zu ignorieren.