How a new client joins the platform

Before LeadRefinery calls one merchant in the name of a client, two things must occur. The client signs the Platform Services Agreement. Then the admin of the client enters the facts that the calling agent needs: who the client is, where a ready merchant goes, and where replies land. This page explains that journey. It also explains how the platform keeps the signed agreement, and who can open it.

Why a client must set up before the first call

The setup exists for two reasons. The agreement is the contract between the client and LeadRefinery. Each call the platform makes, and each text it sends, is made in the name of the client under that contract.

The setup also gives the calling agent the facts it needs:

the legal identity of the client, which the platform prints on emails and texts;
the phone line to which a ready merchant is transferred;
the link to the funding application;
the inbox where merchant replies land.

Until the client accepts the agreement and completes the setup, the team of the client sees only the setup. Nobody can upload leads.

The journey, from invitation to open app

The journey has five stages. LeadRefinery staff do the first two. The admin of the client does the rest:

Staff create the organization. Staff create the organization of the client and upload the agreement PDF of the client. The platform publishes the agreement at once, because the invitation that follows must find it.
Staff invite the admin. Staff send the invitation to the admin of the client by email. The admin sets a password and signs in.
The admin completes a 5-step setup. The admin sees a welcome screen. Then the admin sees a 5-step setup in one window over the app:
1. Accept the agreement. The admin reads the PDF, types a name and a title, ticks the box, and presses “I agree”.
2. Business details. The legal name, the trade name (DBA), the state of formation, the business type, the website, the address, the phone number that merchants see, a logo (optional), the invoices email, and the legal-notices email.
3. Live transfer line. The phone number to which a ready merchant is transferred, the days (weekdays only) and hours when a person answers, and the time zone.
4. Funding application and inbox. The link that the agent sends to merchants, and the team inbox.
5. Text messages. The details that the phone carriers need before a business can send texts: the federal tax number (EIN) and a contact person. The admin presses “Submit for approval”.
Each step saves when the admin presses Next or Back. The platform remembers the step the admin was on. If the admin comes back a week later, the setup opens on the same step. Later steps stay locked until the earlier steps are done.
The app opens. When the admin submits step 5, the window closes and the app opens. Everything the admin entered stays in Settings. The admin can change it there later.
Teammates wait. Teammates (members) who sign in before the admin finishes see one line: “An admin at <company> is finishing setup”. They see nothing else.

The journey of a new client, left to right. LeadRefinery staff create the organization and upload the agreement, then invite the admin by email. The admin signs in, sees a welcome screen, and completes a 5-step setup in one window over the app: accept the agreement, business details, live transfer line, funding application and inbox, text messages. After step 5 the window closes and the app opens. A side branch shows that a teammate who signs in early sees only a waiting line. — Follow the hand-offs: staff do the first two stages, the admin does the setup, and the app opens only after step 5. Note the side branch for a teammate who signs in early: that person sees one waiting line and nothing else.

What each number and address is for

The setup asks for several phone numbers and email addresses. Each one has exactly one purpose:

Field	What the platform does with it
Live transfer line	A ready merchant is transferred here. Callbacks ring here. The agent reads this number out when a merchant asks how to call back.
Phone number for merchants	The platform prints this number on the emails and texts it sends in the name of the client, next to the postal address.
Team inbox	Replies to the application email land here. The outcome alerts land here too: booked, transferred, callback, callback ASAP, do-not-call request, and not interested. The own address of the admin works without a confirmation code. Any other address must confirm a 6-digit code that the platform emails to it.
Send invoices to	The address to which LeadRefinery sends invoices.
Send legal notices to	The address named in the agreement for formal notices.
Carrier contact (name, email, phone)	The platform puts this contact on the toll-free verification form. The phone carriers require this form before a business can send texts.

The life of the agreement

Each client organization has one agreement, in numbered versions (1.0, 1.1, and so on). The rules for a version are strict:

Staff upload a version as a draft, then publish it. Only one version is “current” at any time.
A published version is never edited. A mistake means a new version.
The very first version locks the whole app until the admin accepts it: nobody on the client's team can use any screen before that first acceptance.
When staff publish a newer version of an already-accepted agreement, the admin must accept it again, but only new lead uploads pause until then. An amber banner tells the admin uploads are on hold; the rest of the app keeps working.
The older version is retired. It stays on record together with the acceptance it collected. Nobody is asked to accept it any more.

The agreement runs for a fixed term, then continues month to month: 6 calendar months from the client's first real call, or 4 months from acceptance if the client never places one. A rehearsal call, a demonstration call, and a call a staff member forces past the gate for a test never start this clock; only a real call to a real person does.

Staff can also add a second, separate document for an extra service — an “add-on” — after the main agreement is accepted. The admin reviews and accepts or declines each add-on on its own banner. Accepting or declining an add-on never locks the app and never holds uploads; only the main agreement's own first acceptance and its later versions do that.

Both sides can see the agreement at any time:

Staff see every version on the Agreement tab of the organization: the status (draft, published, retired), the effective date, who uploaded it, and whether it was accepted. Staff can view or download any version.
The client sees the accepted agreement under Settings → Agreement, with who accepted it and when. The client can view or download it at any time.

The states of one agreement version: draft, then published, then retired. Only one version is current at a time. When a newer version is published, the older one moves to retired and keeps its acceptance record, while the gate reopens for the admin of the client with a new-version notice. The first-ever version locks the whole app until accepted; a later version only pauses new lead uploads. — One version moves in one direction only: draft, published, retired. Note that a retired version keeps the acceptance it collected, and that a new published version reopens the gate for the admin — locking the whole app only the first time, and only new uploads after that.

What “accepted” means

The platform writes one acceptance record for each company and each version. The record holds:

Which document. The title, the version, and a fingerprint of the exact PDF. A changed file can never pass for the signed one.
Who accepted. The email and display name of the signed-in admin, the name the admin typed, the title the admin typed, and the role of the admin at that time.
When and from where. The time to the second, the internet address, and the browser.
The exact words. The words of the checkbox as the server rendered them on screen, and the template version of those words. The browser never supplies the text. The server writes down what it showed.

Directly after acceptance, the platform emails a copy of the signed agreement to the admin. The platform records whether the email went out.

The agreement log

The platform also writes each event along the way to an agreement log:

a document is uploaded, published, or retired;
the gate is shown to a person;
the document is viewed or downloaded;
an acceptance is submitted, recorded, or rejected;
a member is shown the waiting screen;
re-acceptance is required;
the copy is emailed, or the email fails;
the “agreement ready” email goes to the admin;
each lead upload is attested;
the admin is notified.

One acceptance record and its four parts: which document (title, version, fingerprint of the PDF), who accepted (signed-in identity, typed name and title, role), when and from where (time to the second, internet address, browser), and the exact words of the checkbox as the server rendered them. Beside it, the agreement log lists each event from upload to notification. Both are marked append-only: the database refuses changes and deletions. — The four parts of one acceptance record, and the log beside it. Note the lock on both: once written, a row can be neither changed nor deleted, not even by the platform.

Where the signed PDF lives, and who can open it

The signed agreement is kept apart from everything else, and only the platform can hand it out:

The PDF goes into its own locked storage area, separate from the lead files. This area keeps every version. A stored file can be neither overwritten nor deleted. The storage client of the platform has no delete command at all.
The platform keeps agreements for at least 10 years. LeadRefinery can set a longer period, but not a shorter one.
Access is only through the platform, only while signed in, and only to the agreement of your own organization. The admin and the members of the client open it under Settings → Agreement. LeadRefinery staff open it on the Agreement tab of the organization.
The platform streams the file to the browser. There are no public links and no share links. The platform logs every view and every download.
The walls between clients apply here too. A record can never point at the document of a different client. The database enforces the pairing.

The signed PDF sits in its own locked storage area, apart from the lead files, with every version kept and no overwrite or delete possible. The only path to the file goes through the platform: a signed-in admin or member of the client, or a LeadRefinery staff member, asks the platform, the platform checks the organization, streams the file, and writes a log entry. No public link exists. — There is exactly one path to the signed PDF, and it runs through the platform. Note what is absent: no public link, no share link, no delete command.

The gates: what stays closed until setup is done

Each client organization has a switch named “Onboarding gates”. The switch is on by default. LeadRefinery staff can turn it off on the General tab of the organization, for example for an internal test organization. Demo organizations never gate.

With the gates on, three things stay closed:

The setup window stays over the app until the admin accepts the agreement and completes the 4 setup steps.
Members wait on the waiting screen.
Nobody can upload leads. The Upload leads page refuses with a plain message that names what is still missing.

After the setup is done, the Upload leads page asks the admin one question at every upload. The admin must confirm that the people on the list gave consent to be contacted. The platform records that confirmation with the list: who confirmed, when, and the exact wording.

Change history

The platform writes down each change to the setup of the client, for example a new transfer number, a changed inbox, or a new application link. Each entry holds:

who made the change;
when;
the old value and the new value;
whether the change came from the setup or from Settings.

The client reads this history under Settings → Agreement. Staff read it on the organization.

Text messages: what occurs after “Submit for approval”

The phone carriers verify each business before it can send texts from a toll-free number. Today LeadRefinery staff do this by hand:

Staff buy a toll-free number for the client and assign it to the organization, in its own field apart from the dialling numbers. Texts go out from that number and from no other; a client without one cannot be texted for.
Staff submit the details of the client to the carriers.
Staff record the result on the organization: submitted, approved, or rejected with the reason. The client sees the result and the number under Settings → Text messages.

Calls and emails work while the client waits. Texts to merchants start when the approval is in.

The technical bit, translated

Hetzner Object Storage, in Finland, holds the agreement PDFs in a bucket of their own. The bucket has versioning and object lock. The application holds no delete right. The platform needs this because a signed contract must stay exactly as signed, for years. Lead files stay in the lead storage.
PostgreSQL holds the acceptance records and the agreement log as tables with insert-only rules. An update or a delete raises an error for every role, including the own role of the application. The platform needs this because the evidence base must not change after the fact.
Resend is the email service that sends the copy of the signed agreement to the admin. The platform logs the send result. The platform needs this because the client must hold a copy, and the record must show whether the copy went out.
Encryption at rest protects the federal tax number (EIN) from the text-messages step. The application holds the key. Only the last 4 digits are ever shown again. The platform needs this because the number is sensitive, and nobody needs the full number on screen after submission.