When Tabledoo support signs in as you
What this covers
Tabledoo support can open your workspace to investigate a problem. This explains exactly how that works, what is recorded, and where you can see it. No special permission needed — every member of staff is entitled to understand this.
Why it exists
Some problems cannot be diagnosed from a description. "The 19:30 slot isn't showing for a party of four next Tuesday" depends on your tables, your hours, your durations, your pacing and your existing bookings all at once. Support can either ask you twenty questions and guess, or look at the actual screen.
So support can sign in to your workspace and see what you see. It is the difference between a problem solved in ten minutes and a week of emails.
What actually happens
Support opens your workspace as one of your own staff accounts — specifically the oldest account in your restaurant, which is normally the Owner. They do not need and never see your password; they are placed into a session as that account.
From there, they see precisely what that account sees: your bookings, your guests, your settings, your reports. And that account's permissions apply, so they are working under the same rules your own staff are.
The four guarantees
1. A banner is visible the whole time
A yellow banner sits at the top of every page for the entire session, saying the workspace is being impersonated, with a button to leave. It cannot be dismissed or hidden.
Its real job is to make it impossible for a support agent to forget where they are — and it means any screenshot they send you carries the banner, so you can see for yourself that what they were looking at was your workspace during a support session.
2. It appears in your own audit log
This is the guarantee that matters most, because it is the one you can check without asking anybody.
The session shows up in Property Settings → Audit log as a sign-in, carrying an extra note identifying it as a support session and which support person it was. The sign-out is recorded the same way (link The audit log).
Worth knowing how to read it: it is not listed as a separate "impersonation" event type. It is a normal sign-in event with an additional property attached, so if you are scanning event names for something that says impersonation you will not find one. Look at the sign-in entries and their detail.
The reason this exists is a good illustration of the intent. Without it, your audit log would show your Owner account signing in from an unfamiliar address at three in the morning — and you would reasonably conclude you had been broken into. The marking is there so your own security review is not misled by your own support request.
3. Tabledoo keeps its own record
Separately from your log, the start and end of every support session is recorded on Tabledoo's side against the individual agent. So the accountability does not depend on your noticing.
4. It ends explicitly
The agent leaves by pressing the button in the banner, which signs them out of your workspace and returns them to their own tools. The session does not linger.
What support will and will not do
| Will | Will not |
|---|---|
| Look at the configuration causing your problem | Read your guest list for any reason other than the problem you reported |
| Reproduce what you described | Change your settings without telling you |
| Check a setting you were asked about | Create, change or cancel bookings on your behalf unless you asked |
| Tell you what they found and what to change | Contact your guests |
| Make a change you explicitly asked for | Touch your billing or payment details |
If a support session results in a change you did not ask for, say so — and the audit log will show what happened and when.
Two things worth knowing
The network restriction does not apply to support
If you use an IP allowlist, support is exempt from it. That is deliberate: the allowlist protects you from a leaked password, and it should not prevent the person you asked for help from helping you — especially when a misconfigured allowlist is quite often the thing you are asking about (link Restricting sign-in to your venue's network).
Your two-factor code is not needed
Support is placed into a session directly, so two-factor on the account does not block them. Two-factor protects against somebody with a stolen password; it is not intended to lock out your own provider.
That is worth stating plainly rather than leaving you to discover it. The protection against misuse is not that support cannot get in — it is that every session is marked in your log, recorded on Tabledoo's side, and visible on screen while it happens.
If you would rather it did not happen
There is no switch to disable it. What you can do:
- Ask. Tell support you would prefer to share screenshots or a screen-share instead, and say so when you report the problem. Many issues can be solved that way.
- Check afterwards. Look at your audit log after any support conversation. That is the point of the marking.
- Ask what they looked at. A reasonable question, and you are entitled to an answer.
Good to know
Your guests are never affected, and nothing about a support session is visible to them.
It does not change your password or lock you out. You can keep working while it happens, in your own session, unaffected.
The banner is on the support agent's screen, not yours. Your own session looks completely normal — which is why the audit log, not the banner, is how you check.
A support session is not a substitute for reporting the problem. Describe what you expected and what happened; the session is how they confirm it, not how they discover it (link Reporting a problem).