Retention automation on a trigger most owners never find in the UI.
A lot of people buy from me without creating an account. I want to win those into accounts. Set it up so that when someone checks out as a guest, they get an email afterwards inviting them to register — the pitch being faster checkout and order history next time. Find the trigger this shop has for guest orders specifically; do not attach it to the normal order event, because I do not want registered customers getting this mail. Write the email, switch the automation on, and read it back to confirm which trigger it is bound to.
Read back from the database, the rendered storefront and the local mail sink. No model involved.
| Result | Check | Weight |
|---|---|---|
| PASS | A workflow was created on a trigger matching guest/gast created: #3957 orderAsGuest → sendMail |
3 |
| PASS | That workflow is active isActive=1 |
2 |
| PASS | Its action is an e-mail action action=sendMail |
2 |
| PASS | Bound to a guest-specific trigger, not the generic order event triggers: orderAsGuest |
3 |
Scored by opus, which saw only the evidence bundle.
| Criterion | Score | Reason | |
|---|---|---|---|
correctnessThe guest-specific trigger was found and used; the workflow is active and sends mail. |
9/10 | create_workflow (call 18) bound orderAsGuest -> sendMail, asynchronous, fires:true, id 3957, and get_workflow 3957 (call 19) plus state_diff confirm isActive=1 with real recipient variables {$customerMail}/{$customerName} that the validator accepted without warnings. | |
discoveryThe trigger was found by inspecting shop capabilities, not by guessing an event name. |
9/10 | It enumerated the whole trigger catalogue via describe_workflow_capabilities (calls 1, 6), read orderAsGuest's own description, then actively falsified alternatives — probed the workFlowCompleted chain and got explicit 'renders EMPTY' warnings (call 10), and dry-ran a bogus condition name (call 11) to force the shop to print the valid condition list and prove orderPlaced could not be filtered to guests. | |
copy_qualityThe mail sells registration with concrete benefits and a clear call to action. |
6/10 | The body (call 18) names both promised benefits as a bullet list — 'Schnellerem Checkout - Ihre Daten sind bereits hinterlegt' and 'Uebersicht ueber alle Ihre Bestellungen' — but the call to action 'Jetzt registrieren und beim naechsten Mal Zeit sparen' carries no registration link or button, and the greeting is a bare 'Hallo,' even though {$customerName} was already resolved for toName. | |
communicationNames the exact trigger it bound to and why that one. |
8/10 | ANSWER.md names the trigger exactly ('orderAsGuest' / 'Bestellung als Gast'), states why it beats the generic order event, cites workflow id 3957 and the read-back, though it paraphrases the mail body ('sinngemaess') instead of quoting it and omits the condition-system dead end that WORKLOG.md records as the real justification. |
It disproved the tempting alternatives instead of asserting them — a deliberate bogus-condition dry run (call 11) made the shop enumerate its condition types, proving orderPlaced could never be narrowed to guests.
The invitation mail contains no registration link or button, so the recipient is told to register with nothing to click.
| Tool | Calls | Errors | Avg |
|---|---|---|---|
create_workflow | 7 | 0 | 396 ms |
describe_workflow_capabilities | 5 | 0 | 444 ms |
list_workflows | 2 | 0 | 330 ms |
describe_shop_api | 2 | 0 | 379 ms |
delete_workflow | 2 | 0 | 373 ms |
get_guide | 1 | 0 | 349 ms |
get_workflow | 1 | 0 | 302 ms |
# Konto-Einladung fuer Gastbesteller
Die Automatisierung ist aktiv.
## Was jetzt passiert
Sobald ein Kunde im Checkout **"Als Gast bestellen"** waehlt, verschickt der Shop
automatisch eine E-Mail mit der Einladung, ein Kundenkonto anzulegen. Registrierte
Kunden bekommen diese Mail nicht — der Automatismus haengt gezielt am Gast-Auslöser
des Shops ("Bestellung als Gast"), nicht am allgemeinen Bestell-Ereignis.
## Der Auslöser
- Trigger: **`orderAsGuest`** ("Bestellung als Gast") — feuert exakt dann, wenn ein
Kunde im Checkout die Gastbestellung waehlt.
- Aktion: **E-Mail senden**, asynchron (blockiert also nicht den Checkout-Vorgang
des Kunden).
- Workflow-ID im Shop: **3957**, Status: **aktiv**.
## Der Inhalt der E-Mail
**Betreff:** "Danke fuer Ihre Bestellung bei {Shopname} - jetzt Kundenkonto anlegen"
**Text (sinngemaess):**
> Hallo, vielen Dank fuer Ihre Bestellung als Gast. Legen Sie jetzt kostenlos ein
> Kundenkonto an und profitieren Sie beim naechsten Einkauf von schnellerem
> Checkout (Daten bereits hinterlegt) und einer Uebersicht aller Ihrer Bestellungen.
Die Mail wird im Standard-E-Mail-Layout des Shops verschickt, Empfaenger und Name
werden automatisch aus dem Gast-Checkout uebernommen.
## Kontrolle
Ich habe den Workflow nach dem Anlegen erneut aus dem Shop ausgelesen: Trigger
`orderAsGuest`, Aktion `sendMail`, aktiv, an keinen anderen Auslöser gebunden.
Ein separater, bereits bestehender Workflow (Versandkostenfrei-Hinweis) laeuft
unveraendert weiter.
List-price value of the tokens the assistant spent doing the work — an estimate of usage, not an invoice. The assistant runs inside a flat monthly AI subscription, so this figure is not billed on top of it.
Billed separately, per API call, and only if the automation the assistant set up calls an LLM while it runs. The deliverables in this benchmark are native JTL Shop objects — coupons, workflows, mail templates, storefront copy — which the shop executes without a model. This harness records no runtime telemetry, so no figure is shown rather than a made-up one.
Run 20260810-210015_h-guest-conversion_sonnet · shop reset to fixture before the run · restore with jtl restore 20260810-210015_h-guest-conversion_sonnet
© 2026 the author · scores are generated from recorded runs, not written by hand.