Seller Portal

The Seller Portal is a web app built for the phone of a field seller. From it, a seller opens their customer book, checks whether a customer qualifies for credit, builds an own-financing simulation with its payment plan and hands the customer over to a bot to finish the application. Sellers have no password: they get in with a personal access link or a one-time code, and the portal lives at an address of the form /{tenant}/seller.

What the Seller Portal Is

Think of the portal as a thin front end that you configure from the Hub. The seller never decides which evaluation runs, which bot greets the customer, which origination fee and taxes apply or how long a session lasts. Every one of those rules is set by an operator in the Hub, and the portal only shows the seller the result. When something is missing, the portal says what is missing and that an administrator has to fix it, instead of letting the seller pick a substitute.

Each time the portal opens, it learns who the seller is, which routes they cover (sorted by name, up to 200), what is actually enabled for the organization, how the organization configured the portal, and its branding: the logo and the primary color. Everything the seller sees afterwards follows from that.

The portal also has a hard limit on what a seller can do with money. A seller saves a simulation, edits it, discards it or reactivates it. A seller never approves one, and nothing the seller does in the portal creates a debt. Approval is a Hub task, done by someone with the permission for it.

This is a different product from the Customer Portal. The Customer Portal is anonymous and runs a conversational flow for the borrower. The Seller Portal is for your own sellers, who are signed in, and it only reaches a conversational flow at the end, when the seller sends the customer the onboarding bot.

Who Does What

How a Sale Moves Through the Portal

A sale goes through these stages in order. Not every organization uses all of them: a stage only appears when the operator turned on the capability behind it.

1. The operator sets the portal up. In the Hub, the operator decides what the portal does (see the customer book, prequalify a customer, build an operation) and configures each part. See Configuring the Portal.
2. The operator organizes the sales force. Customers are grouped into sales routes, each route gets its sellers, and routes can be grouped under distributors. See Sales Routes and Sellers.
3. The seller signs in. With a personal access link generated in the Hub, or with a one-time code sent by WhatsApp, SMS or email, depending on the organization. See Access and Sessions.
4. The seller finds the customer. The customer book lists the customers on the seller's routes, or every customer of the organization when the operator chose that search scope, with a search by name, ID number or customer number. See Customer Book.
5. The seller prequalifies the customer. The portal runs the evaluation the operator chose and shows whether the customer is approved, needs review or is rejected (or that the evaluation returned no recognizable answer), and whether the seller can go on. See Prequalification.
6. The seller builds the operation. The seller enters the operation data and the financial terms, adjusts the payment plan installment by installment and saves the simulation. See Operation Data and Payment Plan.
7. The seller hands the customer to the bot. From the summary, the seller sends the onboarding by email, with a link to a web chat, or by WhatsApp, with a QR code to scan on the spot. See Customer Onboarding.
8. The simulation stays on record. The seller finds it again in their history, prints its document, edits it, discards it or reactivates it, depending on its status. See Saved Simulations and History.
9. The seller runs follow-up actions. If the operator made any available, the seller runs them on the deal linked to the simulation. See Simulation Actions.
10. An approver decides in the Hub. The simulation is approved from the own-financing screens of the Hub, never from the portal. See Own Financing in the Hub.

Every message the seller can meet along the way, and what it means, is collected in Errors, Warnings and Limits.

What the Seller Sees on Every Screen

Where the Seller Lands

The portal's menu is an ordered list of blocks, configured per organization, and each block can be on or off. Two blocks exist: the Customers section and the simulator. The simulator has no menu name on screen: on a wide screen its step rail is headed Credit simulation, and on a phone a bar at the top shows only the current step and how many steps there are. Its steps appear as Pre-qualification, Customer and operation and Simulation, followed by Document and Summary, which always close the sequence. Inside the simulator, Customers is the label on the button that leads back to the customer book. A block this version of the portal does not know is ignored.

The seller lands on the first enabled block. When that block is the simulator, the portal opens straight into it. What the seller gets always follows the organization's capabilities: Customers when the customer book is on, and the simulator when prequalification or operations are on, with the prequalification step only when prequalification is on. In the Hub, those capabilities are See their book of customers, Prequalify a customer and Build an operation. The Hub composes the menu itself, always with the customers section first, so in practice a seller lands on Customers whenever the book is on and on the simulator otherwise. How each capability is turned on is covered in Configuring the Portal.

When nothing is enabled, the seller does not get an empty list. The landing shows Nothing is enabled yet and Your route has no feature turned on. Contact your administrator. The same screen appears when the portal could not load its configuration when it opened (for example, a failed request or a lost connection at that moment). If an administrator confirms that something is enabled, the seller should reload the portal before escalating.

The Header

The main header carries three things:

• The organization's logo, which takes the seller back to the landing. Without a logo, the header shows the text Seller portal instead.
• A History button. On the simulator and on a simulation's screens, History opens a side drawer with the seller's simulations. Everywhere else it goes to the history page. On a phone it shows only its icon.
• The seller pill, with the seller's initials, their name (or Seller when the record has no name) and the role Seller. On a phone the pill shrinks to the initials.

On the customer book, the same header also holds the Pre-qualify a customer button (when prequalification is on), the route selector (when the seller covers more than one route) and the customer search. In the simulator, on narrow screens, it adds a round + button, New consultation, that starts a new consultation. The customer detail screen has its own simpler header, with a back arrow and Customer detail, and no History button. The sign-in screen, the session screens and the Nothing is enabled yet screen have no header.

Inside the simulator, the header also shows a back pill to the Customers section; on a phone it shows only the arrow. When the menu has no section, there is no back pill, because the simulator is all that portal has. Section tabs appear only when the menu has more than one section, and the simulator is never a tab. With the menu the Hub builds today, which has at most one section, the seller sees no tabs.

Branding

The organization's logo and primary color, a hex value such as #1F6F5C, brand the header, the footer and the accents across the portal. Both are set in the Hub. Outcome colors do not follow the brand: the approved, rejected and review panels of a prequalification and the status badges of a simulation keep fixed colors, so a red brand cannot make an approval look like a rejection.

The Footer

Once the seller is signed in, every screen ends with a footer that shows Seller portal and the organization's logo at half opacity. The sign-in screen and the session screens have no footer. There is no legal text on screen. The Document footer an operator writes in the Hub is printed only on the simulation's document; see Configuring the Portal.

Without a Connection

When the phone loses its connection, a banner stays at the top of the screen: You are offline. This is the data that was already loaded. The seller can keep reading what was on screen, but nothing that needs the server works offline: searching, prequalifying, saving and sending fail until the connection comes back. If a session problem comes up while the phone is offline, the portal shows the No connection screen with a Try again button instead of the problem itself.

Language and Formats

The portal comes in Spanish, which is the default, and in English. In practice every seller sees it in Spanish, because nothing in the product switches it to English: there is no language switcher, no setting in the Hub and no link parameter for it, and the phone's or browser's language is ignored.

Numbers and dates follow the language. In Spanish they use Argentine formats, with dates as dd/mm/yyyy. In English they use US formats. Amounts are shown in the customer's currency, or in ARS when none is given.

What the Portal Does Not Do

Approval is the main limit, and it is covered above. Besides that, the portal does not offer:

• A sign-out button. A session ends on its own; see Access and Sessions.
• A way for the seller to pick the evaluation, the onboarding bot or the onboarding channel. The Hub sets all three.
• A dark theme or a language switcher.
• Creating or editing customers.
• The customer's email, phone or list of tax IDs, or any financial figure about the customer such as available credit, debt or next payment.
• The routes dashboard, which lives in the Hub under Sales routes.
• A standard amortization plan taken from a credit product. Every plan is a custom one: the portal splits the capital evenly across the installments, with due dates set by the chosen frequency, and the seller can adjust each of them. Interest is calculated on top, so the installment totals are not necessarily equal.
• A saved record of when the onboarding was sent, or of the installment frequency the seller used to build the plan.
• Saving or sending anything while offline.

Things to Know

The menu is read when the portal opens. The portal reads its configuration once, when the seller opens it. A seller who already has the portal open keeps the old menu until they reload it. AltScore applies the change on the seller's next request, though, so a capability you turned off is refused right away with This feature is not enabled for your organization.

Sellers see the portal in Spanish. A seller whose phone is set to English still gets the portal in Spanish, and nothing in the product changes that. Write the texts you set in the Hub (action labels, the document footer) in Spanish.

The History button is there even without operations. In a portal without Build an operation, including the default customers-only portal of an organization that never saved its configuration, the header still shows History. The history page then shows only the generic error, We could not complete the operation., because there are no simulations the seller can reach. If you run a customers-only portal, expect sellers to report it.

One seller, one live session. Signing in on another device closes the session on the first one. A seller who keeps the portal open in two places will keep pushing themselves out. See Access and Sessions.

Where to Go Next