Stop new bid acceptance
Use the agreed pause phrase. The auctioneer does not call sold, the clerk does not advance the lot and staff do not improvise a parallel bid channel.
REFERENCE 02LIVE FAILURE RECOVERY
What to Do When the Internet Fails During a Live Auction
Use this field runbook to pause the sale without losing the active lot, preserve the last verified bid, identify the failed layer, move to a tested backup path and reopen only after one complete bid round trip has passed.
The sequence is built for an internet failure, auction platform outage or simulcast outage that begins after bidding is live. It separates protection of the auction record from network troubleshooting: freeze the trusted lot and bid state first, then isolate the local, carrier, platform or workstation fault without creating a second uncertainty.
BUILT FORAuctioneersOperations managersSimulcast teamsMobile auction crewsClerks & cashiers
OPERATING PRINCIPLE
Freeze the auction record before changing the technical path.
When the bid path becomes uncertain, the first objective is not to restore internet as quickly as possible. The first objective is to prevent the active lot, last verified bid and bidder source from becoming disputed while staff make changes.
Have the auctioneer pause bidding, stop clerk input and record the last state that two responsible people can independently verify. A router restart, browser refresh, account change or WAN switch performed before this record is frozen can remove the evidence needed to resume fairly.
Use one technical lead to direct recovery and one named person to decide whether the sale stays paused, reopens through the restored path or moves to a pre-approved reduced operating mode.
Capture the last trusted state
Write the lot number, amount, bidder source, bidder identifier, displayed platform state, exact time and names of the people who verified it.
Identify the failed layer
Separate local workstation, LAN, primary carrier, DNS, platform, audio/video and remote-bidder symptoms before making a change.
Test the complete path
Reopen only after an independent bidder connection reaches the correct lot, the bid reaches the clerk and the resulting state matches across required records.
Published August 3, 2026 · Prepared by Jasper Auction’s small volunteer community
FIRST 30 SECONDS
Create a controlled pause before the incident spreads.
These are operational controls, not diagnostic steps. Complete them before anyone reboots a router, refreshes the production browser or switches networks.
Call a neutral pause
State that bidding is paused while the online path is verified. Do not announce a winner, accept a shouted continuation or restart from memory.
Freeze lot and bid entry
Stop advancing the catalog and record the last amount and bidder source visible in the trusted clerk view. Capture a screenshot when the state remains readable.
Stop uncoordinated changes
Tell staff not to reboot, reconnect, change accounts, enable hotspots or move cables until the failure owner and current state are confirmed.
Start the incident record
Record detection time, active ring, lot, known affected channels and the person authorized to decide whether the sale can resume.
INCIDENT CONTROL DESK
Give each recovery decision one owner.
Small teams may combine roles, but the auctioneer, clerk and technical lead must not make conflicting changes or announcements.
| Role | Owns during the outage | First required confirmation | Authority boundary |
|---|---|---|---|
| Auctioneer / ring lead | Room control, pause language and the physical bid floor | Bidding has stopped and no lot has been sold during an uncertain online state. | Does not reopen from memory; resumes only from the state provided by the authorized recovery decision. |
| Clerk / simulcast operator | Active lot, bid source, amount, bidder identifier and platform evidence | The last accepted bid can be supported by the clerk record, operator view or preserved evidence. | Stops input when lot state or bidder source differs across required views. |
| Technical lead | Failure isolation, WAN change, workstation recovery and proof testing | The auction record is frozen and the tested backup configuration is known. | May restore or switch the technical path but does not decide disputed bid ownership. |
| Operations manager | Decision to resume, stay paused or use a reduced operating mode | The last verified state, affected channels, terms and available fallback are understood. | Does not authorize a mode that conflicts with published sale terms, platform rules or applicable requirements. |
| Bidder communications lead | Consistent room, platform, phone and support messaging | One approved message and one update channel are active. | Does not promise a resume time, lot result or bidder remedy that has not been authorized. |
MASTER INCIDENT RUNBOOK
Recover in dependency order without losing the bid record.
The times below are working targets, not automatic deadlines. A clean carrier failover may take less than two minutes; a platform-wide outage or disputed bid state may require a longer pause.
Do not let elapsed time pressure the team into reopening. The pass condition is not “the internet light is green.” It is one verified production bid path with the correct active lot and last accepted bid.
When the last trusted bid cannot be established, keep the lot paused and follow the operation’s authorized discrepancy procedure. Network recovery does not resolve a conflict in the auction record.
| Incident window | Action | Required evidence | Stop / escalation rule |
|---|---|---|---|
| 0–30 seconds | Pause and freeze. Stop bid acceptance, keep the active lot on screen where possible and prevent sold, pass, advance or correction actions. | Lot number, displayed amount, bidder source, bidder identifier where available, system time and two-person verbal confirmation. | If staff cannot agree on the active lot or last accepted bid, mark the state disputed and do not resume from memory. |
| 30–90 seconds | Define the symptom. Check whether the failure affects all venue devices, one workstation, the bidding platform, audio/video only, local services or remote bidders only. | Affected stations and channels, local gateway reachability, platform status from another path and whether the clerk record remains available. | Do not restart shared equipment until the scope is known and the auction record is preserved. |
| 1–3 minutes | Protect local continuity. Keep the clerk record, catalog, local network and protected power stable. Save screenshots or export available incident evidence without changing the active state. | Local system availability, timestamp source, current operator account, ring, lot and any preserved event or screenshot. | If local records are also unstable, stop all transaction input and move to the documented record-continuity procedure. |
| 2–5 minutes | Choose restore or failover. Restore a single failed workstation only when the wider path is healthy. Move to backup WAN when the primary path is confirmed failed and the backup is approved for production use. | Named failure owner, known-good backup profile, backup capacity and exact point at which the network path changes. | Do not create an improvised hotspot, double-NAT route or shared Wi-Fi change that has not carried the production workflow before. |
| 3–7 minutes | Rebuild the operator path. Confirm addressing, DNS, platform login, production sale, correct ring, active lot, clerk permissions, browser device permissions and audio/video inputs where used. | The production operator view opens through the intended path and shows the frozen lot without an unexplained state change. | If the platform shows a different lot, amount or high bidder, remain paused and treat the difference as a bid-state discrepancy. |
| 5–10 minutes | Run an independent bid round trip. Join through a connection outside the venue LAN, verify the visible lot, use a harmless platform-approved test action or a pre-authorized test account and confirm the result reaches the clerk. Never submit a live bid that could create or alter a binding sale record. | Correct lot, bid source, amount, acknowledgment, operator state and recorded result match across the required views. | A successful speed test, website load or operator login is not enough. No bid round trip means no simulcast resume. |
| Before resume | Reconcile the restart point. State the exact lot, last accepted bid, bidder source, next increment and active internet path. Obtain confirmation from auctioneer, clerk, technical lead and decision owner. | A single written restart state and named person authorizing the resume. | Any unresolved disagreement keeps the lot paused, even when connectivity has returned. |
| Resume | Announce and reopen. Tell floor and remote bidders that the path has been verified and identify the lot and restart amount without exposing unnecessary personal information. | Announcement time, communication channels used and the first accepted post-recovery bid. | If the first live bid does not synchronize correctly, pause again immediately and return to the last verified state. |
| After stabilization | Freeze the recovered configuration. Stop nonessential changes, keep the verified backup or restored primary path active and record reduced capacity. | Active WAN, operator station, known limitations, temporary controls and support case number where opened. | Do not “clean up” cables, accounts or routing while the sale remains live unless the active path becomes unsafe or unusable. |
OPERATION-DEFINED DECISION THRESHOLDS
Set escalation points before the sale, not during the outage.
These are sample decision points, not a universal service-level agreement. Each auction operation should define its own recovery time objective, authority and permitted continuity modes before bidding begins.
| Elapsed time | Required decision | Minimum evidence | If unresolved |
|---|---|---|---|
| T+2 minutes | Name the incident owner and define scope. Confirm the affected ring, channels, staff and shared systems. | Frozen lot and bid state, affected stations, first known symptom and named technical lead. | Keep the affected lot paused and prevent uncoordinated changes. |
| T+5 minutes | Choose restore or failover. Decide whether to repair one local fault, retain the primary path or activate the tested backup. | Likely failed layer, backup readiness, expected capacity and named change owner. | Remain paused and escalate to the operations manager. |
| T+10 minutes | Issue an extended-pause update. State what is being verified and when the next status update will be given. | One approved room and remote message, active communication channel and update owner. | Do not promise a restart time; give the next update time only. |
| T+15 minutes | Decide the status of the affected lot or ring. Continue the pause, suspend the ring or use only a pre-approved reduced operating mode. | Published terms, bid-record status, channel availability and named decision authority. | Keep the affected lot or ring suspended. |
| T+30 minutes | Review suspension, postponement or termination. Senior operations and sale authority decide whether same-day recovery remains credible. | Technical prognosis, bidder communication plan, record integrity, staffing and venue constraints. | Use the operation’s documented suspension or postponement procedure. |
SYMPTOM TRIAGE
Use the visible symptom to choose the first test.
Do not assume every missing online bid is an internet outage. A local browser, account, ring assignment, audio path or platform-side event can produce similar complaints.
| Observed symptom | Likely layer | First proof check | Avoid |
|---|---|---|---|
| All venue devices lose external access | Primary WAN, modem, edge router, upstream carrier or shared power | Gateway state, modem/ONT state, protected power and independent external reachability. | Rebooting every workstation or changing platform accounts. |
| One clerk station is offline; other devices work | Workstation, cable, switch port, local addressing, browser or account | Known-good cable/port, local gateway, operator login and correct production profile. | Switching the entire venue to backup WAN. |
| Platform fails on venue WAN and independent cellular | Platform, upstream cloud service, authentication or wider internet route | Provider status/support route and another authorized account or location. | Repeated local router changes that cannot affect the external service. |
| Bids arrive, but remote audio or video stops | Browser permission, encoder, input selection, mixer, USB device or stream service | Bid state first, then selected microphone/camera, local meters and remote feed. | Treating a media-only failure as proof that bidding is healthy enough to continue automatically. |
| Remote bidders report delay; control desk looks normal | Upload congestion, packet loss, platform latency, stream load or remote path | Independent bidder view, sustained path measurement and competing local traffic. | Relying only on the venue operator screen or one peak speed-test result. |
| Correct connectivity, wrong lot or ring in operator view | Sale configuration, account role, catalog state or platform session | Production URL, sale ID, ring, operator account and frozen incident record. | Accepting bids until every required view shows the same lot state. |
| Internet returns, but last bid differs between views | Unsynchronized bid state or commercial record discrepancy | Clerk record, platform event history, preserved screenshots, timestamps and bidder source. | Choosing the highest visible amount without an authorized reconciliation procedure. |
| Unexpected credential prompts, altered records, widespread login failures or a provider security notice | Possible account compromise or cybersecurity incident | Preserve screenshots and logs, isolate affected devices, contact the named security or platform lead and verify service from a clean trusted device. | Moving affected devices to backup WAN, reusing credentials or treating the event as a normal carrier outage. |
| Checkout fails after WAN change | DNS, payment gateway session, terminal route, firewall or account token | Approved payment test/continuity procedure and separate transaction-path verification. | Assuming a successful bidding path automatically proves payment and release systems. |
POSSIBLE CYBER INCIDENT HANDOFF
Stop normal failover when the outage may involve compromise.
Unexpected credential prompts, unrequested MFA approvals, altered records, widespread authentication failures or a provider security notice require a security handoff. Do not carry a suspected compromise onto the backup WAN.
- 01
Stop credential use
Do not enter passwords into an unexpected prompt, approve an MFA request the operator did not initiate or reuse the same session on another network.
- 02
Preserve evidence before cleanup
Record the time, affected account or device, visible messages and changed records. Preserve screenshots and available logs; do not wipe, reinstall or casually reset the affected device.
- 03
Isolate the suspected device
Remove it from production connectivity using the operation’s approved isolation method. Do not reconnect it through the backup internet path.
- 04
Verify from a clean trusted path
Use a known-good device and independent connection to check provider status, the production sale, account integrity and whether the same symptom exists outside the venue.
- 05
Escalate DDoS or service disruption
If the service is unreachable through multiple independent networks, contact the ISP and platform security or support route. Preserve start time, affected endpoints and case numbers; avoid repeated uncontrolled restarts.
- 06
Contain phishing or account compromise
Use a clean device and approved security channel to revoke sessions or change credentials. Check sale, bidder, payment and account settings for unauthorized changes before trusting a restored login.
- 07
Invoke the separate cyber incident plan
The technical outage runbook ends at the security handoff. Keep the affected lot paused until the authorized security and auction decision owners confirm both service availability and record integrity.
REMOTE BIDDER PROOF
Verify recovery from outside the production network.
The operator console can reconnect while remote bidders still see a stale lot, delayed auctioneer audio, a disabled bid button or a session that never reaches the clerk.
Use a controlled device on an independent connection. Confirm the production sale and ring, then follow one action from the bidder interface to the clerk record and back to the bidder-facing result.
Where the platform cannot support a harmless controlled bid during the incident, use its approved test or support procedure. Never create an unapproved bid or alter a live commercial record merely to test connectivity.
- 01
Use an independent connection
Join through a separate cellular carrier, external office or other controlled path that does not depend on the venue router being tested.
- 02
Confirm sale, ring and lot identity
Check the production URL, sale title, ring, lot number, image or description and displayed bid before placing any controlled action.
- 03
Check bidder permissions and session state
Verify that the approved test user or authorized bidder state is current and that the bid control is not merely displaying a cached or disconnected screen.
- 04
Follow one action to the clerk
Confirm the action reaches the correct operator view with the expected source and amount, without appearing in another ring or delayed queue.
- 05
Confirm the response returns
Verify that acceptance, outbid state, lot advance or other approved test result returns to the bidder-facing interface and required records.
- 06
Record the proof and clean test state
Capture the time, path, device, result and operator. Remove or mark test data using the platform’s approved workflow before live bidding resumes.
BACKUP WAN CHANGE
Treat failover as a production change, not a quick hotspot fix.
A backup path can introduce different addressing, DNS, firewall, bandwidth, latency and session behavior. The switch is complete only after the auction workflow passes.
Confirm the primary path is the fault
Verify that the issue is shared across intended production devices and that a workstation, account, platform or local configuration fault does not better explain the symptom.
Use the approved connection method
Follow the rehearsed modem, router or SD-WAN procedure. Record the switch time and do not leave two uncontrolled default routes active.
Remove nonessential traffic
Pause guest Wi-Fi, cloud sync, updates, noncritical streaming and other loads when the backup path has reduced upload or data capacity.
Retest dependent services
Verify DNS, time, platform, clerk, remote bidder, audio/video, payment and support channels that depend on the changed route.
REDUCED-MODE DECISION
Do not continue floor-only merely because the room still works.
Whether a sale may continue without the advertised online channel depends on the published terms, platform arrangements, applicable requirements, bid record and the named person with authority to make that decision. This runbook does not override them.
| Condition | Operational meaning | Default posture | Required control |
|---|---|---|---|
| Simulcast was advertised as an active bid channel and remote access is unavailable | A material bidder group cannot participate through the expected path. | Remain paused unless an authorized reduced mode is explicitly permitted. | Document authority, bidder notice, affected lots, restart point and how online bidders are treated. |
| Last online bid and bidder source are verified; online path is still down | The record is known, but equal access may not be restored. | A known record alone does not justify floor-only continuation. | Apply published terms and the operation’s approved continuity decision. |
| Online channel was supplementary and terms authorize continuation | A reduced mode may be available, but bidder communication still matters. | Conditional continuation only by the named decision owner. | Announce the mode, freeze affected online intake and record the exact time and lot range. |
| Platform recovered, but bid history differs from the clerk record | The auction record is disputed even though connectivity is back. | Remain paused. | Reconcile event history, timestamps, bidder source and authority before any restart. |
| A separate ring is technically and operationally independent | The incident may be isolated to one ring. | Other ring may continue only when shared dependencies and staffing are unaffected. | Clearly isolate ring, accounts, audio, bidder messaging and incident records. |
| The outage prevents reliable bidder communication or auctioneer acknowledgment | Participants cannot understand the active state or compete predictably. | No-go for the affected lot or ring. | Restore an intelligible, synchronized path before reopening. |
BID-RECORD INTEGRITY
Separate network recovery from bid-state reconciliation.
A restored connection can reveal delayed, queued or differently timestamped events. Do not treat the first screen that reconnects as the authoritative state without checking the operation’s approved record sources.
Confirm one active lot
Match ring, lot number, description and catalog position across the auctioneer, clerk and bidder-facing views before considering the amount.
Use preserved evidence
Compare clerk record, platform event history, screenshots, timestamps, bidder source and any authorized phone or absentee record.
Identify queued or late-arriving bids
Record when the bid was submitted, received and displayed where those fields exist. Do not silently merge a delayed event into the restart state.
Escalate unresolved differences
The technical lead supplies evidence; the authorized auction decision owner applies the sale’s terms and procedure. Technology staff should not invent a bid ruling.
COMMUNICATION SCRIPTS
Use short, factual language and one approved message.
Do not blame a carrier or platform before the failed layer is known. Do not promise a restart time. Keep the lot and bid record protected while telling bidders what action is required.
- 01
Initial pause — room announcement
“Bidding is paused while the online bid path is verified. The active lot and last accepted bid are being recorded. Please do not place further bids until bidding is formally reopened.”
- 02
Initial pause — remote message
“This ring is temporarily paused while connectivity and the current bid state are verified. Do not rely on bid controls until a resume message is issued.”
- 03
Extended incident update
“The sale remains paused because the bid path or current lot state has not yet completed verification. The next update will be issued through this channel.”
- 04
Verified resume
“The bid path has been restored and verified. We are resuming lot [number] from the recorded bid of [amount]. Bidding will reopen after the auctioneer repeats the lot and amount.”
- 05
Reduced-mode notice
“This ring is moving to the authorized reduced operating mode described in the sale terms. The change applies from lot [number] at [time]. Follow the stated channel for further instructions.”
- 06
Do not use
Avoid “the internet is back, carry on,” “we think the last bid was,” “online bidders can catch up later” or any announcement that declares a result before the record is reconciled.
ROOM-CONTROL COMMUNICATION SCRIPTS
Give the auctioneer language that keeps the room calm and the record protected.
Use a steady delivery, repeat the same verified facts and avoid blaming a provider. The auctioneer should control expectations without suggesting that bids will be accepted during the pause.
- 01
Controlled initial pause
“Ladies and gentlemen, bidding is temporarily paused while our team verifies the online bidding connection. The current lot and last accepted bid have been recorded. Please do not place further bids until I formally reopen bidding.”
- 02
Pause lasting several minutes
“The auction remains paused while the technical team confirms that the room and online bidders can participate through a reliable and synchronized path. No lot will be sold during this interruption. We will provide another update shortly.”
- 03
When the room pressures staff to continue
“I understand that everyone wants the sale to continue. We will not restart until the active lot and last accepted bid are confirmed across the required systems. This protects every bidder in the room and online.”
- 04
Verified restart
“The bidding path has been tested and verified. We are returning to lot [number]. The last confirmed bid is [amount], held by bidder [number or source]. Bidding will reopen when I announce the next increment.”
- 05
Ring suspension or postponement
“The required bidding path cannot presently be verified. To preserve a fair and reliable sale record, bidding on this ring is suspended. The auction team will issue the next instructions through the published communication channel.”
INCIDENT EVIDENCE
Record the facts needed to explain the pause and reproduce recovery.
Keep the record brief enough to complete during the event. Capture the sale and ring, active lot, last verified bid, bidder source, detection time, affected systems, active WAN before and after the incident, change owner, verification result and resume authority.
Preserve relevant screenshots, platform event references, carrier or platform case numbers and the first successful post-recovery action. Do not collect unnecessary bidder personal information in the technical incident log.
FAILURE ISOLATION
Change one layer at a time and keep the frozen state visible.
Start with the narrowest explanation that matches the symptom. A broad reboot can erase evidence, disconnect working systems and lengthen the outage.
- 01
State the exact failed auction task
Use operational language: remote bid not received, operator view disconnected, wrong lot displayed, auctioneer audio absent, platform unreachable or payment path unavailable.
- 02
Check shared power and physical links
Verify UPS state, modem/ONT power, router and switch links, cable seating, intended ports and visible damage before changing software.
- 03
Compare another local station
Determine whether the fault follows one workstation, cable, browser profile or operator account, or affects the whole production network.
- 04
Compare an independent external path
Check the platform or public service through a controlled connection that bypasses the venue WAN. This helps separate local failure from provider failure.
- 05
Restore the known-good production profile
Use the documented browser, account, ring, addressing and device assignments. Avoid updates, new extensions, ad hoc VPNs or account changes during the live incident.
- 06
Move to the rehearsed fallback
When the agreed trigger is reached, stop exploratory troubleshooting and activate the tested backup. Record the unresolved primary fault for post-sale work.
RESUME / REMAIN PAUSED
Reopen only from one verified restart state.
Connectivity is only one resume condition. The auctioneer, clerk, technical lead and authorized decision owner must agree on the lot, last accepted bid, active path and next action.
Read the restart state aloud before bidding reopens. The auctioneer repeats the lot and amount; the clerk confirms the record; the technical lead confirms the bid path; the decision owner gives the resume instruction.
If the first post-recovery bid does not synchronize correctly, pause immediately. Do not continue while attempting to repair the record in parallel.
| Condition | Decision | Required action | Reason |
|---|---|---|---|
| Backup WAN passes the complete remote bid round trip and all required views show the same lot and bid | Resume | Record the backup as the active production path, announce the restart state and freeze nonessential changes. | The critical bid workflow and auction record have both been proved. |
| Internet access returns, but only the operator login has been tested | Remain paused | Run the bidder-side round trip and verify the resulting clerk record. | A login does not prove bid submission, acknowledgment or synchronized result. |
| The platform and clerk disagree on the last accepted bid | Remain paused | Preserve both states and use the documented bid-discrepancy procedure. | Connectivity recovery cannot determine a disputed auction record. |
| Bidding works, but remote audio is unintelligible and simulcast depends on the auctioneer call | No-go for simulcast resume | Restore the primary or simplified verified audio path and repeat the remote test. | Remote bidders cannot reliably understand and respond to the sale. |
| One clerk workstation failed; a warm spare shows the correct production state and passes the bid round trip | Conditional resume | Make the spare the named active station, isolate the failed device and brief the team. | The critical workflow remains available through a tested replacement. |
| Primary and backup WAN are unavailable, and reduced-mode authority is unclear | Remain paused | Escalate to the authorized operations and sale-terms decision owner. | The team cannot invent a participation mode during the incident. |
| The first live bid after resume reaches the wrong lot, wrong amount or delayed queue | Pause again | Return to the recorded restart state and isolate the synchronization fault. | The recovery proof did not hold under the live workflow. |
MINIMUM INCIDENT RECORD
Leave a precise record without slowing recovery.
The form can be paper or digital, but it must remain available if the primary cloud service is part of the outage.
Sale, ring and lot
Sale or event ID, venue, active ring, lot number, catalog position and the production platform or operator profile.
Bid, source and time
Amount, bidder source, bidder identifier where necessary, timestamp source, clerk confirmation and supporting screenshot or event reference.
Failure and recovery path
Affected systems, primary path state, backup path, switch time, device or account changes, measured limitation and support case number.
Pause and resume owners
Who called the pause, who controlled technical recovery, who reconciled the bid state and who authorized the restart or reduced mode.
OPERATING QUESTIONS
Common questions during a live auction outage.
These answers keep the response consistent across permanent rooms, temporary venues, mobile crews and multi-ring simulcast sales.
- Q1
Should staff immediately restart the modem or router?
No. First freeze the lot and last verified bid, define the scope and confirm that the shared WAN path is actually the failed layer. A restart can erase useful status and interrupt systems that still work.
- Q2
Is a successful speed test enough to resume?
No. It proves only one network measurement. Resume requires the correct production sale, lot, bidder-side path, clerk receipt and recorded result.
- Q3
Can a phone hotspot be used as an emergency backup?
Only when it is an approved and tested production fallback with known capacity, charging, coverage, account and routing behavior. An improvised hotspot can introduce unstable upload, session changes and uncontrolled local access.
- Q4
What if internet returns while the team is still reconciling the last bid?
Remain paused. Technical recovery does not establish the correct auction record. Complete the documented reconciliation and define one restart point first.
- Q5
Can another ring continue during the incident?
Only when it is operationally independent and the incident has not affected shared WAN, platform, accounts, audio, clerking, staff attention or bidder messaging. Record the isolation decision.
- Q6
Should staff contact platform support before switching WAN?
Contact support when the evidence points to platform, authentication or wider service failure, or when the approved procedure requires it. Do not wait for support to preserve the lot and bid record or activate a previously authorized local fallback.
- Q7
What should be tested after the backup WAN becomes active?
At minimum: DNS and time, production login, correct ring and lot, remote bid round trip, clerk record, audio/video where used, payment or checkout dependencies and the support communication path.
- Q8
What should staff do when online bidding goes down but floor bidding still works?
Pause the affected lot rather than continuing floor-only automatically. Preserve the last verified online bid, determine whether the cause is a venue internet failure or an auction platform outage, test the approved backup internet connection and apply the published sale terms before any reduced-mode decision.
FIELD RULE
Do not resume because the internet returned. Resume because the auction state and bid path agree.
Pause first, preserve the active lot and last trusted bid, isolate the failed layer, move only to a tested fallback and prove one complete bidder-to-clerk round trip. When the auction record remains uncertain, keep the lot paused even if every network indicator is green.