Operations context · Auction recording

How we record auctions today

Every auction needs a recording. Most of that work is still manual — a person opens the auction in a browser source, starts a capture, and hopes the start and end times line up. This note explains why we record, how we do it today (Loom vs OBS), and where it breaks.

status: context for colleague · rev 1 · 2026-08-11 · audience: ops / product / engineering

Why this exists

Clients expect a durable copy of each auction. Recordings land in SharePoint so we have an archive of what happened on the day — especially for webcast auctions where audio and video are part of the event.

What needs recording

Across auction formats, the expectation is the same: capture a record of the sale. In practice, formats differ in whether we currently capture them.

Format	A/V present?	Recorded today?	Notes
Webcast auction	Yes — audio + video	Yes (~90%)	Primary workload. Browser capture of the live auction UI + stream.
Pre-bid webcast	Often yes	Not today	Would be a useful bonus if capture became more reliable / automated.
Timed online auction	Usually no live A/V	Not today	Same bonus opportunity — less about mic/camera, more about a durable event record.

Bonus capability

Timed and pre-bid portions are not recorded today. Closing that gap would be valuable, but the urgent pressure is on the webcast majority — where missing start, running long, or dropping mid-sale hurts client deliverables.

Two ways we capture webcasts

We currently have two practical options. Both record the auction as it appears in a browser; they differ mainly in audio isolation and how safely they can run in the background.

Loom quick / constrained

Screen-records the browser. Works well for a focused capture session, but microphone capture cannot be disabled — so ambient talk, meetings, and desk audio can leak into the auction file.

OBS preferred for day-to-day

Browser source + interactive setup. Mic and desktop audio can be disabled so only the auction browser audio is captured. Safe to leave running while you do other work.

Concern	Loom	OBS
Setup effort	Low — open auction, start recording	Higher — add browser source, interact to go live, then start
Microphone	Always captured (cannot disable)	Can disable — auction-only audio
Desktop / other app audio	Risk of bleed depending on session	Can disable — isolate browser source audio
Background use	Poor fit if you need meetings or multitasking	Designed for this — start/stop around your day
Where files go	Loom workflow / export	Saved locally, then uploaded to SharePoint archive

Why Loom is limited for ops

Because Loom always captures the mic, the operator cannot safely join meetings, take calls, or talk nearby without contaminating the auction recording. That pushes most reliable day-to-day capture onto OBS.

OBS workflow (current practice)

This is the repeatable path when we need a clean auction-only recording that can sit in the background.

Add a Browser Source

In OBS, create a browser source and paste the auction URL.
Interact with the embedded browser

Use OBS’s interact feature on that browser source. Click through whatever is required so the auction is live and audio/video are actually playing into the capture.
Lock audio to the browser only

Disable microphone and desktop audio. Confirm OBS is capturing only the browser source audio for that auction.
Start recording

Hit record. OBS can stay in the background while the operator continues other work.
Stop & archive to SharePoint

When the sale is done, stop the recording and save/upload the file into SharePoint so each auction has a durable copy.

What works well

Once set up correctly, OBS gives a clean A/V capture of the webcast without forcing the operator into silence for the whole sale. That is the main reason it wins over Loom for multi-hour auction days.

Where the process hurts

The tooling can capture video and audio. The hard part is human timing and connection reliability around an auction whose length is not known precisely in advance.

Pain point	What happens	Impact
Missed start	Operator is in a meeting or heads-down elsewhere and loses track of the auction start time.	Client-facing gap — opening of the sale may be missing from the archive.
Unknown / fuzzy end	You estimate duration from lot count, then periodically check how many lots remain.	Over-long files — easy to forget and leave recording running well past the end of the day.
Internet drop	OBS itself may keep running, but the browser source loses connection to the auction stream.	Silent failure — you think you are recording; you are recording a dead/blank session.

Start timing

There is no reliable “auction is about to go live — start now” nudge built into the capture loop. Success depends on the operator remembering the schedule while juggling other work. Missing the open is especially bad because clients care about the start of the sale.

End timing

Auctions do not announce a fixed stop wall-clock in a way the capture process can trust. Operators roughly forecast from lot volume, then sample progress during the day. That guesswork is why recordings often run too long — stopping is a manual decision that competes with everything else on the calendar.

Connectivity

A local network blip does not always look like a failed recording. OBS continues; the browser source simply stops receiving the auction. Without an explicit health check or alert, gaps can sit unnoticed until someone reviews the file later.

Operational summary

Today’s system is capable but attention-heavy. Quality depends on a person being available at the right moments, estimating duration, and noticing when the stream dies — not on the recorder knowing when the auction starts, ends, or goes unhealthy.

What “better” would mean (for discussion)

This note is context, not a solution design. Useful directions to explore with product/engineering usually fall into these buckets:

Reliable start — reduce or eliminate missed opens (scheduling, reminders, or automated start against auction state).
Reliable stop — stop when the auction actually ends instead of guessing from lot counts and memory.
Health visibility — detect “recording but not receiving auction” after an internet drop, and surface it quickly.
Coverage expansion — optionally bring pre-bid and timed auctions into the same archive story once the webcast path is less fragile.
Cleaner ops path — keep the OBS-like property (auction-only audio, background-safe) without forcing a brittle manual interact ritual for every sale.

One-liner for colleagues

We already know how to capture webcast auctions; the remaining problem is making capture dependable across starts, ends, and network hiccups — without chaining an operator to the recorder all day.

Auction recording context · hugh-gordon/inbox/auction-recording-context · rev 1 · 2026-08-11 · for internal colleague briefing