What to post when your business website is down

How should you find which customer tasks actually fail?

Open the public site on a phone without an admin session and try the tasks a customer would attempt. Check the home page, service details, booking, order status, payment, contact and support routes separately. A home page can load while a checkout or calendar fails. Conversely, a temporary image error is not proof that paid orders are missing. Record the observed URL, time, timezone, device and error for each task, then ask the website operator what is known. Keep unverified cause, data exposure and recovery estimates out of the public draft.

The content team needs an operational owner for each customer path, not just a screenshot saying the site is down. A customer with an existing appointment may need a different route from someone seeking a new slot. If the business cannot reliably confirm whether a payment completed, route that case to private support and tell people not to retry blindly. Never ask for payment details in public comments or direct messages managed by an unapproved provider. A public post should be specific enough to help without becoming an improvised incident report.

How should you fill a seven-state outage and fallback record?

Copy seven fields into one private row per affected task: customer task and failing URL; first observed time; current tested status; working fallback and its capacity; owner of the fallback; approved public message and next update time; and recovery test plus correction owner. Mark a field unknown instead of guessing. A fallback is working only after someone follows it as a customer and a named person is ready to receive the resulting call or message. A phone number with an unanswered voicemail is not a booking replacement unless the owner approves that expectation.

Use the record to choose a narrow notice. If existing appointments remain valid but new booking is unavailable, say exactly that after the calendar owner confirms it. If all customer routes fail, say what is known and when the next update will be posted, without implying that a social inbox can process an order. Keep the source of each claim beside the text that depends on it. This makes a later correction possible when the incident changes and keeps the social manager from treating a single early status message as permanent.

How should you decide whether to post, narrow the post or hold it?

A useful notice answers three questions: what action is affected, what the customer can safely do now, and when the business will update them. Publish when the operating owner has verified those facts and the fallback can handle likely contact. Narrow the wording when only one route is known to fail. Hold claims about cause, security, refunds or recovery time until the responsible team can support them. The FTC’s advertising guidance applies to the overall impression of customer-facing claims; an optimistic image can contradict a careful caption.

A sample structure is: ‘Our [verified booking route] is currently unavailable. Existing [confirmed appointment type] remains [owner-approved status]. For [specific urgent task], use [tested staffed route]. We will check again at [time and timezone].’ Replace every bracket with a checked fact or remove the sentence. The notice is not a substitute for direct contact with customers whose existing orders or appointments are affected. The owner decides that outreach through the normal private service channel and keeps personal details out of comments.

How should you reconcile scheduled posts and platform destinations?

Inventory scheduled feed posts, stories, bio links, pinned posts, Business Profile updates and paid creative within the team’s control. Pause any asset that still says ‘book now’ or points to a broken form. Changing a bio link does not update a previous story or a Google post. Google’s Business Profile guidance says Update posts can include an action link and can be edited or deleted, while visibility depends on the post’s live, pending or not-approved status. The manager should inspect the customer-facing result rather than assume a scheduled update appeared.

If the site’s primary URL is failing, do not replace it with an unverified short link or a form in a personal account. Use a business-controlled, approved fallback and test it on a phone. Approve the full image text, caption, alternative text, profile, posting time and destination together. If the fallback capacity is limited, avoid inviting more requests than staff can process. An outage notice should route a customer to help, not create a second queue nobody owns. Keep a record of every changed surface for the recovery pass.

How should you rehearse a failed-booking path?

Imagine a fictional neighborhood salon whose home page loads but booking returns an error. One customer already has a Friday appointment, while another is trying to reserve a Saturday slot. The social draft says ‘Our website is down; message us to book anything.’ These people and dates are invented to demonstrate the record, not Lumora customer evidence. The calendar owner confirms Friday appointments remain in the system but cannot confirm that social messages create new bookings. The proposed caption would overpromise a replacement route.

The owner approves a narrower notice: existing Friday appointments remain on the confirmed calendar; new online booking is unavailable; a staffed phone line can answer availability questions but cannot hold a slot until staff confirms it. The manager tests the phone number, updates the caption and image together, pauses a scheduled Saturday promotion and sets a timed recheck. If the phone line also fails, the fallback field becomes unknown and the post changes again. This drill tests consistency of the customer path; it does not estimate lost bookings or prove any particular outage cause.

How should you close the notice only after the customer path recovers?

When the website operator reports a fix, repeat the original customer tasks from outside the admin session. A home page returning is not enough: test booking confirmation, contact receipt and payment or order status through the business’s safe test method. If a task cannot be safely tested, mark it unverified and keep the corresponding public claim narrow. Correct pinned and queued notices, restore links deliberately, and state when customers can use the normal route again. Give affected existing customers direct help where their case requires it.

Google Search Central documents temporary 503 responses for short maintenance windows, but the site operator decides the technical response and duration; the social team should not improvise server settings. Use the booking-link migration guide when the destination changes permanently, and the closure guide when the business itself cannot operate. When comparing a managed-content plan, ask who verifies source facts, pauses old creative, approves the notice, monitors replies and closes the loop. Track working routes, qualified inquiries, confirmed appointments and paid orders separately from post reach.