Rules that run, and a run that knows its consequences.
Workflows are configured, not programmed: trigger, conditions, steps, owners. And a run states what it is going to do — then checks whether exactly that came out.
Clarification unanswered — escalation
Active
Draft saved
Dispute opened
Wagner & Söhne GmbH · €4,200
Assign clarification group
Price differences
Dunning paused
Automatic rule
Response draft
Dispute Agent
Handover to collection
When the deadline passes and nobody has answered.
No handover
When the answer arrives — the hold lifts and the level continues.
Schedule
-
Weekdays 06:30
Recompute the dunning run
-
Every 15 minutes
Check clarification deadlines
-
Last day of the month
Send account statements
Configured, not programmed.
A workflow is a chain of trigger, condition, step and owner — assembled in the interface, versioned and stoppable at any time. What it does is readable as text, not buried in a script.
Trigger
An event on an object — a clarification stays unanswered, a document falls due, a limit is exhausted.
Condition
Amount, area, customer group, reminder level, period — every condition is a field that exists in the record.
Step
A permitted action: notify, escalate, stop, release, defer, draft a letter.
Owner
Every step has a person or a role. A step without an owner is a step that stalls.
A workflow step without an owner is the most common reason escalations sit still — so the interface marks it as such rather than skipping it quietly.
Four phases, in this order.
A dunning run is a process rather than a button, and it has four phases. The third is the one that makes it checkable: every reminder is recomputed and held against the expectation the run stated beforehand.
Decide
A path is chosen per case — send, reduce, defer, leave.
Clean up
Close clarifications, lift dunning stops, defer cases.
Control
Every reminder is recomputed and checked against the expectation.
Expectation
"expected: −2 documents, −0.00 EUR" — that is how a run states what its own action should achieve. If something else comes out, the reminder does not go, and the deviation sits on the case.
Dispatch
Only what matches the expectation goes out. Everything else stays.
Ten groups, assigned deterministically.
Every case gets a check group — not as a sort order but as a finding with a reason. The assignment is computed by the database rather than the model, and it is total and disjoint: every case sits in exactly one group.
And the buckets above them — goes out today, waiting, needs you — are the answer to the only question a clerk has in the morning: what do I have to touch?
- Clear case Nothing speaks against sending.
- Dunning stop holds documents back The stop takes documents out of the reminder.
- Documents in clarification An open clarification concerns the document.
- Promise to pay open A promised date lies in the future.
- Zero-sum documents The dunned documents add up to nothing.
- Escalation The next level would be reached.
Schedules that send nothing overnight.
Runs and analyses follow a schedule — the dunning run early in the morning, the deadline check every quarter hour, the ledger report on the last day of the month. What follows from a schedule is a proposal or a check, never a dispatch without release.
Rolling, not a cut-off date
The run recomputes instead of producing one monthly pile.
No overnight run
A run nobody can see is not executed — it waits for the next working day.
Follow-up
What was skipped today is back on top tomorrow — with today's reason.
Deterministic, prepared, or on demand.
The same mechanics at three speeds. The distinction matters because only the first works without AI — and it is the normal case.
Rule-based
Workflows and schedules. No model, no consumption, same input same output.
Prepared
An agent groups the run, justifies and proposes. A person releases.
On demand
A question in the chat, an analysis, a plan — for the single case, not for operations.
What a run explicitly does not do.
Automation becomes trustworthy by having its boundaries named — and by those boundaries not moving with the next release.
- No dispatch without release, except for the cases you explicitly released as a rule.
- No overnight run. What nobody can review any more is not executed.
- No silent deviation. If the result does not match the expectation, the reminder stays.
- No check group from the model. The assignment is computed deterministically.
- No step without an owner — it is marked, not skipped.
- No follow-up that loses its reason. What was deferred comes back with its justification.
What gets asked about automation.
No. A workflow is assembled in the interface — trigger, conditions, steps, owners — and is readable as text rather than as a script. What it may do are the actions the system already permits; it cannot build itself new ones.
Schedules run, yes — but what follows from them is a recomputation, a check or a proposal. A run whose result nobody could see is not executed; it waits for the next working day. Dispatch happens only by your rules or after a release.
Before the run does anything, it states the expected result of its own action — for instance "two documents fewer, amount unchanged". Then it recomputes the reminder and compares. If the result deviates, nothing goes out and the deviation sits on the case. That is why a run may prepare unsupervised.
The groups are defined in domain terms and assigned deterministically — they describe facts such as "dunning stop holds documents back" or "promise to pay open". What you control are the rules before them and the decisions after them: which groups pass through automatically and which someone looks at.
It is reassessed tomorrow and back on top — with today's reason. That is the follow-up: a skipped case does not drop out of sight, and it is not quietly sent either.