Platform & operations

Cookie consent for agencies:
many sites, many people, one dashboard

Cookie consent for agencies is the problem of running compliance on websites you do not own. Kukie keeps every client site in one organisation under one dashboard, gives each teammate an owner, admin or editor role, and can scope a client to their own site alone. Settings copy from one site to many.

Start free → See how many sites each plan covers

Managing consent for other people's websites is an access problem

The technical side of cookie compliance is much the same on the fortieth site as it was on the first. What changes is everything around it: who is allowed to touch which site, what a client is permitted to see, which junior can publish and which cannot, and what happens to a year of consent records when the relationship ends. Three habits cause most of the trouble, and each one has a fix further down this page.

Habit one

One login that everybody uses

A single shared account is the fastest thing to set up and the hardest thing to unwind. Nobody can tell who changed a banner, a leaver keeps working access until somebody remembers to rotate the password, and there is no way to let a client look at their own consent data without handing them everyone else's.

Habit two

The house style rebuilt from scratch, every time

You settle on wording you are happy to defend, a layout that performs, and a set of region rules that match where your clients trade. Then somebody retypes all of it on the next site, gets one field wrong, and now two clients have subtly different consent behaviour for no reason anybody chose.

Habit three

No plan for the day a client leaves

Contracts end. If the client's consent history only exists inside your account, they either lose it or you keep holding data about their visitors long after you stopped working for them. Neither is a good position, and it is the one nobody thinks about at the point of setting things up.

None of this is unique to agencies. An in-house lead with a dozen brand sites, or a freelancer with a handful of retainers, has the same shape of problem at a different scale. Kukie provides the technical infrastructure for consent management; whether a given site is compliant depends on how it is configured and may need additional legal measures specific to that organisation. The business case for taking it seriously is usually easier to make once you can show a client what their own site is actually loading.

Two different questions: who is on your team, and who is on this site

Kukie keeps those questions apart on purpose, because the answers are almost never the same person. An organisation is the container everything else sits in: your sites, your plan, your people. Access to it comes in two shapes, and picking the right one is the whole trick.

Your side of the wall

An organisation member

This is a colleague. They are invited by email, they accept, and from then on they work inside the organisation with one of three roles: owner, admin or editor. The role travels with them across the sites in the organisation, so you set it once rather than repeating yourself per client.

Use this for the people who need the shape of the whole account in their head: whoever runs delivery, whoever picks up a site when its usual owner is on leave, whoever is going to answer the phone when a client rings about a banner.

Their side of the wall

A guest on one site

Site-level access is separate from organisation roles and much narrower. You invite somebody by email to exactly one site, and that is all they get. They see that site and nothing else in the organisation: not the other clients, not the site list, not the people.

This is how a client marketing manager gets to read their own consent rates, and how a contractor gets to fix one banner during a project without being onboarded into your business. It is also the honest answer when a client asks whether anyone else can see their data.

Both routes start the same way: you type an email address and Kukie sends an invitation. Nobody has to be a customer already, and nobody ends up sharing a password with anybody.

Who can do what?

There are three organisation roles and one narrower kind of access. The dividing line that matters is not seniority, it is reversibility: an editor can do the day-to-day consent work on a site, and cannot do the things that would be painful to undo.

What each Kukie organisation role and a per-site guest is allowed to do
What you can do	Owner	Admin	Editor	Guest on one site
Edit the banner, its wording and its appearance	Yes	Yes	Yes	On their site
Run a cookie scan and categorise the results	Yes	Yes	Yes	On their site
Read the consent log and consent analytics	Yes	Yes	Yes	On their site
Generate and publish cookie and privacy policies	Yes	Yes	Yes	On their site
See every site in the organisation	Yes	Yes	Yes, except sites restricted to named people	No, one site only
Add a new site to the organisation	Yes	Yes	No	No
Invite people and change what they can do	Yes	Yes	No	No
Delete a site and everything attached to it	Yes	Yes	No	No
Transfer a site to another organisation	Yes	No	No	No
Billing, plan changes and cancellation	Yes	No	No	No

Read the editor row as the useful one. It is the role most of a team should have: everything needed to keep a client's consent setup correct, published and defensible, with the destructive buttons out of reach. What each of those jobs involves is covered on the cookie scanner and consent records pages.

How do you avoid rebuilding the same banner twenty times?

You configure one site the way you want every site to look, then copy its settings and paste them onto the others. Onto one, if that is all you need, or onto a whole selection at once.

That turns your house style into something you own rather than something you remember. The wording you have already had a lawyer look at, the layout that performs best on your clients' traffic, the region rules that match the markets they sell into: decided once, applied everywhere, and corrected everywhere when you improve it.

It also shortens onboarding to something you can quote. A new client site goes from empty to matching the rest of your book in the time it takes to paste, which is a very different conversation from billing them for a day of setup.

Copying settings between sites is not included on every plan. The pricing page shows which ones have it.

Travels with the paste

The banner configuration: layout, colours, buttons, behaviour
Your banner wording, in every language you have written it in
Your per-region consent rules
How often the site is rescanned

Stays with the site, and should

Its own cookies, categories and scan results, which are facts about that site
Its cookie policy and privacy policy, written around its own cookies
Its consent records, which belong to its visitors and nobody else's
Its access list, so pasting settings never quietly hands anyone a key

Handing a site back to a client

Nobody chooses a consent platform by thinking about the day they will stop using it for a particular client, which is a shame, because that is the day it matters most. A site can be transferred out of your organisation and into another one: another organisation you own, or the client's own account.

You start the transfer and name the recipient

Only the organisation owner can do this, which is deliberate: giving a site away is the one action on this page you cannot take back by clicking undo. You give the email address of the person who should receive it.
They accept, into an organisation of their own

The recipient signs in and chooses which of their organisations should receive the site. They can also decline, and you can cancel while it is still pending. Until somebody accepts, nothing has moved.
The whole site moves, history included

Banner configuration, region rules, cookies, scan results, legal documents and the consent log all go with it. The banner on the client's website keeps working. Your dashboard is one site lighter and you are no longer holding their visitors' data.

Why not just delete it

Because the consent log is the part that is hard to replace. It is the record of which visitor agreed to what, and when, and it is the first thing anybody asks for if a complaint ever lands.

Delete the site and that record goes with it. The client starts from zero and has nothing to show for the period you looked after them. Transfer it and the history is theirs, sitting in their own account, under their own billing.

The same move works in reverse when you take a client on and they already have a setup worth keeping.

Who this is built for

If you look after one website and you are the only person who touches it, none of this is for you, and a single site on a single login is the honest answer. These are the situations where it starts to earn its keep.

A digital agency with a client roster

Cookie compliance for clients becomes a service line rather than a favour you keep doing. One dashboard, one house style, per-client access, and a clean way to hand a site back at the end. Clients who ask to see their own consent data can be given exactly that and nothing more.

A freelancer with retainers

You are one person carrying a compliance obligation on behalf of several businesses at once. The value here is less about roles and more about not repeating yourself: paste your settings onto a new client site and it is configured the way the last five were.

An in-house lead with many properties

Brand sites, campaign microsites, a shop, a careers site and a help centre, each with a different team wanting to change something. Editor is the role most of those people should have, and the ones who need less than that get a single site instead of the whole estate.

Any team where more than one person publishes

The moment a second person can change the banner, you need to know who changed it and be able to take that ability away again. That is an account question, not a banner question, and it is why access control and audit logging sit alongside the consent features rather than under them.

How many sites one organisation can hold depends on the plan, and removing the Kukie branding from the banner is available on higher plans. Both are set out on the pricing page. If you would rather see the platform against a real site before you decide, run a client domain through the free cookie scanner, or get in touch if your setup does not look like any of the four above.

Related features

Running consent for other people raises questions about records, access and evidence. These are the pages that answer them.

Analytics

Consent rates and records

Security

EU storage, hashing, audit logs

Cookie scanner

Find every cookie automatically

See the full feature set

Agency and team questions

What agencies, freelancers and in-house leads ask before they move a client roster across.

Can I manage cookie consent for multiple websites from one account?

Yes. Every site you add lives inside an organisation, and one dashboard covers all of them. The banner, the scans, the consent records and the legal documents for each site are reached from the same place with the same login, rather than one account per client. How many sites an organisation can hold depends on the plan, which is set out on the pricing page.

How do I give a client access to only their own site?

Invite them by email to that one site rather than to the organisation. Site-level access is deliberately narrower than an organisation role: the person sees the site they were invited to and nothing else in the organisation, so a client can look at their own consent records and their own banner without discovering the rest of your roster.

What is the difference between an organisation role and site-level access?

An organisation role describes what somebody can do across the whole organisation. Owner has full access, admin can manage sites and members, and editor can work on the banner, scans, consent log and legal documents but cannot take destructive actions. Site-level access is granted one site at a time instead, and it is the right choice for a client or an outside collaborator who should never see the others.

What happens to a client's consent records when they leave the agency?

Transfer the site to their own organisation rather than deleting it. The site moves across with its consent history, banner configuration, scan results and legal documents, so the client keeps the record of what their visitors agreed to and when. Deleting the site instead would strand exactly the evidence they might later be asked to produce.

Can I remove the Kukie branding from client banners?

Removing the Kukie branding from the banner is available on higher plans, and which plans include it is set out on the pricing page. It is a per-site setting, so you can leave it in place where nobody minds and take it off for the clients who would rather it were not there.

Do I need a separate Kukie account for each client?

No. One login, one organisation, and every client site inside it is the normal arrangement. Separate organisations are worth creating when the billing genuinely has to be separate, because each organisation carries its own plan and its own list of members. Most agencies run one organisation and use per-site access to keep clients apart.

Run every client site from one dashboard

Free plan, no card required. Add your first site, invite your team, scope your clients.

Start Free → View pricing

Cookie consent for agencies:
many sites, many people, one dashboard