CRM de afiliados de Inlaze
Un CRM de afiliados llevado desde la idea hasta la primera versión en producción, para que los afiliados gestionaran y cobraran las comisiones generadas por los clientes que referían.
Cliente:
Inlaze · Bogotá, Colombia
Categoría:
iGaming · CRM
Mi rol:
Diseñador UI/UX
UI/UX Designer · Bogotá, Colombia · Project contract · February 2023 – October 2023
Inlaze runs iGaming affiliate marketing. Affiliates send players to betting operators and earn a share of what those players generate, which makes it a two-sided marketplace: affiliates on the supply side, operators and their players on the demand side, and commission as the mechanism that ties them together. The company was running the affiliate side of that marketplace without a product. I designed the affiliate CRM from concept to its first production release in eight months.
At a glance
Role: UI/UX designer on a two-person design team. Research, definition and interface.
Scope: 0 to 1. No product, no flows and no design system existed when I started.
Constraint: a fixed project contract — a defined scope and a delivery date. On a contract like this the date decides what gets cut long before taste does.
Outcome: shipped inside scope and on the date. Affiliates use it to manage and collect the commissions generated by the players they refer.
The two sides
The supply side is the affiliate: an independent marketer whose entire relationship with the company comes down to two questions. Did the players I sent convert, and when do I get paid? The demand side is the operator, who cares about traffic quality rather than traffic volume — a thousand players who never deposit are worth less than ten who do.
A marketplace works when both sides trust the number in the middle. Everything in this product sits around that number: attribution, the commission it generates, and the moment it becomes money the affiliate can withdraw. Get the number wrong and the supply side leaves; make the number opaque and it leaves more slowly, but it still leaves.
The problem
Affiliates were being managed, and paid, outside any system. Attribution lived in someone’s spreadsheet, commission questions were answered by a person, and payouts were a conversation rather than a process. That is survivable with twenty affiliates and impossible with hundreds — and the cost lands on the side of the marketplace you can least afford to lose, because an affiliate who cannot see what they earned simply sends their traffic to a competitor who shows them.
Construir el lado de la oferta de un marketplace desde cero
Los afiliados solo ven un número: lo que se les debe. Todo el producto es el argumento de por qué ese número está bien.
Taking it from zero
Nothing existed. That is the part of this case worth reading, and the part every senior posting asks about.
I started from the affiliates, not from a feature list. What they needed was proof: which of my referred players are active, what did they generate, what is owed to me, and when does it arrive. Four questions, and the product is the answer to them.
The core object is the commission, not the affiliate. Once that was settled the information architecture followed on its own — a player attributes to an affiliate, activity generates commission, commission accumulates into a payout. Getting that hierarchy right early is what kept the scope from sprawling.
Trust before features. In a marketplace where one side only ever sees a number, the design job is showing the work behind the number. An affiliate who cannot reconstruct why they earned what they earned stops sending traffic, no matter how good the dashboard looks.
The design system shipped with the product, not after it. Built from scratch, because a 0 to 1 product on a fixed contract cannot afford to redraw the same table three times.
Result
The affiliate CRM shipped its first production version inside the contract window, and it gave affiliates a way to manage and collect the commissions generated by the clients they referred — a product the company did not have before.
Proyectos relacionados
