Each destination step in the bridge builder has a collapsed Add delay control. Leave it alone and that destination fires immediately. Open it and you get two modes.
Wait for:
Enter a number and choose minutes, hours or days. The contact is held for that long, then delivered.
Wait until:
Pick a date and time. The contact is held until that moment arrives. The time is interpreted in your site's timezone, which is set in the standard WordPress Settings then General screen.
How delivery actually happens:
A delayed destination is written to a queue instead of being delivered right away. The five minute poller drains everything that has come due by replaying the bridge for that one destination with the delay stripped off. That means a delayed delivery reuses the exact same mapping, action and logging path as an immediate one, so nothing behaves differently just because it waited.
Accuracy to expect:
Delays measured in hours or days, and scheduled times, land accurately. A delay measured in minutes is approximate on a low traffic site, because it can only fire on the next poll, and the poll depends on WordPress cron running.
Performance note:
Destinations without a delay never touch the queue at all, so there is no overhead for the majority of bridges that do not use the feature.
Seeing delays at a glance:
Once a delay is set, the destination's collapsed summary in the builder shows a stopwatch tag with the delay on it, so you can see the whole sequence of a multi destination bridge without opening each step.
A practical pattern:
One bridge, three destinations. Add to the list immediately. Post to Slack immediately. Apply a follow up tag two days later, so your sequence has time to run first.