Why I stopped asking customers to email me a login

A GravityView ticket comes in overnight. The bug report is real, but the description alone isn’t enough to work from. Someone needs to see the actual site: the form configuration, the view settings, whatever theme or other plugin is fighting with ours. There’s no way to know without logging in.

This is what that cost, before I built anything to fix it. A customer submits the ticket around midnight. Our agent reads it in the morning, confirms a login is needed, and emails back asking the customer to create one. The customer replies with a login hours later, often after we’ve already moved on to the next ticket. Sometimes the account doesn’t work: a typo, the wrong role, a security plugin that blocked the new user. Another round of emails. Four emails and most of a working day gone, and nobody has touched the bug yet.

I run GravityKit. I also built TrustedLogin. The second one exists because of the first.

Abandoned support accounts kept turning up months later

I didn’t start out trying to build a product for other WordPress companies. I was trying to stop writing that fourth email. Before any of this existed, “I need to log in” meant asking a customer to create an account, hoping the instructions were clear enough, and hoping they’d remember to delete it afterward. Most didn’t. I’d find abandoned support accounts on customer sites months later, accounts nobody on either side remembered creating.

GravityKit ships GravityView and add-ons for Gravity Forms, and Foundation, the shared library every GravityKit plugin runs on, now has the TrustedLogin SDK built in: the code that puts the access button inside a plugin. Every GravityKit plugin ships a Grant Support Access screen inside the plugin itself. No separate download, and no second install standing between the ticket and the fix.

2,589 logins across 1,789 customer sites

Since August 2024, when we started keeping the event log, GravityKit’s support team has logged into customer sites 2,589 times, across 1,789 different sites. Lately that’s running about 38 logins a month. None of those needed an emailed password, and none left a standing account behind for someone to remember to delete later. The event log only goes back to August 2024 because that’s when TrustedLogin started recording it. We’d already been running this flow on our own tickets before the record starts.

The agent clicks a link in Help Scout and lands in wp-admin

A ticket that needs a site login arrives in Help Scout. The agent replies asking the customer to click Grant Support Access from inside GravityView’s settings, with a line telling them where the button is. The customer clicks it. A “Log In” link shows up in the Help Scout sidebar, right next to that conversation. The agent clicks it, lands in wp-admin already signed in, reproduces the bug, and replies with a fix or a follow-up question, in the same thread. No second tab, no separate dashboard, no “did you get my email.”

The role and duration are fixed, and the log runs out at 90 days

A product described only in its best light is not one I would trust either, so here are the limits.

The role and duration a customer sees aren’t chosen per ticket. They’re fixed at the product level, set once when we configured the SDK. An agent who needs Administrator for one ticket and Editor for the next doesn’t get to ask for that. Every grant GravityView issues looks the same, every time.

Expiry runs on the customer’s own site, on their own WordPress cron, rather than on a schedule we control. And the credential itself never passes through anything we operate: it’s encrypted before it leaves the customer’s site, and the only thing that can decrypt it is a key that lives on GravityKit’s own site, inside the Connector plugin. The key sits on GravityKit’s own site rather than on the customer’s or on TrustedLogin’s servers.

The customer still has to click. Nothing in this removes their consent from the process or logs an agent in without them knowing. If they don’t respond, the ticket waits exactly as it did before, just without a password changing hands while it does.

The audit trail (who logged in, to which site, when) is kept for 90 days. Older sessions aren’t retrievable.

A one-off tool does not hold up across an install base

Free options exist for the one-off case: a plugin the customer installs, generates a login with, and deletes when they’re done. That’s a reasonable answer if a login request lands once a quarter.

GravityKit gets that request across an entire install base, every week. A one-off tool doesn’t hold up there. It is one more plugin the customer has to install before troubleshooting starts, so the ticket that needed a login now needs a second plugin too. I also wanted one record across every grant, rather than a login history scattered across whichever plugin each customer happened to have installed, at whichever version. And a standing account nobody remembers to remove is exactly the kind of unmanaged credential that turns into an incident later, which was the thing to avoid from the start.

None of that is a knock on the free temp-login plugins. For a shop that logs into a customer’s site once a season, installing one, generating a link, and deleting it when the ticket closes is the right amount of tooling. A support team doing this every day, across 1,789 sites, needs the plugin itself to log the grant and enforce the expiry. Building the login into the product we already ship meant every customer got the same request, logged and expiring the same way, without a second install standing between the ticket and the fix.

AI agents get the same rules next

We’re extending the same access rules to AI agents next: a scoped account that expires on schedule and can be revoked like any other session.

Whenever a customer asks now, someone on our team is in the site within minutes, fixing instead of describing, with a record that they were there. If your team is still waiting on customer emails for a login, see how TrustedLogin scopes support access for plugin and theme vendors.