What should count as a client project?
Start with the brand or website being analyzed, the client owner and the reporting agreement. A project should have a clear identity that reviewers can recognize before running a scan or exporting data. If one client has multiple brands or markets, document why separate projects are needed and which work can remain within a shared reporting scope.
Avoid creating duplicate projects simply because two colleagues use different names for the same site.
Maintain a register with client, approved website, workspace, project identity, authorized users and service dates. Keep the purpose and evidence boundaries explicit. An agency’s internal planning spreadsheet can coordinate this work, but it should not include credentials or unnecessary private client information. Use the access controls and permissions approved by your organization.
How do you confirm capacity and access?
Read the current pricing comparison, then verify the actual account configuration and any purchased additions. Project, seat and workspace allowances are separate requirements. A plan that fits the number of active brands may still need more authorized users or a different workspace arrangement. Record the commercial basis and review date for your operating decision.
In Rankfor, open Workspaces, select the intended workspace and confirm the project before analysis. Check the website and engine shown for the record you are about to inspect. Team membership and project access matter; the existence of a workspace does not imply that every colleague can read every client. Resolve access through the approved account process before sharing data or creating work.
How do you operate a portfolio consistently?
Give each client a defined question scope, factual reviewer and measurement protocol. Preserve engine, dates and source records per client, and keep custom Answer Trail tests distinct from full Index scans. A central calendar can schedule your team’s review work, while the product’s actual scan availability determines when a new scan can run.
Do not describe a manual operating calendar as an automatic scan scheduler.
For illustration, an agency managing a fictional travel supplier and a fictional software vendor uses different buyer tasks and factual references. It reviews both accounts in one weekly operations meeting, but it does not pool their recommendation counts into one performance claim. The team checks the correct project before opening Reports, then inspects the relevant export before sharing through an authorized process.
What happens when a client leaves?
Use a documented offboarding decision covering access, reporting obligations, retained evidence and any future reactivation needs. Verify the product’s supported archive, deletion or replacement behavior before changing a project. Do not promise that deleting one client automatically preserves its historical data or returns a reusable slot; the particular action and account terms need confirmation.
Review the register for inactive access and unresolved work at an agreed cadence. Keep a client’s historical measurement protocol with its final deliverables so a future audit can identify where the series ended. The public playbooks can help standardize individual jobs, while your operating register keeps client scope, capacity and responsibility clear across the portfolio.
Steps to follow
Define client project scope
Record the approved brand/site, owner and reporting boundaries.
Confirm limits and access
Verify account capacity, memberships and any additional entitlements.
Operate separate evidence records
Keep per-client methods and check the active project before analysis or export.
Verify offboarding behavior
Confirm retention and lifecycle consequences before archiving, deleting or replacing a project.
Client project operations register
A blank CSV worksheet for your own evidence and decisions.
Download worksheet (CSV)Sources
Put the guide to work
Client project operations register
Explore the public playbooks ↗