Platform · CRM & back office
A prop firm CRM built for the challenge lifecycle.
A prop firm CRM is not a sales CRM. Your customers don't move down a funnel — they buy challenges, pass or breach, get funded, request payouts, and come back. PropXO's back office models that loop directly: every account by plan, phase, and status, with the full customer behind it.
The core problem
Your customers don't have a funnel. They have a lifecycle.
Most prop firm back offices are broker or sales CRMs with the labels changed. The mismatch isn't cosmetic — it's structural.
A sales CRM assumes a line: lead, opportunity, closed-won, retention. A forex broker CRM assumes a slightly different line: lead, deposit, trade, redeposit. A prop firm's customer does something neither model can describe. They buy a product they will probably fail. The ones who fail often buy again. The ones who succeed become a payout liability that must be managed, not a deal that gets closed.
That means breach is not churn. A breached trader with a clean verification record and a note trail is one of your likeliest next customers — and a "closed-lost" label actively hides that. It also means the interesting questions about your book are state questions, not pipeline questions: who is mid-evaluation on which plan, who just got funded, whose payout is pending, who is under risk review. A CRM that can't answer those natively makes your team answer them with spreadsheets.
So we didn't adapt a sales CRM. We built the back office around the lifecycle your customers actually move through — the same lifecycle the challenge engine defines and the risk engine enforces.
- 01
entry
Purchase
An order lands through your storefront. The account is created automatically, and the rules the customer bought — targets, drawdown, splits — are locked to that account for its whole life.
- 02
the work
Evaluation
The trader works through their phases under real-time rule enforcement. The CRM tracks which phase they're in, how the account is classified, and everything support might need to know about it.
- 03
the fork
Breach or funded
Every evaluation resolves one of two ways. Both outcomes matter commercially: funded traders create payout obligations, and breached traders very often come back for another attempt.
- 04
the loop
Payout, reset, or scale
Funded traders request payouts. Breached traders retake. Successful ones move up scaling plans. The record persists across all of it — this is a loop, not a pipeline that ends at closed-won.
Accounts
Every account by plan, phase, and status.
The operational unit of a prop firm is the account, not the contact. The console treats plan, phase, and status as the primary way you see your book — because they are the primary way you run it.
By phase
Evaluation phases are first-class, not a custom field. See who is mid-evaluation, who just advanced, and who is funded — the operational question behind almost every support ticket and every risk review.
These views read the same live state the rest of the platform writes. When the risk engine breaches an account or the payout pipeline advances a request, the console reflects it — there is no sync job between "the CRM" and "the trading system" because they are the same system.
Customer context
The whole customer on one record.
Support quality and risk quality both come down to the same thing: how much of the truth is in front of the person making the decision.
Orders and purchase history
Every challenge purchase, retake, and reset with its payment state — so when a customer disputes a charge or asks which attempt an account belongs to, the answer is on the record, not in a payment dashboard two tabs away.
Notes that stay with the customer
Internal notes attach to the person, not to a ticket thread that gets archived. The context a support agent wrote down during a payout question is still there when a risk analyst opens the same record weeks later.
Support tooling
Support that starts with context, not a blank ticket.
In a prop firm, most support tickets are account questions in disguise. Tooling that separates the conversation from the account guarantees slow, wrong answers.
The account, in front of the answer
Why did I breach. Where is my payout. Why is my verification pending. These are account questions wearing ticket costumes — and the agent answering them sees the phase, the rule that fired, and the payout state without leaving the console.
Actions, not just replies
Support work in a prop firm is operational: extend an evaluation, escalate a flagged account, chase a stuck verification. The console exposes the actions a role is allowed to take, and records that they were taken.
The trader asking the question is looking at the other side of this same record — their white-label dashboard shows the account state, payout status, and progress your agent is reading. When both sides see the same truth, most disputes never start. See the trader experience →
Roles & permissions
Who can see what, who can do what, and proof of both.
A back office that touches payouts, KYC data, and account interventions needs real access control — not a shared admin login.
Role-based access
Support, risk, finance, and admin see the console differently. Each role gets the context it needs to work — and nothing that belongs to another job.
Permissions scoped to actions
Reading a record and acting on it are different privileges. An agent can review a payout request without being able to approve it; approval belongs to whoever your policy says it belongs to.
An audit trail with names on it
Manual interventions — suspensions, refunds, extensions, approvals — are recorded with who acted and when. When a trader disputes a decision, you reconstruct what happened instead of arguing about it.
Affiliates
Affiliate tracking that sees past the sale.
Affiliates drive a large share of prop firm growth — and a large share of prop firm fraud. Both facts argue for tracking them inside the back office, not beside it.
Affiliate and referral tracking is built into the same console. Purchases are attributed to their source, and because the referred customer's whole lifecycle lives in the same system, you can follow what an affiliate's traffic actually did after the sale: evaluations bought, phases passed, accounts breached, payouts requested. An affiliate whose referrals buy once and vanish looks very different from one whose referrals keep funding accounts — and different again from one whose referrals share devices and IP histories, which is a pattern the risk engine's abuse detection is built to surface.
The business-level view of the same question — which sources produce durable revenue and which produce exposure — lives in analytics and reporting.
Connected
One console over the whole platform.
The CRM isn't a product bolted onto the stack — it's the human interface to it. The modules below write the state this console reads.
Verification, payments & storefront integrations surfaced in the back office
FAQ
Frequently asked questions
PropXO · Demo
See the console with your model in it.
A walkthrough of the operator console configured for your vertical — accounts, records, support flow, roles, and affiliate tracking. Commercial terms are scoped privately for the deployment.