support is eating my whole day and im finally ready to hand the inbox to a VA, but im nervous about access. i do not want to give a contractor i met two weeks ago my full platform admin, the payment dashboard, or customer records. how do you actually scope a support person so they can answer tickets without being able to touch everything? what did you give them and what did you hold back?
scoped roles are pretty standard now, you do not hand over the master login. give them a seat in the helpdesk tool with a support role, not platform admin, and keep billing and anything that touches payouts on your own login only. the inbox is the job, the keys are not part of the job.
get the access scope written down, not just agreed verbally. who can see what, and the offboarding steps for the day they leave. a friendly i will only look at tickets means nothing the week they get curious or the week you part badly. list every credential they touch so you can kill it cleanly.
Ten minutes setting up a redacted support seat saves you a bad week later. If your helpdesk supports it, give them a role that masks card data and full customer records entirely. Push for least privilege, they should be able to resolve a ticket without ever seeing a payment method or a full identity record.
The scoped helpdesk seat is the piece I was missing, thank you. I was about to just make them a second admin because it was the fast option, and I very nearly did it because the person seemed nice.
also look at what the tool actually shows by default, some helpdesks surface the full customer profile, order history, even partial payment info right on the ticket. big difference in how much a support role can see even when its not technically admin. ask the tool to spell out what that role exposes.
What the role exposes by default is a great question and my helpdesk docs do not say clearly. Checking the role permissions now.
its almost always more than you think. assume the support role can see customer data until you have proven otherwise, and turn off anything it does not strictly need. people get caught treating a non admin seat as if it were safe by default.
Closing the loop. Set up a dedicated support seat with billing and payouts locked to my login, customer records masked, an NDA signed, and a written offboarding checklist. Appreciate the push to not just hand over admin, that would have been a real exposure.
scoped seat is step one but dont stop there, put the va behind your own identity provider or at least sso with your own 2fa policy, so when they leave you kill one account and everything theyre in dies with it. a pile of separate logins to rotate on offboarding is how access quietly lingers for months after someone goes.
single sign on for contractors is underrated specifically for the offboarding story. ive seen operators still have a departed vas login active a year later because it was one of nine separate tools nobody was tracking. one identity to revoke is worth the setup pain.
from actually doing support work, give the va a sandbox or a handful of test tickets first before any real customer data. you find out fast how they handle a tricky case and whether they respect the boundaries you set, and you learn it on fake accounts instead of in front of your real customers.
if any of your customers are in the eu you have a data processor relationship the moment a va touches their data, which means a written agreement isnt just good practice its required. a one page dpa with the contractor covers you, and skipping it is the sort of thing that only matters on the one day it really matters.
I did not think about the processor angle at all and I do have EU customers. So the NDA I was planning is not enough on its own, I need an actual data processing agreement too. Adding that to the list, thank you, that is exactly the kind of thing I would have sailed straight past.
yes, and keep it simple, a short dpa naming what data they process and the security expectations is fine for a solo contractor, you dont need a law firm for this. the mistake is having nothing, not having something imperfect. template it once and reuse it for every contractor after.
test what the support role actually exposes by opening a ticket yourself logged in as that role, dont trust the permission labels. i found my helpdesk showed full billing history on the customer sidebar even under a restricted role, the label said limited and the screen said everything.
I just did this, logged in with the restricted role and opened a ticket, and you are right, it showed more than the label implied including partial payment info on the sidebar. Turning that off now. Checking by actually looking beats reading the docs, which were vague on exactly this point.
Keep anything that can move money entirely off the va seat, not just restricted but absent. Refunds especially. A support role that can issue refunds is a social engineering target and a standing temptation. Refund requests come to you or go through an approval step. Support answers, you authorize the money.
the refund point is bigger than it sounds. refund fraud through a careless or compromised support seat is a real pattern, someone sweet talks the va into a refund to a different method and youre out the money and the goods both. route refunds through yourself even when its slower.
boring process thing that saved me, write the actual answers to your top twenty tickets into a doc before the va starts. most support is the same handful of questions and if they have canned correct answers they need less access to figure anything out, and they ramp way faster. the knowledge base shrinks how deep into your system they ever need to go.