Why teams pool geocoding credits instead of buying per-seat

Per-seat software pricing made sense when the resource being sold was a human-hours story — a licence to use a word processor, a seat in a CRM, a user account in a project-management tool. Usage scales roughly with headcount, so headcount-based billing is a fair proxy for consumption.

Geocoding is not a human-hours story. It is a data-volume story. One analyst uploading a single 200,000-address file in a batch consumes the same number of address-row credits as twenty analysts uploading 10,000 rows each. The work that drives the cost is not the number of people sitting at keyboards — it is the number of address rows that need to become latitude/longitude pairs.

This has a direct consequence on procurement. A team that buys individual geocoding subscriptions for each analyst is not buying the right unit. They are paying for seats when they should be paying for rows. The same budget, restructured around a single shared pool, almost always buys more capacity, simpler billing, and cleaner visibility into which projects are actually consuming the resource.

This post walks through the economics of that restructuring, the exact mechanics of how CSV2GEO's shared team accounts work, and the failure modes that catch teams off guard in the first billing cycle.

The per-seat problem, put concretely

Imagine a five-person data team at a mid-size insurance carrier. Their geocoding needs look something like this on a typical month:

• Alice (senior analyst) — uploads two large policy-renewal files, 80,000 rows each. 160,000 rows total.
• Bob (junior analyst) — one intake file per week, roughly 5,000 rows. 20,000 rows total.
• Caro (data engineer) — periodic enrichment jobs, typically one big run early in the month, 60,000 rows.
• Dan (product manager) — occasional ad-hoc lookups, maybe 500 rows some months, zero others.
• Eve (external consultant, part-time) — quarterly deliverable, 30,000 rows, three months per year.

The team's aggregate monthly geocoding demand is roughly 240,000–270,000 rows in a heavy month and under 25,000 in a light one (when Eve is off-cycle and Alice's renewals are not due).

With per-seat subscriptions, every person above needs their own plan sized to their personal peak. Alice needs a plan that can handle 160,000 rows. Bob needs one for 20,000. Caro needs one for 60,000. Dan needs something even if he only uses it occasionally. Eve needs a subscription active during her active quarters and either cancelled or idled the rest of the year.

The procurement overhead alone — five subscription purchases, five renewal cycles, Eve's quarterly on/off cycle, separate invoices to reconcile — is a finance team's Friday afternoon made worse. And the capacity purchased across all five plans almost certainly exceeds actual aggregate demand, because each plan must cover each person's peak independently.

A single shared pool sized to the team's aggregate peak is smaller than the sum of the individual peaks, costs less to administer, and requires exactly one line item on the finance team's ledger.

How CSV2GEO's shared team account actually works

The mechanics matter. Here is what is real and what is not.

One person — the owner — holds a monthly batch-geocoding subscription. They invite teammates by email from account settings. Each invited person keeps their own login, their own password, and their own CSV2GEO account. Nobody shares credentials. The invite flow is an email link; if the invited address already has a CSV2GEO account, it activates immediately. If not, the invite stays pending and auto-activates the moment that person registers using the same email.

Once accepted, invited members can use the web batch tool — upload a CSV or Excel file, map the address columns, geocode, download the result — and the address-row credits consumed come from the owner's pool, not from the member's own account. The owner's dashboard shows per-member usage: how many rows each person has consumed in the current billing cycle. That is the visibility that lets the owner spot if one project is consuming a disproportionate share of the month's budget.

A few mechanics that catch teams out if they skip the documentation.

The shared pool is for the web batch tool, not the REST API. Developer API keys are issued per user, metered independently, and not pooled. There are no sub-keys, no per-key caps configurable from the team dashboard, no way to draw REST API credits from a shared pool — do not design an architecture that assumes otherwise. If your team's primary workflow is automated pipelines calling the REST API directly, the team account feature is not the right lever. The right lever is caching aggressively and managing concurrency sensibly — see Concurrency Tuning — Finding the Geocoding Sweet Spot for that pattern.

Members with their own active subscription spend their own balance first. The shared pool is the fallback, not the override. If Alice decides to keep her own personal CSV2GEO subscription active after joining the team account, her usage draws from her own balance until it is exhausted, then falls back to the owner's pool. This can be useful (Alice's project budget covers her own rows; the team pool covers everyone else's) or confusing (the owner's dashboard shows Alice consuming zero rows when she is actually very active). Make the policy explicit during onboarding: either members cancel their individual subscriptions when they join the team account, or the owner acknowledges that their dashboard undercounts that member's true activity.

The seat limit is per-plan, default five members. The owner can remove a member's seat at any time, freeing it for someone else. If your team exceeds the default cap, contact support — the limit exists in the plan definition, not as a hard technical barrier that cannot be adjusted.

Credits are address rows, not API calls. A file with 50,000 rows costs 50,000 credits. A file with one row costs one credit. The per-call REST pricing page at csv2geo.com/pricing/api covers the developer API; the batch tool subscription is a separate metered product. Do not conflate the two when sizing a plan.

The procurement economics

Let us put numbers to the five-person team above using only the publicly documented starting points. The free tier provides 3,000 requests per day for trialling — useful for pilots, not sized for production. Paid tiers start at $54/month for 100,000 calls as documented on the pricing page.

Without a shared pool, the team is procuring five separate subscriptions, each sized to each person's individual peak. With a shared pool, the owner holds one subscription sized to the team's aggregate peak demand — which is almost always lower than the sum of individual peaks because not everyone is at peak simultaneously.

Three structural reasons the shared pool wins on economics.

Aggregate demand smooths individual peaks. Alice's 160,000-row months do not coincide with Caro's 60,000-row months every month. The pool only needs to cover the realistic aggregate peak, not the theoretical simultaneous peak of everyone running their biggest file on the same Tuesday morning.

Idle capacity is shared, not stranded. Dan's subscription, in a per-seat world, sits mostly unused but continues billing. In a shared-pool world, any unused capacity Dan would have consumed is available to Alice when she has a large renewal file. Nothing is stranded.

One invoice, one reconciliation, one renewal decision. Finance teams price procurement overhead at real money. Five subscription renewals, each with a different billing date, each generating a separate invoice, each requiring a separate cost-centre code, is not a free administrative activity. One line item is one line item.

The honest caveat: if every member of your team genuinely needs the REST developer API as their primary interface — not the web batch tool — the shared pool does not apply to that workflow. In that case the right procurement conversation is about total call volume across all engineers, caching strategy, and whether a single high-volume REST plan owned by the team's infrastructure account makes more sense than per-engineer API keys. The economics are the same (aggregate demand beats individual peaks) but the mechanism is different.

How to set up and operate the shared account

Step 1: Audit actual usage before you pick a plan size

Do not guess. Pull the last three months of geocoding demand from every team member who currently has an individual subscription or has been running files ad-hoc. Identify:

• The realistic monthly peak (the worst month in the last year, not the worst week extrapolated)
• The realistic average month
• Which members are active every month versus seasonally active

Size the shared pool to the realistic peak, not the average. Sizing to the average means you hit the cap in heavy months and have to scramble for a plan upgrade mid-cycle — plan upgrades should be deliberate, not reactive.

Step 2: Designate one owner and clarify their responsibilities

The owner holds the subscription, pays the invoice, and can see per-member usage. In most teams this is the data engineering lead, the head of analytics, or whoever already owns the data-tooling budget. The owner is not a gatekeeper to the tool day-to-day — members invite themselves by accepting the email — but they are the person who gets paged if the pool runs dry on the 15th of the month.

Write down three things before you send the first invite: who the owner is, what the per-member soft limit is (e.g. "no single project should consume more than 40% of the monthly pool without flagging the owner first"), and what happens when a new member needs access. These three things prevent the most common operational headaches.

Step 3: Invite members from account settings

From the owner's account settings page, enter each team member's email address. Each person receives an invite email. If they already have a CSV2GEO account under that address, access activates immediately. If not, the invite is pending until they register with the same address.

A note on the external consultant case (Eve from the example above): invite her during her active quarter; remove her seat when the engagement ends. The owner can remove a member's seat from the same account settings page at any time. Removing a seat does not delete the member's CSV2GEO account — it just stops them drawing from the shared pool. If Eve returns next quarter, invite her again.

Step 4: Establish a usage-review cadence

The owner's dashboard shows per-member row consumption for the current billing cycle. A five-minute review on the first of each month answers three questions: Is total consumption tracking below the plan cap with enough margin? Is any single member consuming a disproportionate share? Are there any members showing zero usage who still hold a seat?

If you do not do this review monthly, you will discover you are 90% through the pool on the 20th of the month with ten days left and no clear picture of what drove the overage. That is a recoverable situation (upgrade the plan, understand the cause, adjust the cap conversation with the relevant team) but it is an avoidable one.

Build the review into an existing monthly data-team ritual — the sprint retrospective, the analytics stand-up, wherever your team already discusses tooling — rather than as a separate calendar item. A separate calendar item gets cancelled; a five-minute slot appended to an existing meeting does not.

Step 5: Handle the REST API workflow separately

Reiterate this clearly at team onboarding, because it is the assumption that causes the most confusion: the shared pool governs the web batch tool only. Engineers who are calling the REST API directly from code — automated enrichment pipelines, real-time geocoding in an application backend, scripts that run on a scheduler — are using their own API key, their own per-user call balance, and their own rate limits.

Those engineers should read Rate Limiting — Token Bucket vs Leaky Bucket and Observability for Geocoding Pipelines to manage their REST usage. The shared pool does not absorb REST overage; there is no mechanism that does. If your team has a mix of batch-tool users and REST API users, make sure both groups understand which pool applies to their workflow. A diagram on the internal wiki saves the same explanation from happening four times in Slack.

Failure modes to design around

Three things that reliably catch teams in their first billing cycle with a shared pool.

Unannounced large files. A team member runs a one-time data-quality project that requires geocoding 180,000 addresses in a single upload. If the shared pool is sized to 200,000 rows for the whole month and this is the third week, the pool hits zero and everyone else's work blocks. Fix this with a communication norm, not a technical control: large one-off jobs (anything over, say, 20% of the monthly pool) get flagged to the owner before they run, not after. This is a people process, not a platform feature.

Pending invites that never activate. The owner sends an invite to a contractor whose email address differs from the one they register with. The invite sits pending indefinitely; the contractor cannot access the pool; they start running files from their own paid account instead; the owner's dashboard shows them consuming zero rows when they are actually active. Follow up on pending invites after 48 hours. If the invite has not activated, verify the email address with the invitee directly.

Members retaining active personal subscriptions. As noted above, a member with their own active subscription draws from their own balance first. If you want the shared-pool dashboard to accurately reflect total team consumption, team members should cancel their individual subscriptions when they join the pool. If you want a hybrid model — certain members cover their own rows, the pool covers the rest — document which members are in which category so the owner's dashboard is interpreted correctly.

A note on REST API keys for engineers

Because this comes up in every procurement conversation: CSV2GEO API keys are issued per user at /api-keys. There is no concept of a team API key, a sub-key with a per-project cap, or a shared API key with per-member rate limits. Each engineer has their own key, their own call balance, and their own rate limit.

If your team wants to centralise REST API billing — one invoice for all engineering usage — the current mechanism is for one account (typically a service account owned by the data engineering function) to hold a plan, and for all automated pipelines to use that account's API key. That is a sensible pattern for production pipelines. The person who owns the service account is responsible for monitoring its usage; the Observability for Geocoding Pipelines post covers what to instrument.

This is distinct from the shared team-account pool, which is a batch-tool feature. Do not try to make one mechanism do the job of the other.

Cost model for a realistic team

Working through the five-person insurance team example with only publicly documented numbers.

The team's realistic monthly peak is around 250,000 address rows — Alice's 160,000, plus Caro's 60,000, plus Bob's 20,000, plus a buffer for Dan's ad-hoc work and any partial month from Eve. Individual plans sized to each person's peak would collectively overshoot this number because each plan must independently cover its owner's worst-case month.

The shared pool needs to cover the aggregate realistic peak: roughly 250,000 rows in a heavy month. Check the current published brackets at csv2geo.com/pricing/api to find the right tier — the pricing page is the authoritative source; do not use any figure from this post as the current price, because prices update and this post does not.

In lighter months — Eve off-cycle, Alice's renewals on a quarterly rather than monthly cadence — the actual consumption may be well under 100,000 rows. The pool does not penalise unused rows within the plan cap; they simply do not get drawn. The owner pays for the ceiling they negotiated, not for the floor of what was actually used in any given month. That is the same dynamic as any subscription — size the ceiling to the realistic peak, accept that light months underfill it, and treat heavy months as the constraint you are actually managing.

The free tier (3,000 calls per day, no credit card) is the right starting point for piloting the workflow before committing. A 3,000-row daily cap is enough for each team member to validate that the column-mapping workflow fits their data format and that the output geocoding quality meets the project's accuracy threshold. Do not try to run production workloads on the free tier — it is a trial instrument, and the daily cap will interrupt a large file mid-run if the rows-per-day limit is hit.

Frequently Asked Questions

Does each team member need to share the owner's password? No. Each member keeps their own CSV2GEO login and password. The invite grants access to draw from the owner's credit pool; it does not give the member any access to the owner's account settings, billing details, or API keys.

What happens if the shared pool runs out mid-month? Members without their own active subscription will be unable to process new batch files until the pool is refilled — either by the owner upgrading the plan or waiting for the next billing cycle. Members who have their own active subscription will continue drawing from their personal balance. This is why sizing the pool conservatively above the realistic peak matters, and why the monthly usage-review cadence exists.

Can the owner see what files each member uploaded? The owner can see per-member row consumption for the billing cycle. The specific file names and contents are not exposed to the owner — members retain privacy over the data they upload, and the owner sees a usage number, not a data audit trail.

Can a member be in multiple team accounts simultaneously? This is not documented as a supported configuration. Treat each member as belonging to one team account. If a contractor works across two client engagements that both use CSV2GEO team accounts, the practical path is a separate email address per engagement.

If we invite a member and then remove them, do they lose their own CSV2GEO account? No. Removing a member's seat revokes their access to the shared pool only. Their personal CSV2GEO account and any personal subscription they hold are unaffected. They can continue using their own account independently; they simply cannot draw from the owner's pool.

Does the shared pool apply to the REST API? No. The REST API is metered per user, per API key, independently of the shared batch-tool pool. There is no mechanism to pool REST API credits across team members. See the API pricing page and the per-user key management at /api-keys for the REST usage model.

What is the default seat limit and can it be raised? The default is five members per plan. The owner can remove a member to free a seat at any time. If your team exceeds five, contact CSV2GEO support — the limit is a plan-level configuration, not a hard technical ceiling.

Related Articles

• Benchmarking geocoding APIs — honest numbers — what to actually measure when evaluating a geocoding vendor for team use
• Caching geocoding results — 90% cost reduction — the complementary lever to pool sizing: fewer rows consumed means the shared pool goes further
• Observability for geocoding pipelines — how to instrument per-engineer REST API usage so the service-account model stays visible
• Concurrency tuning — finding the geocoding sweet spot — relevant when engineers on the team are running parallel REST pipelines against their own keys
• Rate limiting — token bucket vs leaky bucket — the mechanics behind per-key rate limits that apply to individual engineer API usage outside the shared pool

---

*I.A. / CSV2GEO Creator*