# Run-through

{/* AUTO-SYNCED SOURCE: this page lives in apps/app/src/modules/db-leads/docs/ and is mirrored into the docs app by `bun sync:module-docs`. Edit it in the module, not in apps/docs. */}

<Lead>
The **run-through** is the mode for the afternoon you spend calling forty contacts. It turns a browsing view into a queue: you no longer decide who is next, only what happens to the contact in front of you.
</Lead>

## Why this is its own mode

In the normal view you look for a card, click it, read, close it, and look for the next one. Across forty contacts that is roughly two hundred actions that have nothing to do with any contact. The run-through removes them: after each outcome the next contact is already there, with its briefing, history, and call buttons.

## Starting

The **Run-through** button sits in the toolbar, next to **Sync**. It takes **exactly the contacts that are currently visible**, in the order they appear.

<Tip title="Filter first, then start">
Your stack is only as good as your filter. Useful stacks: all open findings from score 60 up, all contacts of one assignee, everything due today, or one phase of the board. See [List, filters and export](/tools/db-leads/liste-filter-export).
</Tip>

<Callout tone="note" title="Who can use it">
The run-through needs the **Edit contacts** permission (`db-leads.update`), because every outcome writes something. Without it the button is not shown.
</Callout>

## The queue is frozen

At start the order is taken **once** and never touched again. This is the most important property of the mode, and it is deliberate.

The obvious build would be to always use the current list. That breaks the moment the first outcome is pressed: “Not interested” disqualifies the contact, the findings list reloads, the contact you just handled is no longer in it, and the pointer at “number 7 of 40” now points at somebody else. You would skip contacts without noticing.

So: the stack does not shrink because a colleague changes something, and it does not shrink because you disqualify somebody yourself.

<Warning title="After a page reload">
If you reload mid-run, the stack is rebuilt from the visible order. If the data changed in between, the order can differ. That is the more honest of two bad answers: a mode that silently ends after every reload would be worse for somebody who is on the phone.
</Warning>

## The bar at the top

Above the panel runs a bar of its own:

<DefinitionList>
  <DefItem term="Position">“7 of 40 · 33 left”. Your place in the stack, its length, and how many have not yet received an outcome.</DefItem>
  <DefItem term="Prepare briefings">Generates the briefings of the next contacts ahead of time so you never wait mid-call. Contacts that already have one are skipped. While it runs you see progress; one click stops it, and briefings already generated stay.</DefItem>
  <DefItem term="Finish">Leaves the mode. Everything recorded stays, nothing is rolled back.</DefItem>
</DefinitionList>

<Tip title="Prepare before the first call">
Analysing a contact takes a few seconds. Triggering it while somebody waits on the phone is the wrong order. Start the preparation as soon as the stack is set, then begin at the top.
</Tip>

## The five outcomes

At the bottom, the outcomes replace the briefing button. Each one **writes something** and then moves on.

<DefinitionList>
  <DefItem term="Not reached">Records a call attempt and moves on. Working through an existing database, this is by far the most common outcome, which is why it sits leftmost under your thumb.</DefItem>
  <DefItem term="Reached">Records that you spoke. What was said belongs in the note field of the dossier above, not in this button.</DefItem>
  <DefItem term="Appointment">Records an agreed appointment as an activity.</DefItem>
  <DefItem term="Not interested">Disqualifies the contact. A small picker asks for the reason first. The reason is not paperwork: the scan's calibration learns from it what you do not want to see.</DefItem>
  <DefItem term="Later">Sets a follow-up. Again a picker asks for the interval instead of guessing one.</DefItem>
</DefinitionList>

The first two sit on top in wide buttons, the three rarer ones below. The split follows **frequency**, not importance: “Appointment” is the most valuable outcome and still the rarest.

<Callout tone="note" title="What each outcome writes">
Full sentences, not shorthand, and they name the tool as their origin: for example “Not reached. Call attempt from DB-Leads.” The entry gets read months later by somebody who was not on the call, and “n/r” answers no question then. If the contact comes from onOffice and the transfer of notes to onOffice is switched on under Settings, General, the same sentence lands in its log, under the onOffice user mapped to you under Settings, Integrations, onOffice. If it is switched off, the sentence stays in the tool.
</Callout>

<Info title="There is deliberately no “email sent”">
You do not write an email during a run-through, you write it afterwards. An outcome that opens a second application stops the queue.
</Info>

## Moving on only happens after a successful write

If the write fails you stay on the contact and see the error. Otherwise you would be on the next contact while the previous one had nothing in its history, and that only surfaces weeks later when somebody asks why nothing is there.

## What still works inside a run-through

The **three-dot menu** of the panel stays reachable. It holds the marketing objection, "Open in onOffice", "Copy opener" and “Exclude from scan”. Without the menu you could only reach a marketing objection by leaving the run-through, which is exactly the wrong moment for that.

Also available: writing a note, changing the phase, setting the assignee, [adding a property](/tools/db-leads/objekte). You can page backwards too; correcting a contact a second time still counts it as handled once.

## The summary

When the stack is done, the summary replaces the next contact: how many contacts you handled and how they split across the outcomes. From there you return to the normal view.

The queue deliberately has **no wrap-around**: after the last entry it does not start over. Without an end there is no end of day, and that is exactly what the run-through is meant to deliver.

## Further reading

<CardGrid>
  <Card title="List, filters & export" href="/tools/db-leads/liste-filter-export">Assemble the stack before you start.</Card>
  <Card title="Customer view" href="/tools/db-leads/kundenansicht">What is in the panel you read during a run.</Card>
  <Card title="Follow-ups" href="/tools/db-leads/wiedervorlage">What the “Later” outcome creates.</Card>
</CardGrid>