Partner co-branding

The problem with account-level branding

Most survey tools hold branding at account level. You upload a logo once, set a colour once, and every survey the account publishes wears it. That model assumes one organisation runs surveys about itself, which describes a company doing its own customer research and almost nobody else.

It does not describe a shared service running consultations for four district councils. It does not describe a research agency with six clients, a charity delivering a programme funded by three trusts, or a county team collecting data on behalf of an NHS partnership. In all of those cases the organisation doing the work and the organisation whose name should appear at the top of the survey are not the same, and they change from survey to survey.

With account-level branding there are only bad options. You create a separate account per partner and lose the shared team and the single place to look at results. Or you swap the account logo before each launch, which works until two consultations are open at once. Or you give up and publish everything under your own brand, which is the option most teams take and the one that quietly costs them responses.

Why the badge on the survey changes the response

A survey's masthead is the first trust signal a respondent gets, and it arrives before a single question does. Someone who receives a link about bin collections in their borough is deciding, in about two seconds, whether this is their council asking or a stranger phishing. If the page is badged with an organisation they have never heard of, the honest reading is that it is spam, and the honest response is to close the tab.

This is sharpest in the public sector, where a consultation carries a statutory weight that a marketing survey does not. It matters again for charities and non-profits, where a funder frequently requires visible acknowledgement on the materials their grant paid for, and where "we could not put your logo on it" is an awkward line in a report.

How it works

Deliberately separate from the org brand kit

The organisation's own brand lives at account level, as you would expect. Per-survey collaborator logos sit alongside it rather than overwriting it, and that separation is the design decision worth understanding before you set anything up.

The practical benefit of keeping them apart is that nothing about your partner set-up is destructive. Adding a council to one consultation does not touch the twelve other surveys in the workspace, and removing it when the project ends does not either.

Set-up that survives a busy year

A few habits that are worth adopting before you have thirty surveys and four partners:

• Get the logo file from the partner's own brand team rather than lifting it from their website. Councils and NHS bodies have strict identity rules, and a stretched crest is a phone call you do not want.
• Agree in writing who appears and in what order. On a joint consultation this is a genuine question of ownership, not a design preference.
• Name surveys so the partner is obvious in the list — the branding is on the survey, so your internal naming should match it.
• Set the accent colour at the same time as the logo, then check it against white for contrast. A per-survey theme can be set to a colour that fails.
• Clear test responses before launch. It removes the completed responses, the partials and the uploaded files together, so the partner's first look at the results is a clean dataset.

Multiple organisations, if you need them

Co-branding covers the case where one team publishes on behalf of others. Where the work genuinely needs to be separated — different people, no shared visibility of results — the product also supports multiple organisations, with owner, admin and member roles and the last owner protected from removal at database level. Row-level security applies throughout and organisation isolation is pinned server-side, which is described further on the security page.

Most partner work does not need that. A shared service usually wants one workspace, one team and per-survey branding, precisely so results sit side by side.

What this is not

"White label" means different things to different buyers, so here is the boundary in plain terms:

• No custom domain for surveys.
• No white-label sending domain — the product does not email respondents at all.
• No reseller or partner portal, and no sub-account hierarchy for agencies.
• No per-partner login page or branded respondent accounts; there are no respondent accounts.

What you do get is the survey itself badged correctly, an accent colour to match, and embed mode for putting the survey inside a partner's own page, which is the closest thing to a domain change that most consultations actually need: the respondent stays on the council's website and never navigates away.

Related

See NumoForms for local government for how co-badged consultations tend to run, save and continue for long consultations that need more than one sitting, and the form builder for the rest of the per-survey settings. The product overview puts building, collecting and analysing in one place.