Every new account wants the product set up its own way: its own terms, the columns it uses, the views it works from. With Usivity, your team writes that setup in plain language and sends it to the account’s users. Nothing is built, nothing touches your code, and every account stays on the standard product.
This playbook assumes Usivity is already installed in your product. If it isn’t, start with how Usivity integrates with your product.
Before go-live: agree the ground rules
Settle four things with the account, and with whoever manages Usivity in your company, before you send anything.
Which zones are open
Zones are the parts of your product Usivity can change, each named by a CSS selector. They apply to your whole product, not one account. Check that the screens this account cares about sit inside a zone; if one doesn’t, ask your product team to add it.
Which users get Usivity
In the portal’s Access page, Usivity either loads for all users, with exceptions, or only for users enabled one by one. Each user can be switched on or off.
Who sees the Usivity button
Each user’s button visibility is Always, Suggestions only or Never. It decides how the changes you send reach them (below).
What users can do themselves
Full access lets a user create, edit and delete their own personalizations. Review only lets them turn personalizations on or off and apply what your team sends, but not make their own.
Choose button visibility for each user
| Setting | What the user sees | How a change you send reaches them |
|---|---|---|
| Always | The Usivity button, wherever Usivity loads. | It waits in their Usivity panel. They apply it or decline it. |
| Suggestions only | The button only when a change from your team is waiting for a zone on the page they’re on. | The same: they apply it or decline it. |
| Never (silent) | No Usivity button, panel or message. | It applies automatically on their next visit to that page. They can’t undo it. |
One way to split an account: Always for its champions and power users, who will want to personalize for themselves, and Never for users who just want the product set up for them. Access also sets the button visibility for new users, the first time they load your product; existing users keep theirs.
Build the account’s setup
Write the setup as a list of plain-language changes, one zone at a time, the way a user would ask for them. Most of it comes out of the kickoff: the terms the account uses, the columns it never looks at, the views each role works from.
| Zone | Request |
|---|---|
| Deals table | “Rename the Owner column to Account manager” |
| Deals table | “Hide the Forecast column” |
| Deals table | “Sort by close date, soonest first” |
| Pipeline board | “Highlight deals over $50k in green” |
Requests that land
- One change per request. It’s easier to check, and if one can’t apply, the others still do.
- Name what’s on the screen: the column title, the label, the status, exactly as the page shows it.
- Use the account’s words. If they say “Account manager”, rename the column to that.
- Group by role. A manager and a rep at the same account often need different views; send each group its own changes.
Send it to the account’s users
In the portal, open Users and choose Send to users. To send to one person, open their page in Users and send it from there.
- 1
Pick the zone and write the change
Choose the zone the change belongs to and describe it in plain language.
- 2
Find the account’s users
Filter the list by company, name or email, and tick the users who should get it. The count shows how many of them are silent. One send reaches up to 200 users.
- 3
Send to one user first
Send the change to a single user, check that it reached Applied, then send it to the rest. Each user gets their own copy, on their own view.
- 4
Watch the status
Each user’s page in the portal shows every change your team sent them, and what happened to it.
| Status | What it means |
|---|---|
| Waiting | Sent, and not applied yet. For a silent user, it applies on their next visit to that page. |
| Applied | The change is on the user’s view. |
| Couldn’t apply | Usivity tried and couldn’t make the change on the page. The portal says why. |
| Declined | The user chose not to apply it. |
| Withdrawn | Your team took it back before it was applied. |
While a change is Waiting or Couldn’t apply, you can edit it or withdraw it. For a silent user, a change that hits a network problem stays Waiting and is tried again on a later visit.
Setups you repeat across accounts
After a few accounts, the same requests come back: the same renamed labels, the same hidden columns, the same highlights. Keep them as your standard setup.
Keep a standard list
Write the requests every new account gets, zone by zone, in your onboarding plan, in the order you send them.
One list per kind of account
If your segments work differently, keep a list for each, and add the account’s own wording at the kickoff.
Paste, adjust, send
For each new account, start from the list, change the words to theirs, and send.
Let Reports prune it
If a change from the list is often turned off or declined, drop it. If users keep adding the same one themselves, add it.
Go-live checklist
Before you call the account live
- The screens the account uses sit inside zones.
- The account’s users are enabled in Access, or Usivity loads for all users.
- Your app passes each user’s company, so you can find the account’s users.
- Each user’s button visibility is set: Always, Suggestions only or Never.
- Each user’s capability is set: Full access or Review only.
- The setup is written as one change per request, within what Usivity does.
- Each change was sent to one user first and reached Applied.
- The setup is sent to the rest of the account’s users.
- No change is left at Couldn’t apply without a fix or a note.
- Users who see the Usivity button know what it is and how to ask for a change.
After go-live: read the Reports
The portal’s Reports show how each account takes to Usivity and what its users change. Check them in the account’s first weeks, and before handover.
Accounts
For each account: its users, how many were active in the last 30 days, the share who personalize, their personalizations, the share still on after 14 days, the top theme and the last activity. Click one for its full picture.
Suggestion outcomes
The changes your team sent, how many were applied, and how many are still on: whether your setup landed, and stayed.
Most requested changes
What users personalize most, by category. When the same change comes up account after account, add it to your standard setup, or take it to product as a default.
Requests your product couldn’t do
What users asked for that the product can’t do yet. Pass these to your product team.
Data users add
Fields from your data sources that users add to their views: candidates to show by default.
Might need help
People who asked for what the product can’t do yet, or turned their own personalizations off. A quick call now saves a harder one later.
Hand over to Customer Success
Customer Success inherits an account that already has its setup, and a record of what was sent. Give them what they need to carry it on.
What to hand over
- The setup you sent, and to whom. Each user’s page in the portal shows how many changes your team sent and what happened to them: still on, turned off or declined.
- Which users are silent, and why. They never see the Usivity button, so they can’t ask for changes themselves; Customer Success sends changes for them.
- Anything that couldn’t apply, and what you did about it.
- Requests the product couldn’t do, and where you passed them.
- The account’s adoption at handover, from the Accounts report, as a baseline for the first QBR.