Shared team accounts: batch geocoding for the whole company

Most companies end up with three or four separate geocoding logins before anyone notices. The operations team signed up first because they had a delivery file to clean up. The sales team created their own account a quarter later because they did not know operations already had one. Someone in the data team ran a one-off enrichment on a personal login and expensed it. Now there are several monthly invoices, several separate balances, several people who each believe they own "the geocoding account," and a finance team that cannot tell you the total annual spend to within fifty per cent.

This is the problem a shared team account solves. One subscription, one pooled balance of address rows, and the people who need to geocode invited onto it by email. When the operations team has a quiet month the unused capacity sits in the pool and covers the data team's quarterly backfill the following week. There is no inter-team budget negotiation, no duplicated subscriptions, and one place to look when finance asks what geocoding actually costs.

This post explains what a shared team account is on CSV2GEO, how to set one up for a company with several people who need to batch geocode, and the operational habits that keep it tidy as the team grows.

What a shared team account actually is

A shared team account is built around a single monthly subscription. One person — the owner — holds the subscription and its balance of address rows. From their account settings, the owner invites colleagues by email. Each invited teammate keeps their own login and their own password; what they share is the owner's subscription balance.

That distinction matters, so it is worth stating plainly. A shared account does not mean everyone logs in as the same user with one shared password. It means each person has their own named account, and the geocoding work they do is billed against a common pool rather than against individual subscriptions. Everyone uploads their own files, runs their own batch jobs, and downloads their own results — but the rows they consume all come out of one balance.

Because each member keeps a distinct login, usage is attributable. The owner can see how many rows each invited member has consumed. That per-person breakdown is the difference between "we spent a lot on geocoding last quarter" and "the data team's customer-database refresh used most of the pool in March, which is exactly what we expected."

Why one pool beats several separate accounts

The economics case comes first because it is the one finance cares about.

Three teams each running their own subscription each pay for a plan sized to their own peak month. The operations team sizes their plan for their busiest week; the sales team sizes theirs for the quarterly territory rebuild; the data team sizes theirs for the annual enrichment. Each plan carries headroom that goes unused most of the year, and you are paying for three sets of headroom. A single pooled subscription needs only enough headroom to cover the combined peak — which, because the three teams rarely peak in the same week, is far smaller than the sum of three separate buffers.

The variance case is stronger. Consider what happens when the data team kicks off a quarterly refresh of the full customer database — hundreds of thousands of address rows, processed over a weekend. On a separate subscription sized for their normal monthly volume, that job blows through the month's allowance on Saturday morning and stalls. On a shared pool, the same weekend job draws against a balance that operations and sales were not touching over the weekend. The pool absorbs the spike automatically, with nobody upgrading a plan at 9am on a Saturday.

The visibility case is the one that quietly saves the most pain. One subscription means one balance, one renewal date, one invoice, and one list of who is using it. When the geocoding line item comes up in an annual software review, you have a single dashboard that shows total consumption and a per-person split, rather than three logins owned by people who may have since left the company.

How invitations work in practice

The mechanics are deliberately simple, and they are worth understanding before you start adding people.

The owner opens their account settings, enters a colleague's email address, and sends the invitation. What happens next depends on whether that email already belongs to a CSV2GEO account:

• If the person already has an account, they are added to the team immediately and can start drawing from the shared pool straight away.
• If they do not have an account yet, the invitation is held as pending. They see access the moment they register with that same email address — the pending invitation links itself to their new account automatically on sign-up. You do not need to re-invite them after they register.

There is a seat limit, and it depends on the plan. By default a subscription allows up to five team members; some plans allow more. When you reach the limit, the next invitation is declined with a message telling you the maximum for your plan, so you are never surprised by a silent cap.

One nuance is worth internalising for people who already pay for their own subscription. If an invited teammate has their own active subscription, their own balance is used first; the shared pool is the fallback for members who do not have a subscription of their own. In practice this means you invite the people who need geocoding capacity but do not have it — not people who are already paying for their own plan, since their personal balance would be spent before the shared one.

Removing someone is just as direct. When an employee leaves or changes role, the owner removes their seat from settings; the freed seat is immediately available for the next invitation, and the departing member can no longer draw from the pool.

Step-by-step: setting up a shared team account

Five steps take you from a fresh subscription to a running multi-person setup.

Step 1: Choose a plan sized for the combined volume

Add up the monthly row volume your teams expect — operations files, sales territory rebuilds, data enrichment runs — and pick a plan that covers the aggregate, not each team separately. The pooled model is the whole point: one plan covers everyone. If you are not certain of the numbers, the free tier (3,000 calls per day) is enough to validate the workflow end to end before you commit, and the full plan options are on the pricing page.

Step 2: Invite your teammates by email

From your account settings, add each colleague by their work email address. Use the email they will actually register with or already use — the invitation links to the account on that exact address. Invite the people who need geocoding capacity and do not already pay for their own plan; those who have their own subscription will spend their own balance first regardless.

Step 3: Have new members create their account

Anyone you invited who does not yet have a CSV2GEO account simply registers with the invited email address. The pending invitation activates automatically on sign-up — there is no second step, no code to paste, and no need for the owner to re-send anything. Existing-account holders are active the moment they are invited.

Step 4: Run batch jobs from each member's own login

Each member logs into their own account, uploads a CSV or Excel file of addresses, maps the columns, and runs the geocode. The rows they process draw from the shared pool. Results are theirs to download. Nothing about the day-to-day batch workflow changes for the individual — the only difference is where the credits come from. If you are new to the batch flow, the walkthrough in how to geocode a large file covers the upload-and-map steps in detail.

Step 5: Watch per-member usage and manage seats

Back in the owner's settings, review the per-member usage figures periodically. They tell you which team is consuming the pool and roughly when, which is exactly what you need to size next year's plan or to explain a sudden jump in consumption. When someone leaves the company or no longer needs access, remove their seat so the capacity returns to the pool and the headcount stays accurate.

Using the API instead

It is worth being precise about scope, because teams sometimes assume the shared subscription also pools their developer API usage. It does not, and conflating the two leads to confusion.

The shared team account governs the batch geocoding tool — the upload-a-file, map-the-columns, download-the-results workflow that most of a company will use. The developer REST API is a separate surface with its own per-user keys, managed under your API keys page, and metered independently. If three engineers integrate the API into three services, each uses their own key; those calls are not drawn from the shared subscription pool.

That separation is usually what you want. The people writing CSVs and the people writing code have different needs, and keeping the two metering models distinct means a runaway integration test cannot drain the balance your operations team depends on for its weekly delivery file. If you want a single number for total geocoding spend across both surfaces, reconcile the subscription dashboard and the API usage figures at month-end. For the relative cost of each approach, the pricing breakdown lays out the real per-address numbers.

Failure modes specific to shared accounts

Three things behave differently in a shared setup than on a single login, and knowing them in advance saves a support ticket.

The pool is shared, so one large job affects everyone. A data enrichment run that consumes most of the balance leaves less for operations until the renewal date or a top-up. This is a feature — the pool is meant to flex — but it means large, predictable jobs should run on a schedule the team agrees on rather than landing unannounced mid-month. Treat the pool like any other shared resource: large consumers tell the others before they run.

A member's own subscription takes precedence. If you invite someone who already pays for their own plan expecting them to draw from the shared pool, they will not — their own balance is spent first. Invite the people who lack capacity, not the people who already have it, and you avoid the "why is my personal balance going down?" conversation.

Seats do not free themselves. When an employee leaves, their seat stays occupied until the owner removes it. On a five-seat plan that quietly fills up, the next person you try to add is rejected because a former colleague is still holding a seat. Make seat removal part of your off-boarding checklist alongside revoking other software access.

What a healthy shared account looks like

A concrete picture helps, because "pooled credits" is easy to misread.

Suppose a mid-sized company with three groups that geocode. Operations cleans a weekly delivery file of a few thousand rows. The sales team rebuilds territories once a quarter, a larger one-off each time. The data team refreshes the customer database quarterly, the biggest single job of the year. Across a normal month, operations is the steady consumer and the other two are quiet; in the months the quarterly jobs land, consumption jumps and then settles again.

On three separate subscriptions, each group pays year-round for a plan sized to its own peak, and most of that capacity sits idle most of the time. On one shared subscription, the company buys a single plan sized for the combined peak — meaningfully smaller than the sum of three peaks, because the big jobs rarely coincide — and the pool absorbs the quarterly spikes without anyone touching the plan. The owner sees, in one place, that the data team's March refresh used most of that month's pool, which is exactly what everyone expected. That is the whole pitch: less total spend, no surprise stalls, and one honest number for finance.

The operations team, running the same delivery file every week, can stretch the shared pool further still by caching repeat addresses — many of the addresses in this week's file appeared in last week's. The caching patterns post covers the no-code side of de-duplicating an upload before you run it, and the rows you save stay in the pool for the data team's next big job.

Frequently Asked Questions

Does everyone share one login and password?

No. Each team member keeps their own account and their own password. What they share is the owner's subscription balance, not a set of credentials. This keeps usage attributable per person and means you never have to circulate a shared password.

How many people can I add to a shared account?

It depends on your plan. The default is up to five team members; some plans allow more. When you reach your plan's limit, the next invitation is declined with a message stating the maximum, so you always know where you stand. Removing a seat frees capacity for a new invitation immediately.

What happens if I invite someone who does not have an account yet?

The invitation is held as pending. As soon as that person registers with the same email address you invited, the invitation activates automatically and they can draw from the shared pool. You do not need to invite them a second time after they sign up.

If a teammate already pays for their own subscription, which balance is used?

Their own. A member's personal subscription is always spent first; the shared pool is the fallback for members who have no subscription of their own. Invite people who need capacity, not people who already pay for it.

Can I see how much each team member has used?

Yes. The owner's settings show per-member usage, so you can attribute consumption to the right team and size your plan accordingly. This per-person breakdown is the main reason to use a shared account rather than passing one login around.

Does the shared subscription also cover our developer API usage?

No. The shared team account governs the batch geocoding tool — the file-upload workflow. The developer REST API is a separate surface with its own per-user keys, metered independently. Keeping the two separate means an API integration cannot drain the balance your operations team relies on.

What happens when an employee leaves?

The owner removes their seat from settings. The departing member can no longer draw from the pool, and the freed seat is available for the next person. Make seat removal part of your standard off-boarding so a five-seat plan does not silently fill with people who have left.

Related Articles

• Free batch geocoding: how to geocode a CSV file — the no-code upload-and-map workflow each team member uses on a shared account
• How to geocode a large file — handling the big quarterly jobs that a shared pool is designed to absorb
• The best batch geocoding tools — how shared-account batch geocoding compares to the alternatives
• Geocoding API pricing compared — the real cost in 2026 — the per-address numbers behind the pooled-versus-separate decision
• Carving sales territories for a 200-person org in a weekend — a team-scale batch job of exactly the kind a shared pool handles well

---

*I.A. / CSV2GEO Creator*