Software that works well at one location often fails at five in ways nobody predicted at signing. The failure is rarely performance. It is that the product assumed a single set of prices, a single staff list, a single definition of normal, and your five stores have none of those things.
If you run more than one location, here is what actually changes, and how Attergo is engineered for it.
Five connections, not one
Each store connects separately, with its own Basic Auth credentials issued for the Rx Event API at that location. There is no chain wide credential.
That is more setup. It is also the correct answer, for reasons that only become obvious later:
- Revocation is local. Rotating one store’s credentials does not interrupt the other four.
- Attribution is unambiguous. Every event carries the store it came from, so a data question resolves to a location without inference.
- Offboarding is clean. Selling a store, or closing one, means disconnecting one credential.
- Blast radius is one store. A leaked secret exposes one location, not the chain.
The tedious part is real: five locations means five credential issuances, and if your stores are on different upgrade schedules or have different administrators, that is five small coordination problems rather than one.
The thing owners underestimate: cost bases diverge
At one store, acquisition cost is one problem. At five, it is five problems that look like one.
Your locations may buy from different primary wholesalers, sit in different volume tiers, hold different contracts, use different generic sourcing, or run one location with a purchasing arrangement the others do not have.
Which means a chain wide cost table is wrong for at least some of your stores, and the resulting margin comparison is not comparing what you think.
Attergo holds cost per store. The basis label (invoice, NADAC or override) applies per store as well. A fill in store three shows margin against store three’s cost, with store three’s basis.
This produces an uncomfortable but useful outcome. When the same NDC shows different margin at two locations, the cause is either a genuine buying difference or a stale cost file at one of them, and the basis label tells you which. That is worth knowing, and a chain wide average would have hidden it.
Isolation, and who can see what
Tenant isolation is enforced in the database, not only in application code. A query that fails to filter correctly returns nothing rather than another pharmacy’s rows. That protects you from other Attergo customers.
The within chain question is different, and needs a straight answer.
Within the chain, every store’s data is separated and attributable, every user authenticates with mandatory TOTP two factor, and every access to protected health information is written to an append only log that nobody, including us, can edit. If you ever need to answer who looked at which store’s data, the record exists and it is complete.
Access is administered at the organization level, with the full access trail behind it. Whatever scoping policy you run internally, the log means it is enforceable in fact, not just on paper.
Roll ups: what exists and what does not
This is where multi store buyers should press hardest, because a cross store view is easy to mock up and hard to build correctly.
Attergo builds the roll up from the bottom: per fill margin against acquisition cost, per store, with the cost basis shown on every number. Attergo Intelligence is the layer above it, where chain level dashboards, store versus store benchmarking on a like for like basis, and outlier detection across locations live.
The order matters. A cross store comparison built on inconsistent cost bases is worse than no comparison at all: it looks authoritative and is quietly wrong. Attergo refuses to average a store computed from invoice cost against a store running on a reference basis without telling you, which is precisely what makes its comparisons worth acting on. Press any vendor in this category on the same point, and ask to see the cross store view running on real data.
The rest of the platform, and why one connection matters more at five stores
Attergo is eight products: Margin, Billing, Audit, Authorizations, Inventory, Compliance, Intelligence and Integrations. At one store, the argument for a shared spine is architectural elegance. At five, it is a purchasing argument, because every additional integration project multiplies by your store count.
| Product | What it means at five stores |
|---|---|
| Margin | Per store margin, per store cost basis |
| Billing | Encounters to medical claims on the same feed |
| Audit | Response assembly from the per store archive |
| Authorizations | Prior authorization tracking across locations |
| Inventory | Purchasing against real demand, per store |
| Compliance | Licenses and controls across every location |
| Intelligence | The cross store layer described above |
| Integrations | The spine all of it runs on |
Every product arrives on the connections you already made. At five sites, that is five onboarding projects you never run.
Pricing at five stores
Pricing is per store, per month:
| Tier | Price per store per month |
|---|---|
| Margin | $199 |
| Margin plus Audit | $349 |
| Full platform | $499 |
Five stores on Margin is $995 per month, and volume terms apply from the fifth store. If a vendor’s pricing page is silent on multi store, ask before you get attached to the product.
A sane rollout order
- Connect one store first, ideally your most typical rather than your best or worst. Verify events arrive and the numbers look like the store you know.
- Load that store’s cost file and watch how much the margin picture moves from the NADAC baseline. That delta tells you how much cost accuracy matters in your business.
- Connect the rest, one at a time, each with its own credentials.
- Load cost per store, resisting the temptation to reuse one file across locations that buy differently.
- Then turn on the cross store view, once every location’s cost basis is clean enough that the comparison means what it appears to mean.
Questions to ask any vendor if you run multiple stores
- Is pricing per store, and is there a chain rate?
- One credential or one per location?
- Can cost data differ per store, or is there a single chain table?
- How is manager access scoped, and is every access logged immutably?
- Can I see the cross store dashboards running on real data?
- If I sell a store, how does its data get separated out?
The summary
Five stores means five connections, five credential sets, five cost bases and five sets of numbers that are individually accurate, which is the only foundation a truthful chain view can stand on. Tenant isolation, mandatory two factor and the append only access log hold at every location.
The reason Attergo is strongest at multiple locations is that the connection you make once carries all eight products. Every store you add compounds the value of the spine, and none of them adds an integration project.