Run geocoding for every client under one team plan

Agencies do not have a geocoding problem. They have five geocoding problems, one per active client, running simultaneously, billed to three different stakeholders, executed by a team of four analysts who share a Slack channel and a deadline but not a clear picture of who has spent how many credits this month.

The standard workaround is a proliferation of accounts: each analyst signs up separately, each client project gets its own login, and the agency owner ends up reconciling four or five separate invoices at month end while hoping nobody accidentally ran a 200,000-row file on the free tier again. It works, in the way that a filing cabinet full of Post-it notes works.

CSV2GEO's shared team plan is built for the alternative: one owner account holds the subscription and the credit pool, teammates draw from that pool under their own logins, and the owner can see exactly how many rows each member has consumed. The web batch tool — upload a CSV or Excel file, map the address columns, geocode, download the result — is the interface that powers it. This post explains how the mechanics actually work, where the edges are, and how to run a clean multi-client operation on top of it.

The model: one pool, many members, separate logins

The design is deliberate. The owner holds one paid batch-geocoding subscription. Credits are denominated in address rows — the unit of work in the web batch tool. When a team member uploads a 5,000-row CSV and runs it through the geocoder, 5,000 rows come off the pool. The member does not need a card on file. They do not see the billing settings. They log in with their own credentials, do their work, and the row count lands against the shared pool.

The owner, meanwhile, can open the team dashboard and see exactly how many rows each member has spent. Not combined, not approximate — per member. That is the number the account manager needs when they are reconciling which client project consumed which budget line.

What does not pool is the developer REST API. API keys are per-user and metered independently. If an analyst needs programmatic geocoding from their own scripts, they manage their own API key at /api-keys under their account. There is no way to route REST API calls through the owner's credit pool, no sub-keys, no per-key caps tied to the shared balance. The team plan covers the web batch tool. The two billing systems sit in parallel and do not talk to each other.

This is not a limitation to route around — it is the right separation for most agency workflows. The web batch tool is where the bulk of the address-row volume lives: client data files, address lists from CRMs, election canvassing spreadsheets, property databases. The REST API is where individual engineers run integration tests and one-off enrichments. Keeping them on separate meters means neither pollutes the other's cost accounting.

Inviting a teammate

The owner invites members by email from account settings. Two outcomes depending on whether the invitee already has a CSV2GEO account.

If the email is already registered, the seat activates immediately. The member logs in the next time they use the product and sees the shared pool available in the batch tool. Nothing else changes for them — their own login, their own password, their own API key if they have one.

If the email is not registered, the invite sits as pending. The moment someone registers with that exact email address, the seat activates automatically. This matters for agencies onboarding a new freelancer or a client-side analyst who has not yet set up an account — the owner can pre-stage the invite before the person is fully onboarded.

The default seat cap is five members per plan. The owner can remove a member's seat at any time, freeing that slot for someone else. There is no grace period, no waiting for a billing cycle — the seat is freed immediately.

One edge case worth understanding: if an invited member already holds their own active CSV2GEO subscription, their own balance is spent first. The shared pool is the fallback for members who do not have a subscription of their own. In practice, for agencies, most team members are analysts without their own subscriptions — they are on the agency's plan. But if a senior engineer on the team has a personal subscription, they will draw from their own balance before touching the pool, which can create a confusing discrepancy in the owner's per-member usage report. Know your team's account situation before reading the usage numbers.

Running a clean multi-client batch job

The web batch tool is straightforward: upload a file, map the address column (or columns, if your data has street, city, state, country split across fields), set the output options, run. The challenge for agencies is operational, not technical — keeping client data clean and credit consumption attributable.

Three patterns that work in production.

One upload per client project

The most important habit is also the simplest: one file per engagement. Do not merge a 3,000-row retail-location list and a 7,000-row customer-address list into a single 10,000-row upload to save clicks. Separate files mean separate job histories, which means the usage report the owner sees accurately reflects which project cost what. When the client asks "how many addresses did you actually geocode for us this month," the answer is in the download history, not in a calculator.

Naming conventions for the download archive

The batch tool returns a downloadable file when the job completes. The filename is under your control before upload — name it clientname_projectname_YYYYMMDD.csv and the archive doubles as your audit trail. Geocoded results are not re-geocoded automatically; if the client comes back six months later with an updated file, you run a new job and get a new download. The naming convention keeps those distinct.

Check confidence scores before delivery

Every geocoded row comes back with a confidence score alongside the coordinates. A row that geocodes at 0.95 confidence is a pin-on-a-map; a row at 0.45 is a postcode centroid at best, a misparse at worst. Clients who use geocoded output to drive field operations — delivery routing, canvassing, sales territory mapping — need to know the distinction before they trust the coordinates.

The rule of thumb: flag any row below 0.7 for human review before delivering to the client. That is not a CSV2GEO-specific threshold — it is the industry convention. See Geocoding Confidence Scores Explained for the full breakdown of what the score components mean and where to draw your threshold for different use cases.

A worked example: three clients, one billing cycle

Call them Client A (a logistics company with 12,000 delivery addresses), Client B (a political campaign with 4,500 canvassing stops), and Client C (a retail chain with 800 new store locations to validate). One billing cycle, one analyst each, one owner reviewing at month end.

Here is what the month looks like under the team plan.

The owner invites three analysts — one per client — by email. Each accepts and logs in. Each uploads their client's file using the web batch tool. Client A's analyst runs 12,000 rows, Client B's runs 4,500, Client C's runs 800. The shared pool depletes by 17,300 rows total over the month. The owner's usage dashboard shows: Analyst A — 12,000 rows, Analyst B — 4,500 rows, Analyst C — 800 rows. The billing reconciliation is a single screen, not a multi-invoice arithmetic exercise.

The owner downloads the per-member breakdown and drops it into the agency's time-tracking system. Client A is invoiced for the geocoding cost proportional to 12,000 rows; Client B and C accordingly. Everyone's data stayed in their own analyst's session — there was no file-sharing across members, no risk of Client A's addresses appearing in Client B's output.

Staying within the seat limit

The default cap is five members. For most agencies — a project lead, two or three analysts, and one account manager who occasionally needs to run a sanity check — five is enough. But five fills up faster than it seems when you add a freelancer for a quarterly data project, a client-side contact who wants to run their own files, and a developer who needs access for testing.

Two things to manage proactively.

Remove seats when a project ends. When an engagement closes and the analyst is no longer active, remove their seat. This is a one-click operation in account settings and it frees the slot immediately. An agency that treats seats as permanent will hit the cap on its third client; an agency that cleans up after each project will cycle five seats through a dozen engagements per year without upgrading the plan.

Decide whether the developer seat counts. If your developer is running REST API calls exclusively, they do not need a team seat for the batch tool — their REST API key is independent and does not draw from the pool. Give the seat to an analyst who actually uses the web interface. The developer can still have a CSV2GEO account; they just are not consuming a team seat.

The REST API is separate — design accordingly

This bears repeating because it is the most common confusion in onboarding calls. The team plan governs the web batch tool. Row credits flow through the shared pool. The REST API is a completely separate billing surface: each user has their own API key at /api-keys, metered independently, with no connection to the team pool.

If your agency workflow is entirely web-tool-based — upload, map, geocode, download — the team plan handles everything. If you have a developer who is also building a programmatic integration for a client, that integration runs on that developer's own API key and their own paid REST tier or free tier. The owner's subscription does not cover it, and the developer's API usage does not show up in the owner's usage dashboard.

This means you should not route production client workloads through a developer's free-tier REST account and expect it to be covered by the team plan. Design the workflow first, then confirm which billing surface it hits. The pricing page at csv2geo.com/pricing/api shows both tiers — the batch-tool tier and the REST API tier — and they are priced separately.

How to set up and run the team plan end to end

Step 1: Choose the owner account and upgrade the plan

The owner account is the one that holds the subscription. Pick carefully — this is the billing contact, the credit-pool holder, and the account with admin access to invite and remove members. If the agency has a shared ops email (geocoding@agency.com), that is the right owner; a personal email that belongs to one analyst who might leave next year is the wrong choice.

Once the account is created, go to csv2geo.com/pricing/api and choose a paid plan that covers the monthly row volume you expect across all active clients. You can estimate from past usage or from the file sizes you receive — a 10,000-row file is 10,000 credits. Upgrade from the account settings page. The free tier supports trialling the product up to 3,000 calls per day; the paid tier starts at $54/month for 100,000 calls. Both are available without a sales process.

Step 2: Invite your team members

From account settings, navigate to the team management section and invite each member by email. For analysts already on CSV2GEO, the seat activates when they next log in — they will see the shared pool available in the batch tool automatically. For new hires or external collaborators without an account, the invite sits as pending and activates the moment they register with the matching email. You do not need to coordinate timing — send the invites, then tell the analysts to register at their convenience.

Document which seat belongs to which client project. A simple internal note (Analyst A = Client A logistics project, seat active until Q3) will save confusion when you are deciding whose seat to remove at project close.

Step 3: Run a test batch before the first client job

Before an analyst runs a real client file, have them run a small test batch — 50 to 100 rows from a publicly available address list, or a sample from the real client file with names removed. This confirms the column mapping is correct (address, city, state, country mapped to the right fields), the output format is what the downstream workflow expects, and the credit draw is visible to the owner in the usage dashboard.

The test batch costs 50-100 rows from the pool. It is worth it. A misconfigured column mapping on a 15,000-row client file means 15,000 wasted credits and a re-run at full cost — the test batch catches that for a rounding error.

Step 4: Run the client batch job and review confidence scores

Upload the client's address file via the web batch tool. Map the columns. Run the job. When it completes, download the enriched output.

Before delivering to the client, open the output in a spreadsheet and filter on the confidence column. Flag any row below 0.7 and review it manually. For the remaining rows — the 85-95% that geocode cleanly at high confidence — the output is ready to deliver. The flagged rows go into a second pass: clean the address format, check for typos, re-run if necessary.

See Geocoding Confidence Scores Explained for a fuller treatment of what the score components mean and what thresholds fit which use cases.

Step 5: Review the usage report and reconcile costs

At month end (or project end, whichever comes first), pull the per-member usage report from the team dashboard. Each member's row total is visible. Match these to client projects. If Client A's analyst ran 12,000 rows, Client A's project cost is 12,000 rows × (plan cost per row) — a one-line calculation.

Document the numbers before removing any seats or archiving any jobs. Once a member is removed, the usage history stays in the owner's reporting — you do not lose the data — but confirming this before removal removes any ambiguity.

If you are running observability across your geocoding pipeline more broadly — tracking job durations, error rates, and credit burn — Observability for Geocoding Pipelines covers the metrics worth instrumenting and the tooling patterns that work at scale.

Edge cases worth planning for

A member uploads a file and the job fails partway through. If a batch job fails mid-run, the partial rows already processed consume credits. The safest operating pattern is to run large jobs during off-peak hours, keep files under 50,000 rows per upload, and have the analyst check the job status page before starting a new upload. For very large files — 100,000 rows or more — split the file into chunks before upload.

A pending invite that never activates. If an invitee registers with a slightly different email address (a common typo or a work-email alias), the invite does not activate automatically. The owner needs to remove the pending invite and re-invite with the correct email. Check the pending-invite list before concluding a seat is "in use" — a stale pending invite consumes a slot without doing any work.

An analyst who also has their own active subscription. As noted earlier, a member with their own active CSV2GEO subscription draws from their own balance first. Their usage may not appear in the shared pool's depletion count even if it shows up in the owner's per-member usage report. If the per-member report and the pool-depletion number do not add up, this is the most likely explanation. Decide as a policy whether analysts should maintain their own subscriptions while on the team plan, or whether all batch work should flow through the shared pool exclusively.

The free tier and trialling before committing. The free tier — 3,000 calls per day — is available for both the web batch tool and the REST API. Before upgrading to a paid team plan, the owner can trial the product on their own account, running small sample files from each client vertical to confirm address coverage, confidence scores, and output format. Only when the trial confirms the product works for the workflow should the paid plan and team invites be set up. There is no time pressure; the free tier does not expire.

Cost transparency across the team

One of the underrated benefits of the team-plan model is what it does to internal cost conversations. An agency owner who is reconciling geocoding spend across three active clients at month end with three separate invoices and no per-project breakdown is essentially guessing at the cost allocation. The team plan replaces the guess with a number.

That number matters for a few reasons. First, it anchors the pass-through billing to the client — if the SoW includes a data-enrichment line item, the owner now has an auditable basis for that charge. Second, it surfaces which projects are credit-heavy — a 50,000-row client dataset that re-geocodes every week because the source system sends full dumps is a different cost profile from a 2,000-row one-time validation. Seeing that in a dashboard makes the conversation about batching and caching concrete rather than theoretical.

On caching: the web batch tool does not cache at the user level — each job you run draws credits. But if a downstream workflow is also hitting the REST API, caching geocoding results at the application level is straightforward and can eliminate redundant calls entirely. Caching Geocoding Results — 90% Cost Reduction covers the patterns; the same logic applies whether the original geocode came from the web tool or the REST endpoint.

Frequently Asked Questions

Does each team member need a paid subscription of their own?

No. Team members draw address-row credits from the owner's shared pool. A member without their own subscription uses only the shared pool. A member who already has their own active subscription will spend their personal balance first and fall back to the shared pool only if their own balance is exhausted.

Can a team member see the billing details or the full credit balance?

Members can see their own usage in the web batch tool. Billing settings, the full credit balance, and the per-member usage breakdown visible to the owner are not exposed to team members. The owner retains exclusive access to billing and team management.

What happens if the shared pool runs out mid-month?

Batch jobs that would exceed the remaining pool balance will fail or not start. The owner needs to upgrade the plan or wait for the next billing cycle. To avoid mid-project failures, monitor the pool balance before running large jobs and top up the plan in advance if a large engagement is approaching.

Does the team plan cover the developer REST API?

No. The team plan governs the web batch tool only. REST API calls are metered per user via individual API keys at /api-keys and are independent of the shared pool. There are no sub-keys and no mechanism to route REST calls through the team balance.

Can the owner see which specific files each member ran?

The owner's dashboard shows per-member row consumption. Specific file names and job details are visible to the member who ran them. The owner sees the aggregate row count per member, which is the figure needed for cost allocation across client projects.

What is the seat limit and can it be increased?

The default limit is five members per plan. The owner can remove a member's seat at any time to free a slot. If the team genuinely needs more than five concurrent active members, check the pricing page at csv2geo.com/pricing/api — higher-tier plans may accommodate larger seat counts.

What address formats and countries does the batch tool cover?

The batch tool draws on the same geocoding engine as the REST API — 461M+ addresses across 39 countries. Structured and free-text address inputs both work; the column mapper in the web tool handles split-field formats (street, city, state, country as separate columns) as well as a single combined address column. For a fuller treatment of how the engine handles international address formats see Geocoding Addresses in 200+ Countries.

Related Articles

• Caching geocoding results — 90% cost reduction — how to avoid re-geocoding the same address rows across repeat client jobs
• Benchmarking geocoding APIs — honest numbers — what to measure when evaluating whether a geocoding service is accurate enough for your client deliverables
• Observability for geocoding pipelines — instrumentation patterns for tracking credit burn, error rates, and job duration across multiple concurrent projects
• Rate limiting — token bucket vs leaky bucket — relevant if you are combining web batch jobs with REST API calls and need to manage throughput across both surfaces
• Geocoding confidence scores explained — what the confidence number means, where to set your review threshold, and how to handle low-confidence rows before client delivery

---

*I.A. / CSV2GEO Creator*