The Series· No. 50 · Act XII — People & Access

By DocuSeller · Published

Onboarding
DocuSeller · No. 50

The bit where everyone gives up

Software in this category rarely loses on features.

It loses on the first Tuesday.

Somebody opens a blank screen and works out they have three hundred communities to set up by hand.

Several communities queue toward a single setup desk, with an ellipsis indicating more waiting Setup, one community at a timeSetup…Each community waits its turn
Three hundred of these. Alphabetically, apparently.

That's the wall this whole category walks into. Not the product. The setup.

So a lot of the work went into the first Tuesday.

A new community starts as a guided walk-through rather than a screen with ninety empty boxes on it. Five steps: what it's called, who to contact, where it is, the defaults it should inherit, and how it connects to the accounting system. You can stop halfway and come back.

Five named setup stages form a path with a person paused at defaults before connecting the community Five steps, with room to pause1Name2Contact3Location4Defaults5ConnectResume where you left off
Five stones, not ninety boxes. And you may leave the path.

There is one more first-Tuesday job, and it is the one everybody expects to be a phone call: getting set up to take money. Nobody sends us a voided check. You click Connect in settings, fill in the payment processor's own form, and the card moves itself along — waiting, then connected — without anybody refreshing it. While it waits it says in plain words what is still missing: bank account for payouts, company tax ID, business representative. Not the processor's field names.

And afterwards it keeps two lights on, not one. Being allowed to charge a buyer and being allowed to send that money to your own bank are two different permissions, and a store can have the first without the second. So the page shows them separately, names whatever is still outstanding, and the date it is due by.

Then the part that used to eat the week. The units and the owners.

Files and voice become explicitly illustrative draft rows that remain unsaved until reviewed Review before savingFilesVoiceDraft rowsExample14 WillowM. AlvarezNot saved
Whatever you already have, on the left. What you read before saving, on the right.

You don't type those. You hand over whatever you already have — the export from the old system, the spreadsheet a manager keeps privately, a photo of the page in the binder — and it comes back as rows you can edit. Or you talk, and the addresses land as rows while you read them out.

Nothing is saved until you've read it.

The most accurate record in a back office is often a binder. Which is impressive, and also a binder.

Then the part nobody asks for, because it happens on its own.

When a community arrives from a sync, it doesn't land as a row in a table. It lands with its own sellable packages already made, priced off the defaults you set once.

A synced community record passes through configured defaults to produce a ready-to-sell package Sync can provision the storefrontCommunityApplydefaultsPackageReady to sell
The one screen nobody has to open on day one.
Nobody opens a catalog screen. The shop is already open.

Onboarding stops being a data-entry project, which is the only reason any of this gets adopted at all.

Because a platform in this category almost never loses on the demo.

Next up: what happens when a form leaves the building and goes out on a link of its own.

#PropTech · #CommunityManagement · #Automation