When your restaurant website is unavailable or shows the wrong content, start with the person or company responsible for the website. If the problem appears to involve the domain or hosting, contact those providers too. Your first internal call should be to the person who can approve changes and reach the account owners.
Those roles may belong to one company or several. The useful preparation is to name them before something goes wrong, record how to reach them, and decide who can authorize a correction. Keep the list somewhere staff can access even when the website is down.
Identify the people behind the site
Start with the company or person who edits your restaurant website. That might be a website provider, an agency, a freelancer, or someone on your staff. Ask who handles an incorrect menu, an outdated phone number, or a page that displays unexpectedly.
Next, identify the host: the provider responsible for serving the site. Your website provider may arrange hosting for you, or you may have a separate account. Record both the host and the person authorized to contact it. If you do not know who hosts the site, ask your website provider or the person who pays the relevant bills.
Then identify the domain registrar, where the restaurant's domain is registered. The registrar is not necessarily the company that built or hosts the site. Record the account owner and the domain renewal contact. Also ask who manages the domain's DNS settings, which direct visitors to services associated with the domain. That responsibility may sit with the registrar, host, website provider, or another company.
Finally, map services that visitors reach from the site. An online ordering link may lead to a separate provider, for example. If the website opens but ordering does not, the ordering provider and the person who manages the website link may both be relevant.
Do not guess who controls an account based on a logo or an old invoice. Ask each provider what it manages, which account belongs to the restaurant, and how an authorized person should request help. The domain ownership guide can help you frame the account ownership questions.
Record support channels and account owners
For each service, record the provider's name, the restaurant's account owner, the support channel, and the hours when that channel is available. Use contact details obtained directly from the provider's account portal or official materials, and check that the account owner can actually access the support route. A phone number is not useful if only a different account holder can authorize help.
Include an alternate contact when possible. A freelancer may know the site well but be unavailable during dinner service. A provider's support portal may be available outside business hours, but the response time may differ by plan. Ask how urgent issues are handled and what information support needs to locate the account.
The table below is a hypothetical example for a restaurant whose website, hosting, and domain are managed separately. Replace the roles and channels with your own verified details. The escalation column tells the shift manager what to do if the first contact cannot resolve or accept the issue.
| Responsibility | First contact and channel | Account owner or approver | Escalation |
|---|---|---|---|
| Website content and links | Website editor; provider support portal | Restaurant owner approves public changes | Contact the website provider's support team if the editor is unavailable |
| Hosting and site availability | Host support through its account portal | Operations manager holds the hosting account | Ask the website editor to coordinate with host support |
| Domain and DNS | Domain administrator; registrar support portal | Restaurant owner holds the domain account | Owner contacts registrar if the administrator cannot access the account |
| Ordering service | Ordering provider's support channel | Operations manager holds the ordering account | Ask the website editor to check the link while provider support checks the service |
In your working copy, add the actual phone numbers, portal addresses, account identifiers that are safe to share, hours, and backup contacts. Include the date each entry was last confirmed and the person responsible for reviewing it. Keep personal contact details limited to staff who need them.
Set the escalation and approval rules
A contact list should answer two questions: who investigates, and who gets to approve the fix? The person who notices a problem may not have the authority to change a menu, redirect a domain, or approve a provider's paid work.
Give the shift manager a clear first action: record what is wrong, tell the designated incident lead, and contact the appropriate provider if authorized. The incident lead coordinates the response and keeps the owner informed. Name an alternate lead for days off and busy shifts.
Set different approval rules for different changes. A manager might be allowed to correct a published phone number against an approved reference. A domain change, a new page, or work carrying an extra charge might require the owner's approval. Tell providers who can give that approval and how they should confirm it. Ask what happens if the primary account owner cannot be reached.
Consider a separate hypothetical incident: a guest reports that the menu page shows an old closing time. The shift manager checks the page and the restaurant's approved hours, records the page address and time, then alerts the incident lead. The lead asks the website editor to correct the hours after the designated approver confirms them. The lead checks the published page and records the outcome.
If the whole site is unavailable instead, the lead can contact the website provider first and involve the host or domain administrator as needed. If ordering alone fails, the ordering provider becomes an early contact. The lead should describe the symptoms rather than instruct someone to change DNS settings based on a guess.
Decide when to escalate an unanswered request: for example, after the restaurant's chosen response window has passed, or sooner if a service interruption is affecting guests. Record the next person and channel, not just the word “urgent.” If a provider proposes a charge, obtain a written quote and approval before work begins.
Practice the list without exposing secrets
Keep the contact list separate from passwords, recovery codes, payment details, and other secrets. It can say where an authorized person should find account access instructions, but it should not contain the credentials themselves. Use your normal secure method for storing access details, and restrict access according to each person's role.
Run a short tabletop exercise before you need the list. This is a simulation, not a live service pilot: no one changes the website, sends a guest message, places an order, makes a payment, or dispatches a courier. Use an invented symptom, such as an incorrect menu item, and have the team talk through these steps:
- Identify who receives the report and who becomes incident lead.
- Choose the first provider contact from the list and explain why.
- Find the named account owner and the person who can approve the proposed correction.
- Describe what to record: affected page, observed problem, time, and the support case reference if one exists.
- Choose an escalation if the first contact is unavailable, then identify who checks the correction and closes the incident.
The exercise checks whether the instructions make sense; it does not prove that a provider will respond or that a correction will work. Separately, an account owner can confirm access and support details through normal provider channels without submitting a simulated incident as a real one. Update the list after staff, provider, account, or contact changes, and review it on a regular schedule.
Use the checklist to map your current setup. If you are evaluating a change, review the restaurant website builder comparison, then ask Fleksa about its restaurant website and verified US availability. Ask who would manage the domain, support requests, and approved edits in your particular setup.
Frequently asked questions
Who should I call first if the whole website is down?
Start with your website provider or designated website contact, and notify your internal incident lead. Bring in the host or domain administrator if the symptoms or provider's response point to their area.
Who should approve a correction to the website?
Name an owner or manager in advance, with an alternate. Set rules for routine corrections, domain changes, and work that may incur a charge, and tell providers who can authorize each type.
Should the contact list include passwords?
No. Record the account owner and the secure location of access instructions instead. Keep passwords and recovery information in your normal protected credential storage, available only to authorized people.
