# Admin / Partner-Broker Back-Office Research: Hoppler (hoppler.com.ph) Clean-room, public-data-only teardown of Hoppler's **partner-broker back-office surface**, to inform the future admin/CMS roadmap of `property-portal`. Companion to the general competitive teardown at `../hoppler.md` (tech stack, public-site feature inventory). Captured 2026-07-11. **Method / ethics**: everything below comes from `robots.txt`, `sitemap.xml`, public marketing pages, and the **publicly served JS bundle** for the partner-broker portal (`/kpb/js/main.57e7d222.js`, 2.1 MB, fetched via plain `curl` — this file is downloaded to every visitor's browser before any login, so grepping its route table, Redux action names, and API-call strings is public-data analysis, not access to authenticated internals). No login was attempted, no credentials were submitted, no authenticated API response was read. Where a claim comes from web search / marketing copy rather than direct observation, it is marked `(inferred)` or cited. --- ## 1. Admin surface overview Hoppler runs **two separate account surfaces** on top of the public SSR marketplace (`www.hoppler.com.ph`, see main report): - **Buyer/consumer account** — lightweight, embedded in the public SSR site. Sign-up at `/signup-type` → `/client/sign-up/buyer`, session-cookie auth (`/login`, `/api/users/*`). Powers "My Viewing List" (shortlist/cart) and inquiry history. Not a back-office — no dashboard beyond saved listings, `not observed` to have more. - **Partner-broker / internal back-office** — `/kumita-brokers` and everything under it. This is a **fully separate client-side-rendered SPA** (``, page shell is 353–367 bytes, all content and routing happens in the downloaded JS bundle). It is a genuine multi-role CRM/back-office product — not just a "my listings" page — with a distinct route namespace, a large internal role hierarchy (§3), a sales-funnel/pipeline CRM (§4), commission-collection tracking, and a broker leaderboard. - The partner-broker SPA and the public SSR site share the same **Java/Tomcat API host**, `api.hoppler.com.ph` (confirmed via `hopplerApi.host` references in the bundle; cf. main report's `Server: Apache-Coyote`/`JSESSIONID` findings), and use `withCredentials:true` on `fetch`/axios calls — i.e. **cookie/session auth**, not a separate bearer-token scheme, shared across the SSR site and the SPA. ## 2. Discovered entry points Public URLs (HTTP 200, unauthenticated, served as SPA-shell HTML pointing at the same `/kpb/js/main.57e7d222.js` bundle): - `https://www.hoppler.com.ph/kumita-brokers` — portal root / marketing-ish landing - `https://www.hoppler.com.ph/kumita-brokers/login` — login screen (confirmed reachable, page contents are client-rendered, `not observed` beyond the shell) - `https://www.hoppler.com.ph/kumita-brokers/post-property` — public deep link into the listing-creation flow - `https://www.hoppler.com.ph/kumita-brokers/listings` - `https://www.hoppler.com.ph/kumita-brokers/inquiries/`, `/kumita-brokers/inquiries/accepted`, `/kumita-brokers/inquiries/search` - `https://www.hoppler.com.ph/kumita-real-estate-crm-software` — SSR marketing page for the CRM product itself (footer/nav link from homepage) - `https://www.hoppler.com.ph/partner-brokers` — SSR marketing/recruitment page (footer nav link "Kumita Partner Brokers") - No `robots.txt` disallow entries for `/kumita-brokers` or `/kpb/` — the whole partner-broker marketing/entry surface is intentionally crawlable (`robots.txt` only disallows `/_blog/`). **Full internal SPA route table**, extracted by regex-grepping quoted path-literals out of `kpb-main.js` (i.e. React-Router / history-push targets embedded in the bundle, not necessarily all directly navigable without auth): ``` /login /auth /token /refresh /dashboard/add-property /dashboard/mybusiness /dashboard/mylistings /post-property /preview /propertypreview /listings /listings/ /condominiums/ /group-listings/ /kumita/listing /kumita/listing/ /kumita/listing/description /kumita/listing/multimedia /kumita/listing/upload-for /kumita/location/search /kumita/location/linear/search /kumita/groups /kumita/groups/ /inquiries /inquiries/accepted /kumita-brokers/inquiries/search /kumita/inquiry/ /kumita/inquiry/pipeline/ /kumita/inquiry/pipeline/add-client /kumita/inquiry/pipeline/lost /kumita/comment/ /kumita/comment/listing/ /action/first-call-date /action/first-viewing-date /action/viewing-scheduled /action/lost /action/lost/restore /action/return /viewing-list/search /viewing-list/final /viewing-lists /viewing-lists/ /viewing-lists/create /viewing-lists/list /vl/ /attachment /attachment/ftf /attachment/selected-listings /offer /offer/ /offer/list /contract /contract/ /contract/list /contract/templates /commission /commission-agreement /collection/amount /collection/collected /collection/invoice /deals-lost /accepted /won /sent /expire /refresh /delete /download /kumita/partner-broker/dashboard /kumita/partner-broker/dashboard/broker-leaderboard /kumita/partner-broker/dashboard/listing/ /events /frameable/events /system /test /somewhere (utility/debug routes, unclear purpose — not observed in use) /api/properties/ /api/properties/check-duplicate /api/locations/search /api/locations/request/search/ /api/users ``` Notable **API calls resolved with full method + payload shape** (from Redux-thunk-style action creators in the bundle, all called against `hopplerApi.host` = `api.hoppler.com.ph`, all `withCredentials:true`): - `GET /kumita/groups` — fired on `GET_CURRENT_USER`, returns the user's current group(s) → confirms a team/brokerage-group membership model, not flat individual accounts. - `GET /kumita/partner-broker/dashboard/broker-leaderboard` → `GET_BROKER_LEADERBOARD_DATA`. - `PUT /kumita/inquiry/{id}/collection/invoice` (body `{invoiceNumber}`) and `PUT /kumita/inquiry/{id}/collection/collected` — commission-collection status tracking per deal. - `GET /kumita/inquiry/{id}/attachment/ftf` and `updateInquiryFtf` — "ftf" attachment on an inquiry (likely "face-to-face [meeting]" proof document; exact meaning `inferred` from field name only). - `POST /api/partnerbroker/partial` then `POST /api/partnerbroker/complete` (found in the **public SSR bundle**, `/xpoc/js/main.c674426a.js` — two-step broker registration: a partial-save action `BROKER_REGISTER_PARTIAL` followed by a final `BROKER_REGISTER_FULL` submit) vs. the buyer flow's single-step `POST /client/sign-up/buyer` — the broker sign-up is a longer, resumable multi-step wizard, buyer sign-up is not. - `iframe src="/frameable/events"` inside the `Events` SPA component — the events/calendar page is a **third-party embed**, not a native calendar (path name suggests the "Frameable" embeddable-calendar product; not independently verified). ## 3. Role & account model Three tiers of account exist: 1. **Buyer / consumer** (`ROLE_CONSUMER`) — public-site account, no back-office access. 2. **Partner Broker** (`ROLE_PARTNER_BROKER`) — external, independent brokers/salespeople who join the KUMITA network. Sign-up (per public marketing copy, `inferred` from web search, not the raw API) requires selecting an accreditation type: **"Licensed Real Estate Broker"** or **"HLURB/PRC Accredited Salesperson"**, each with a license-number field — i.e. license verification is collected at sign-up time (see §4 Verification). 3. **Internal Hoppler staff/roles** — a much larger role enum than the public marketing implies, extracted verbatim from the bundle's `Role` enum object: ``` ROLE_ADMIN ROLE_SUPERADMIN ROLE_CONSUMER ROLE_EXTERNAL_BROKER ROLE_RES_ASSOCIATE_BROKER (Residential Associate Broker) ROLE_RES_INTERNAL_BROKER (Residential Internal Broker) ROLE_COM_ASSOCIATE_BROKER (Commercial Associate Broker) ROLE_COM_INTERNAL_BROKER (Commercial Internal Broker) ROLE_SALES_LEASING_EXECUTIVE ROLE_SD_MANAGER (Sales Director Manager) ROLE_SALES_DIRECTOR ROLE_EXTERNAL_SALES_DIRECTOR ROLE_BROKER_COORDINATOR ROLE_BROKER_MANAGER ROLE_PARTNER_BROKER ROLE_CONTENT_PROVIDER ROLE_LISTINGS ROLE_MARKETING ROLE_SALES_SUPPORT ROLE_ACCOUNT_MANAGER ROLE_ACCOUNTING ROLE_LISTING_APPROVAL_SUPPORT ROLE_LISTING_APPROVER ``` A helper function in the bundle collapses this into a coarse "internal_manager" vs "external_manager" split: ```js r.roles.includes("ROLE_ADMIN") || r.roles.includes("ROLE_SUPERADMIN") ? "internal_manager" : ... "external_manager" ``` confirming a two-tier privilege model layered on top of the fine-grained role list (fine roles gate individual features; admin/superadmin is the coarse "internal staff" bit). The presence of `ROLE_LISTING_APPROVER` / `ROLE_LISTING_APPROVAL_SUPPORT` as distinct roles from `ROLE_LISTINGS` implies a **maker/checker split**: broker-submitted listings pass through an internal approval role before going live (see §4). Residential vs. Commercial brokers are modeled as separate role pairs (`ROLE_RES_*` / `ROLE_COM_*`), and internal ("Internal Broker") vs. externally-recruited ("Associate Broker" / "External Broker") staff are also distinct roles — Hoppler's own salaried brokerage staff and its KUMITA-recruited independent partner brokers coexist in the same CRM under different role flags, not separate systems. ## 4. Admin feature inventory **Listing / inventory access — partner brokers list their own inventory, they are not limited to reselling Hoppler's stock.** Evidence: a full listing-creation wizard exists in the SPA (`/dashboard/add-property` → `/kumita/listing` → `/kumita/listing/description` → `/kumita/listing/multimedia` → `/kumita/listing/upload-for`), backed by `POST /api/properties/check-duplicate` (anti-duplicate-listing check before submission) and post-submit lifecycle actions (`/expire`, `/refresh`, `/delete`, toast strings `"Successfully delete listing"`, `"Listing is now expired"`, `"Refresh listing success"`). Scoping labels found: **"My Listings"**, **"Team Listings"**, **"Rental Listings"**, **"Sale Listings"**, **"Offline Listings to Update"** — listings are viewable per-individual and per-team/group, with a nudge queue for stale ("offline") listings needing refresh. **Lead / client (CRM) management** — a full sales-pipeline model, not a simple inbox. Inquiry stages (from `ALL_INQUIRY_STAGES`, verbatim): ``` Accepted → Made 1st Call → Viewings Scheduled → Offer Sent → Offer Accepted → Collections (for-collection) ; plus Search (non-tab utility stage) ``` Supporting actions/routes: `add-client` (manual lead creation), `/action/first-call-date`, `/action/first-viewing-date`, `/action/viewing-scheduled`, tag-as-lost / restore-from-lost (`"Tag Inquiry as Lost"`, `"Successfully Returned Lead"`, `"Inquiry will be moved under Returned Leads"`, `"Inquiry will be moved under deals Lost"`), and a **41-entry lead-source attribution enum** (`LEAD_SOURCES`) covering Hoppler's own channels plus syndication to **third-party portals** — verbatim list includes `Blog, Carousell, Contacted BC, Dot-Property, Email, Events, FB Chat, FB Lead Form, FB Marketplace, FBP, Instagram, Lamudi, Lazudi, Mitula, Mobile-App, MyProperty, Newsletter, Offline Initiatives, OLX, Persquare, Petal-Organic, Phone, Phone - Website, PLDT Global, Property24, Referral - Own, Referral by Hoppler Partner Broker, Referral by previous Hoppler client (tenant or buyer), Referral by Hoppler Personnel, Rentpad, SMS, Trovit, Viber, Walk-In, What's App, ZipMatch, ZipMatch Post Inquiry`. This confirms Hoppler cross-lists on/tracks leads originating from most other PH portals studied in this competitive set (Lamudi, Dot Property, Rentpad, Property24 etc.) as attribution channels inside its own CRM. **Viewing-List / shortlist admin** — the buyer-facing "My Viewing List" cart (main report §4) has an admin-side counterpart: `/viewing-lists`, `/viewing-lists/create`, `/viewing-lists/list`, `/viewing-list/search`, `/viewing-list/final`, `/attachment/selected-listings`, with a broker-facing "Client Selected Listings" label and a "Live Viewing Link" / "Schedule Viewing" flow — brokers can construct/manage a client's shortlist and convert it into a scheduled viewing from the back office, not just receive it passively. **Commission / earnings ("KUMITA")** — deal-stage financial tracking beyond a static rate: `/commission`, `/commission-agreement`, and a distinct **collections sub-workflow** for invoicing and receipt (`/collection/amount`, `/collection/invoice` [PUT, sets an invoice number], `/collection/collected` [PUT, marks commission received]), plus offer/contract document handling (`/offer`, `/offer/list`, `"Upload Offer Accepted"`, `/contract`, `/contract/templates`, `"Create Contract"`, `"Select a property or offer template"` — templated offer-letter/contract generation, corroborated by public tutorial articles "Kumita Tutorial: How to Make an LOI" and "...How to Prepare a Contract"). Commission split rules (from the public `/partner-brokers` page, quoted verbatim): - Own listing + co-broker's client: **"40% Partner Broker | 40% Co-Broker | 20% Hoppler"** - Shared-responsibility close: **"50% Partner Broker | 50% Hoppler"** - Hoppler-provided client or owner referral: **"50% Partner Broker | 50% Hoppler"** - Per web search (not on the fetched page, `inferred`/secondary source): a long-term-partner variant where Hoppler passes a lead directly and takes **30%**. **Analytics** — a partner-broker dashboard (`/kumita/partner-broker/dashboard`) with labeled widgets: **"Number of Inquiries"**, **"Number of Listings"**, **"Number of Active Deals"**, **"Your Current Active Deals"**, **"Views on Your listings"**, **"Popular Locations by Inquiries"**, **"New Business"** vs **"Existing Business"** counters, and **"Deals Lost"**. Per-listing view counts are also exposed on the public results-page JSON (`views` field, main report §3) — the same counter likely powers both. **Referral / recruitment (KUMITA growth loop)** — `/kumita/partner-broker/dashboard/broker-leaderboard` (a **"Broker Leaderboard"** widget, `GET_BROKER_LEADERBOARD_DATA` action) gamifies broker activity/ranking; public marketing (`inferred`) also mentions a **points-for-listing-activity → discount-redemption** rewards mechanic, separate from cash commission. **Verification** — two distinct verification touchpoints: (a) **broker onboarding**: accreditation-type selection (Licensed Broker vs. HLURB/PRC Accredited Salesperson) with license-number capture during the two-step `/api/partnerbroker/partial` → `/api/partnerbroker/complete` sign-up (public marketing page description, `inferred` — raw form fields not directly observed since submission requires auth); (b) **listing moderation**: `ROLE_LISTING_APPROVER` / `ROLE_LISTING_APPROVAL_SUPPORT` roles plus a duplicate-check API (`/api/properties/check-duplicate`) gate broker-submitted listings before publish — an internal maker/checker step, exact UI/queue **not observed** (would require an approver-level session). **Notifications** — in-SPA labels only: `"Listing Updates"`, `"Inquiry Updates"`, `"Inquiry Update"` sections exist; delivery channel (email/push/in-app bell) **not observed**. ## 5. Implementation & tech Confirms and extends the main report's split-architecture finding: - **Public site** (`www.hoppler.com.ph`): Node/Express SSR, React-as-web-components "islands" (bundle `/xpoc/js/main.c674426a.js`). - **Partner-broker portal** (`/kumita-brokers/*`): a **second, entirely separate SPA build** — different bundle path convention (`/kpb/js/...` vs `/xpoc/js/...`), different bundler fingerprint, ships as a bare `` custom-element root with all rendering client-side (confirmed: page source for `/kumita-brokers`, `/kumita-brokers/login`, and `/kumita-brokers/post-property` are byte-for-byte identical shells except the canonical URL, i.e. one true SPA handling all client-side routing). Same custom-element (`hi-*`) naming convention as the public site, suggesting a shared internal component library across both apps even though they ship as separate bundles. - **Shared backend**: both apps call the same Java/Tomcat REST host, `api.hoppler.com.ph` (`hopplerApi.host` constant baked into both bundles), using cookie-based session auth (`withCredentials:true`, consistent with the `JSESSIONID` cookie observed on that host in the main report). - State management in the partner-broker SPA uses **Redux-style action types and RxJS-based epics/thunks** (`ofType`, `switchMap`, `mergeMap`, `catchError` patterns throughout `kpb-main.js`) — a redux-observable architecture, distinct from whatever the public-site bundle uses. - No CSP header was observed on the partner-broker portal responses (`not observed`, checked explicitly) — no additional signal on allowed script/connect hosts beyond the hardcoded `api.hoppler.com.ph` string. ## 6. The KUMITA partner-broker model — how recruitment/commission works KUMITA ("earn," Filipino) is Hoppler's branding for the whole partner-broker program **and** the CRM tool given to members — the marketing page literally states *"Kumita is Philippines' first end-to-end free real estate CRM software exclusive to Hoppler Partner Brokers and Sales Directors"* (`kumita-real-estate-crm-software` page). Mechanics, from public marketing pages + web search: - **Recruitment**: any broker can apply via `/partner-brokers` → sign-up form; accreditation (license type + number) captured at sign-up; two-step submit (`partial` save, then `complete`) suggests a resumable multi-field wizard rather than a single form. - **Lead flow**: Hoppler pre-qualifies leads before routing them to partner brokers ("Every lead will be pre-qualified before we pass them on to you" — web search summary of program copy); a **co-brokerage** model lets two partner brokers split responsibility on one deal. - **Commission splits** are tiered by who originated the deal (verbatim from `/partner-brokers`, §4 above): 40/40/20 for co-broker-on-own-listing, 50/50 for Hoppler-sourced leads or shared-responsibility closes; a long-tenure 70/30 variant is reported in secondary sources but not directly observed on-page. - **Non-cash incentive layer**: points earned per listing posted, redeemable for discounts, plus a competitive leaderboard (`broker-leaderboard` API) — a gamification layer stacked on top of commission economics to drive listing-supply activity specifically (points are tied to *posting*, not just closing). - **Tooling as the retention hook**: free CRM access (Kumita) is positioned as the member benefit that keeps brokers inside Hoppler's funnel instead of just cross-listing everywhere — the CRM includes templated offer-letter/contract generation and a commission-collection tracker, i.e. Hoppler removes enough of the back-office paperwork burden that an independent broker has a reason to run their whole deal pipeline inside Hoppler's tool rather than a generic CRM or spreadsheet. ## 7. Takeaways for property-portal's future admin/CMS Prioritized, given `property-portal` is a bilingual JP/EN SUUMO-like demo currently at Phase 2 (listing grid/detail, matching feed, bookings — per repo history): 1. **The shortlist-to-inquiry pipeline is the single most reusable idea here.** Hoppler's buyer-facing "Viewing List" (main report) is *not* just a UI cart — it has a full admin-side lifecycle (`/viewing-lists/create` → `/viewing-list/final` → "Schedule Viewing" → inquiry-stage progression `Accepted → Made 1st Call → Viewings Scheduled → Offer Sent → Offer Accepted`). property-portal already has a booking + matching-feed feature; modeling the admin side as a **stage-based pipeline with explicit action verbs** (call logged, viewing scheduled, offer sent, lost/returned) rather than a flat inquiries table would let a future admin UI show funnel health at a glance and is a small, well-scoped v1 CMS feature. 2. **Adopt a fine-grained role enum from day one, even with only 1-2 roles active initially.** Hoppler's ~20-entry `Role` enum (residential/commercial × internal/external, plus support roles like `LISTING_APPROVER`, `ACCOUNT_MANAGER`, `MARKETING`) looks over-engineered for a startup but it lets one CRM serve consumer, external partner, and internal staff without three codebases. For property-portal's roadmap, define role constants (e.g. `ADMIN`, `AGENT`, `LISTING_APPROVER`, `CONSUMER`) even in a single-tenant demo, so the data model doesn't need a breaking migration when a second role is added later. 3. **Separate the authenticated back-office from the public SSR app as its own bundle/route-tree, not a bolted-on `/admin` section of the same app.** Hoppler runs the partner-broker SPA as a structurally separate build (`/kpb/js/*` vs `/xpoc/js/*`) sharing only the API host and a component-naming convention. Given property-portal is a Next.js **static export**, a future admin surface likely can't be static-exported the same way (it needs auth + mutation) — plan for it as a separate deployable (e.g. a small authenticated Next.js/Remix app or even a lightweight SPA) hitting the same API, rather than trying to force it into the static-export pipeline. 4. **Listing moderation (maker/checker) is worth building in even for a demo/single-admin context**, because it's cheap to fake convincingly and is a recognizable "real CMS" signal: a `status: pending_review | approved | rejected` field on listings plus one approver role (mirroring `ROLE_LISTING_APPROVER`) demonstrates the concept without needing Hoppler's full multi-role complexity. 5. **Commission/earnings tracking is the one Hoppler back-office feature that's out of scope for property-portal's current positioning** (property-portal isn't modeling itself as a brokerage-commission marketplace) — flag it as an explicitly deferred capability rather than a gap, so it isn't accidentally half-built later. 6. **A lightweight "leaderboard"/gamification widget is a cheap, demo-friendly differentiator** if property-portal ever adds a multi-agent view: Hoppler's `broker-leaderboard` is a single API call surfaced as a dashboard widget, not deep infrastructure — worth considering purely for demo polish (e.g. "top-performing listings this week") even before real multi-tenant agent accounts exist. Sources consulted for §6 commission/program mechanics (public web search, not scraped): [Partner Brokers — Hoppler](https://www.hoppler.com.ph/partner-brokers), [Kumita real estate CRM software — Hoppler](https://www.hoppler.com.ph/kumita-real-estate-crm-software), [Additional Features of Kumita by Hoppler That Are Helpful](https://www.hoppler.com.ph/magazine/real-estate-news/additional-features-of-kumita-by-hoppler-that-are-helpful), [Kumita Tutorial: How to Make an LOI](https://www.hoppler.com.ph/magazine/real-estate-news/kumita-tutorial-how-to-make-an-loi), [Kumita Tutorial: How to Prepare a Contract](https://www.hoppler.com.ph/magazine/real-estate-news/kumita-tutorial-how-to-prepare-a-contract), [Hoppler Is Harnessing Cooperation In Real Estate Through Its Exclusive Network For Brokers — Orange Magazine](https://orangemagazine.ph/2018/hoppler-harnessing-cooperation-real-estate-exclusive-network-brokers/). --- ## Admin matrix row Roles | Admin entry points | Listing mgmt (bulk/feed?) | Lead CRM | Analytics | Promotion/boost admin | Billing/credits | Team/brokerage mgmt | Developer/project mgmt | Verification/moderation | White-label CRM product | Tech/implementation | Standout admin capability --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- ~20-entry role enum (`ROLE_CONSUMER`, `ROLE_PARTNER_BROKER`, `ROLE_EXTERNAL_BROKER`, `ROLE_RES/COM_ASSOCIATE_BROKER`, `ROLE_RES/COM_INTERNAL_BROKER`, `ROLE_SALES_DIRECTOR` (+`_EXTERNAL`, `_SD_MANAGER`), `ROLE_BROKER_COORDINATOR`/`_MANAGER`, `ROLE_ACCOUNT_MANAGER`, `ROLE_LISTING_APPROVER`/`_APPROVAL_SUPPORT`, `ROLE_MARKETING`, `ROLE_ACCOUNTING`, `ROLE_ADMIN`, `ROLE_SUPERADMIN`, collapsed to internal_manager/external_manager) | `/kumita-brokers`, `/kumita-brokers/login`, `/kumita-brokers/post-property`, `/kumita-brokers/listings`, `/kumita-brokers/inquiries/*` — separate CSR SPA, no robots.txt block | Yes — per-broker listing creation wizard (`add-property`→`description`→`multimedia`→`upload-for`) with duplicate-check API; scoped views "My Listings"/"Team Listings"; no bulk-CSV-feed import observed | Full pipeline CRM: stages Accepted→Made 1st Call→Viewings Scheduled→Offer Sent→Offer Accepted→Collections, manual add-client, lost/return actions, 41-source lead attribution enum incl. competitor portals (Lamudi, Dot Property, Rentpad, Property24, OLX, Carousell, etc.) | Dashboard widgets: Number of Inquiries, Number of Listings, Active Deals, Views on Your Listings, Popular Locations by Inquiries, New vs Existing Business, Deals Lost | not observed (no featured/boost-listing admin UI or endpoint found) | Commission-collection sub-workflow (`/collection/invoice`, `/collection/collected`, `/commission-agreement`) tracks invoicing/receipt per deal; no self-serve ad-credit/wallet system observed | Yes — `/kumita/groups` fetched on login (current user's group), "Team Listings" scoping, `ROLE_BROKER_COORDINATOR`/`ROLE_BROKER_MANAGER` roles | not observed (no distinct developer/project-inventory admin surface found, separate from generic listing mgmt) | Two-step broker sign-up (`/api/partnerbroker/partial`→`/complete`) with license/accreditation type capture (marketing copy, inferred); internal `ROLE_LISTING_APPROVER`/`ROLE_LISTING_APPROVAL_SUPPORT` gate listing publish | No — Kumita is Hoppler's own free CRM given exclusively to Hoppler partner brokers/sales directors, not sold as a standalone white-label product to other brokerages | Separate CSR SPA (`/kpb/js/main.*.js`, redux-observable/RxJS epics) vs. public site's Node/Express SSR (`/xpoc/js/main.*.js`); both call the same Java/Tomcat API (`api.hoppler.com.ph`) via cookie session auth | Templated offer-letter/contract generation + commission-collection tracker + gamified broker leaderboard, bundled as the retention hook of the whole partner-broker recruitment program