Resell MADDOX to your clients

Resell MADDOX to your clients. Provision workspaces from one console, set each client’s level, and work inside them on the record with a full audit trail.

Your clients already ask you to fix their sales process. They forward you the spreadsheet, they ask which CRM they should buy, and then they go and buy the wrong one anyway.

Resell MADDOX and that conversation becomes a line of business instead of free advice. You own the relationship, you own the invoice, and the platform underneath is one you can actually get your hands into on their behalf.

What resellers get

Run your clients’ platform, not just recommend it.

Every client in one place

One console across all of your client workspaces. You see who is set up, who is active and what each of them is running, without logging in and out of anything.

Provision a client yourself

Stand up a new client workspace when you win the work. No ticket to us, no waiting on our calendar, no procurement step between you and a live environment.

Set each client’s level

Choose which subscription level a client sits on and change it as they grow. The client you onboarded on the basics is a two-minute change when they are ready for more.

Work inside their workspace

Configure the pipeline, build the campaign, fix the broken automation – hands-on, in your client’s workspace, without asking them to book a screen-share so you can talk them through it.

How it works

Four steps, and none of them are a procurement cycle.

  1. Apply. Tell us who you are, who your clients are and what you run today.
  2. We set you up. You get your reseller account and we walk the platform with you properly, not as a demo.
  3. Provision your first client. Stand up their workspace, set their level, configure it the way you would configure anything else you run for them.
  4. You own it from there. The relationship, the invoice and the day-to-day are yours. We are behind you, not between you and your client.

Apply

Tell us about your clients.

We read every one of these ourselves. If you are a fit we will say so quickly, and if you are not we will say that too rather than leaving you wondering.

Applications are read by a person, not a queue. Use the request form and say you want to resell; you will get a reply from somebody who can answer commercial questions.

  • Your company, and roughly how many clients you would bring.
  • What you run today — PSA, CRM, marketing tools.
  • Whether you want to resell, refer, or just run it yourself first.

Apply through the request form

Not sure yet? Request access first and see the product before you decide whether to sell it.

The console

Your clients are rows in a console that is yours, not tickets in ours.

Every workspace on the platform belongs to exactly one reseller. That is not a label on an account — it is the column every reseller-scoped read filters on, which is why the console can show you your whole book and cannot show you anybody else’s.

Provision a client workspace yourself.

One action stands the whole thing up in a single transaction: the workspace, its activity-outcome vocabulary, the six compliance expectation rules switched on at creation, the coaching advice library, the module registry, the first administrator and the subscription row. If any step fails, none of it is written. There is no ticket to us in the middle of that and no half-built workspace afterwards.

A new workspace refuses to join an existing one. The generated slug collides about once in fourteen million, and “you are now an administrator of somebody else’s client” is not a failure mode worth a probability argument, so the create path is a different method from the repair path rather than a flag on one.

Set the level, and change it when they grow.

You choose which rung a client sits on and move them when it stops fitting. Each move writes three things in one transaction — the live subscription, the mirrored plan on the workspace, and an append-only ledger entry naming you and carrying your reason. The ledger cannot be edited afterwards by anybody, including us.

A retired rung refuses new assignments rather than silently accepting them, and a level that would take away the one module everything else depends on is refused at the point of assignment. You cannot accidentally sell a client a workspace that loads and does nothing.

Invite their people, or hand them a link.

An invitation is a real object with a redemption path rather than an email you hope somebody kept: it can be issued, it can be redeemed once, and a redemption that is no longer valid says which of the reasons it is — expired, already used, revoked — instead of failing generically.

Hands on

You can work inside a client workspace, and the workspace can prove you did.

This is the part most channel programmes do not have, and it is the part that needs the most care. Configuring a pipeline for a client should not require a screen-share where you talk them through clicking — and it should also never be a back door.

Three modes, and they are genuinely different.

Observe is read-only: you see the workspace and write nothing. Acting as a named user is what you use when the question is “what does Dana see”. A managed seat is a real user row that is not a person, which is what you use to actually configure something — because deal ownership, assignment, the audit trail’s causer and every created-by column are keyed to a user id, and an operator wearing a fake principal would leave rows pointing at nothing.

The seat has no password, and that is the security argument.

A managed seat is created without one, and the login path refuses a passwordless user before a password is ever compared. So the seat cannot be signed into by anybody, ever, by any password — including one an attacker sets through a compromised administration screen, because user administration is on the list of things an impersonating session may never reach. The alternative would have been a random password nobody keeps, which is security by ignorance of a value that is nonetheless in the row. This is security by there being no value.

A reason is required, and it is the control rather than the courtesy.

Starting a session needs a written reason of at least a few characters. The console renders the field as required, but a form input is a courtesy; the refusal is on the server. There is deliberately no judgement of whether a reason is a good one, because a rule that tried to assess that would refuse real support calls.

The session is recorded with who you are, which client, which mode, when it started, when it ended and how many writes it made. The token that authorises it is stored as a digest and never as a raw value, so a database dump does not yield working sessions.

What you cannot do inside a client workspace, ever.

Identity and credential surfaces are refused outright, including their read-only screens: enrolling or disabling their second factor, the page that renders the enrolment secret, their identity-provider binding, connecting or disconnecting their mailbox, issuing or revoking softphone credentials, and API keys. Data-subject erasure is refused on anything that writes — reading the request queue during a support call is the job; erasing a data subject is not. Starting a second session from inside the first is refused by the engine and again by the middleware.

This is the same refusal list the assistant is held to, in one place, because two copies of it would mean the next destructive domain gets added to one of them.

The boundary

The line between your book and everybody else’s is structural.

A programme that relies on the console showing you the right rows is a programme with one bug between you and a competitor’s client list. This one relies on the filter.

A client that is not yours does not exist to you.

A workspace id that names nothing and a workspace id that names somebody else’s client produce the same answer, which is what makes the pair useless as a way of finding out whether a company is a MADDOX customer. Reseller scoping is applied by the same shared concern on every reseller route rather than remembered per controller.

Your own audit trail, not a support request for ours.

The console carries the record of what was done in your clients’ workspaces by your people: sessions, reasons, subscription changes and who made them. You do not have to ask us for it, and your client can be shown it.

What we are not offering, plainly.

There is no published margin on this page, no client-count threshold and no tier structure, for the same reason there are no figures on the pricing page: those are conversations, and printing a number here would make it one anyway. There is also no white-label product — the workspace your client signs into is MADDOX, and this page is not a soft way of saying a rebrand is coming.

Questions

The things people actually ask.

Who is the partner programme for?

Agencies, consultancies, IT service providers — anyone who already runs systems on a client’s behalf and gets asked which CRM they should buy. The console, the provisioning model and the audit trail were all shaped by that relationship: you are working inside somebody else’s business, so every session carries your name and a written reason. IT service providers have their own page.

Do we own the client relationship?

Yes. You provision the workspace, you hold the level, you invite their people and you are the one they call. Every workspace belongs to exactly one reseller and yours belongs to you; a customer who signed up with us directly belongs to a house reseller row, which is the same object with a different name on it.

Can we configure a client system without them watching?

Yes, and it is recorded. You work in their workspace through a managed seat – a real user row that is not a person, so ownership and audit rows point at something real – and the session carries your name, your written reason, its start, its end and its write count.

What can we not touch in a client workspace?

Their second factor and the screen that renders its secret, their identity-provider binding, their connected mailbox, their softphone credentials, their API keys, user and role administration, and data-subject erasure. Those are refused on the server, on every method, regardless of the role attached to the session.

Is this a white-label programme?

No. Your client signs into MADDOX and it says MADDOX. What is yours is the relationship, the invoice, the console and the ability to work inside their workspace on the record. We would rather say that here than let you find out during an onboarding call.

How long does it take to stand a client up?

Provisioning is one transaction and it is the fast part. What takes time is the work you were going to do anyway – the pipeline, the stages, the campaigns – and you can do all of it in their workspace yourself rather than describing it to them over a screen-share.