POS Data Integration: Connect Sales to Training

Want to know which store behaviours actually move sales? The POS Data Integration brings your point-of-sale figures into Atobi and puts them next to everything the platform already knows about a store — product knowledge, visual compliance, task execution and responsiveness. 💰

🔑 Who Can Access It

The store dashboards are gated by their own permission — Store Dashboard — which is separate from the Dashboard Access permission that covers the analytics dashboards such as Compliance and Member Status. A member can have one without the other.

What a member sees is then set by their access level:

Local Access 📍 — sales data for their responsible locations and sub-locations only.
Global Access 🌍 — sales data across all locations.

Note: Atobi's location hierarchy and data access controls apply to sales data exactly as they do everywhere else. A store manager sees their store, a regional manager sees their region — and nothing more.

🔌 How the Integration Works

Atobi does not replace your sales reporting. It receives the sales data you already have and joins it to what happened in Atobi — who was trained, which campaign ran, which store completed what.

How the data arrives

You send us files in a standard CSV format through a secure Atobi API endpoint. There is no manual upload step and no scraping of your systems: your side pushes a file on whatever schedule suits you — nightly is typical — and the data is loaded automatically.

When you order the POS data integration module, Atobi issues you the endpoint and the authentication details, along with the full technical specification for each file type.

💡 Tip: If your data sits in JSON rather than CSV, tell us — we configure a solution rather than asking you to rebuild your export.

How the data is matched

The join happens on two keys you already have:

Store — a store in your sales data is matched to a location in Atobi.
Employee — where you send employee-level sales, they are matched to the individual member.

From there, every Atobi metric for that location or member can be read next to its sales figures.

Note: Because the match runs on store and employee identifiers, your Atobi locations and members need to correspond to the stores and staff in your sales data.

Corrections and segments

Data can be sent per segment — by country or department, for example — so different parts of the business can deliver independently. If you resend a file covering a period you have already sent, the newer file overwrites the overlap, which is how corrections are made.

📦 What You Can Send Us

Six data sets are supported. Most customers start with sales records and store targets, then add the rest over time.

Data set	Broken down by	What it unlocks
Sales records	Date, store, employee, transaction, brand, category, product family, sales type	The core figures — turnover, baskets, items per basket, splits by brand and category
Store sales targets	Date, store	Performance read against what the store was asked to do, not only against other stores
Employee sales targets	Date, employee	Individual progress against target
Footfall	Date, store	Conversion rate — how many visitors became transactions
Inventory	Date, store, brand, category, product family	Sell-out read against stock, so a flat week can be separated from an empty shelf
Loyalty members	Date, store	Club sign-ups and the split between member and non-member sales

💡 Tip: Send targets as well as actuals. Without targets, a store can only be compared to other stores — which is unfair to the small ones and flattering to the big ones.

📊 What You Get Out of the Box

Two dashboards come with the module, both available on web and in condensed mobile versions:

All Store 🏬 — for store managers, regional managers and HQ. Compares performance against targets across all stores in scope.
My Store 🙋 — for the individual employee. Compares their own performance against the same period last year and benchmarks it against colleagues in the same store.

Metrics tracked

Turnover month-to-date vs. target month-to-date
Basket size vs. the same period last year
Average items per basket, month-to-date vs. target
Turnover split by brand
Turnover split between loyalty club members and non-members
Hit rate — conversion of store visitors

Filter and drill by

Stores (locations in Atobi)
Brand
Product category
Product family
Employee profession

🧩 Reading Sales Next to Behaviour

This is what makes the integration worth doing. Most platforms can show you one variable against sales: did they complete the training, did they sell more. Atobi already holds several measured behaviours per store, on the same key as your sales data.

Signal	What it tells you
Product knowledge	Training completion and quiz scores
Visual compliance	Whether the store looks right — photo evidence from the floor
Campaign readiness	Whether the store was ready before the campaign went live
Operational execution	Task and action completion, and whether it happened on time
Responsiveness	How quickly the store reads and acts on what you send
Competition behaviour	Whether the store takes part, and whether it wins
Sales vs. target	Not only what a store sold, but what it was aiming at

❓ Key Questions It Answers

Which of these actually relates to sales in our network?

The point of holding several signals rather than one is that you can find out, instead of assuming it is the training.

Did the campaign move anything?

Sales before, during and after, per store, alongside whether that store was ready and executed.

Which stores are trained but not selling?

High knowledge with flat sales points somewhere else — stock, footfall, price, or a display that was never built. The inventory and visual compliance signals usually tell you which.

Which stores are selling without being trained?

Often the most useful question. It shows where the upside is if the training can be made to land.

🧮 Getting Past Correlation

Most companies compare two columns: staff knowledge and sales. Stores with higher completion sell more, so training works. That conclusion is usually unsafe, and it is worth understanding why before you put it in front of a board.

⚠️ The confound that catches everyone

Store managers who are good at driving sales are often also good at driving their staff to complete training. If that is true in your network, completion and sales will move together whether or not the training did anything at all. The manager is causing both, and a two-column correlation cannot tell the difference.

✅ What to do instead

Because Atobi holds several store-level signals rather than one, you can run a multivariate variance analysis — a calculation that asks how much of the variation in sales each signal explains once the others are accounted for.

"Knowledge explains roughly this share of the sales difference between our stores, after allowing for visual compliance, task execution, responsiveness and store size."

That is a number that survives scrutiny, because the obvious alternative explanations have been put into the model rather than left out of it.

Note: This is not a button in the platform. Export the data from the dashboards and have whoever does your analysis run it. What Atobi provides is the thing that makes it possible: more than one measured behaviour per store, on the same key as your sales data.

⚠️ What POS Data Can and Cannot Tell You

Worth being straight about this, because it protects the conclusions you draw.

Linking completion to store-level sales gives you a strong signal and a place to look — not proof of cause. Many things move in-store sales besides whether someone passed a quiz: footfall, stock availability, weather, pricing, promotions and the display all matter, often more than knowledge in any given week.

A variance analysis is much stronger than a correlation, but it still only controls for what you measured. Something you did not measure — a refit, a new competitor across the street, a local stock problem — can still be the real driver.

To get closer to cause, the next step is a controlled pilot: run the activation with a defined group and compare against a comparable group that did not get it. That is where a defensible lift number comes from, and it is the one that survives a budget review.

💡 Tip: Use the platform signals to find what is worth testing. Use a controlled pilot to prove it. A single store's week is not evidence; fifty stores over a quarter, compared against similar untrained stores, is.

🛠 Setting It Up

POS data integration is an add-on module, not part of the standard platform. Getting it running looks like this:

Order the module through your Atobi contact. You receive the API endpoint, authentication details and the full file specification.
Map your stores to Atobi locations. This is the step that decides whether the rest works, so it is worth doing carefully before any data flows.
Build the export on your side — your BI team, ERP partner or POS vendor produces the CSV files to the specification.
Send a test file and we validate the format together.
Schedule the delivery — usually a nightly push.
Dashboards go live for the roles you have given the Store Dashboard permission.

Note: The heaviest part of the work is almost always on the data side — producing a clean, consistent export from your own systems. Involve whoever owns your POS or ERP data early.

📊 Your Guide to Atobi Dashboards

✅ Advanced Dashboards - Compliance

🔎 Understanding Dashboard Metrics

🎯 Actions in Atobi