Sales Integration
Stop typing the same sale into your POS and into vimigo. Let your POS feed sales straight into vimiSales so commission updates itself.
Why you need this
Without this feature, every sale gets entered twice - once by the cashier into your POS, once by the staff member or manager into vimigo. Two consequences follow.
The smaller one is wasted time - five minutes a day per person, more if your team forgets and has to backfill at month-end. The bigger one is trust drift: when commission depends on a number staff type in themselves, every reward conversation eventually becomes a "but I sold more than that" argument with no clean source of truth. The boss starts double-checking. The boss stops double-checking. Trust in the reward system erodes. The whole point of vimigo - making the reward system run itself - quietly breaks.
Sales Integration fixes both. Your POS, CRM, ERP, or accounting software pushes every sale to vimigo automatically. The staff member sees their commission tick up in real time without lifting a finger. The boss sees one source of truth - the same number that's already on the receipt. No re-entry, no arguments, no drift.
You should turn this on if:
- You already use a POS / CRM / ERP / e-commerce platform / payroll system, and
- Your sales staff are tired of updating sales manually, or you don't trust the manually-updated numbers, or you spend hours reconciling at month-end.
You should NOT turn this on if:
- You don't have a digital sales system (you write receipts on paper or use a spreadsheet) - in that case keep using vimiSales' manual-entry workflow.
How it works (the 30-second version)
Your POS rings up a sale
↓
Your POS sends it to vimigo (one HTTP call, instant)
↓
vimigo holds it in a queue
↓
Every 5 minutes vimigo processes the queue:
- finds the matching staff member
- finds the right vimiSales setting (using the Tag - see below)
- adds the amount to that staff member's running total
↓
Staff member sees their commission update in the app
You don't see the queue most of the time - sales just appear. You only touch the queue when you first set up (mapping who is who) or when something goes wrong (a name typo, a missing tag).
What you need before starting
Three pieces:
- A POS / CRM / ERP that supports vimigo's Sales Integration API. Ask your vendor. We've worked with SQL Account, EasySales, TunaiPos, 33CRM, Zapier, Payroll Service, and others. If your vendor doesn't already integrate, they can - point them to the developer docs the vimigo team will share with them.
- The Sales Integration module enabled on your vimigo account. Ask your vimigo customer success manager - it's a one-click toggle.
- API credentials issued by vimigo. Your vimigo CSM hands you four values -
client_id,client_secret,email,password. You give these to your POS vendor. They store them and use them to push your sales.
That's the full setup cost. Once it's done you don't need to think about credentials again.
Understanding Tags - the only thing you really need to learn
Tag is the single concept that makes Sales Integration tick. If you understand Tag, you can run the integration. If you don't, you'll be confused forever. So we'll go slowly.
What Tag is
Tag is a number (like 1, 2, 3) that the vendor includes in every sale they push. The number itself doesn't mean anything to vimigo - it's a label your vendor and you agree on.
You decide what each Tag means by mapping it to a vimiSales setting (or a vimiTeam team) inside vimigo.
Why Tag exists
A typical SME has more than one thing being measured.
A car dealership might track:
- New car sales (one vimiSales setting, monthly target)
- After-sales service revenue (another setting, weekly target)
- Insurance attachment (a third setting)
When the POS pushes a sale, vimigo has to know which of those three to credit. The POS doesn't know your vimigo settings (and shouldn't have to - if you renamed "New Car Sales" tomorrow, you'd have to call your vendor). So instead the POS uses a stable number - Tag 1 always means "new car sale", Tag 2 always means "after-sales", Tag 3 always means "insurance". Your vendor commits to using those numbers consistently. You commit to keeping the mapping right inside vimigo.
How to use Tag (step by step)
You'll do this once during setup, then occasionally when you add a new vimiSales setting.
Step 1 - Decide the Tag scheme with your vendor. Sit down (or have a call) and write down what each Tag will mean in your business. Example:
| Tag | What it represents in our POS |
|---|---|
| 1 | New car sales |
| 2 | After-sales service |
| 3 | Insurance attachment |
Your vendor codes their POS to send the right Tag for each transaction type. From that moment on, the POS will always use these numbers.
Step 2 - Set up the matching vimiSales settings in vimigo. Create one vimiSales setting per Tag:
- "New Car Sales" setting
- "After-Sales Service" setting
- "Insurance Attachment" setting
(Or vimiTeam settings if you measure team-wide rather than per-person.)
Step 3 - Map each Tag to its vimiSales setting. Open Settings → vimiSales Integration in vimigo. Go to the Link vimiSales tab. You'll see one row per Tag your vendor has ever sent. For each, pick the matching vimiSales setting from a dropdown.
Step 4 - Map each sales person. Open the Link Sales Person tab. You'll see one row per person identifier your POS has sent (this is whatever your POS calls each staff member - usually their name). For each, pick the matching vimigo user.
Step 5 - You're done. Future sales now flow automatically.
The six Tag scenarios (what vendor and customer must do, by case)
These cover every situation we've seen across customers. Find the one that matches your setup.
Scenario 1 - Single setting, single Tag (most small SMEs)
You have one vimiSales setting. Your POS sends Tag 1 on every sale.
| You set up | Vendor sends | You do in vimigo |
|---|---|---|
| 1 vimiSales setting "Sales A". John is in it. | Tag 1 | Link John Doe → John (Link Sales Person tab). Link Tag 1 → Sales A (Link vimiSales tab). |
Scenario 2 - One Team, single Tag
You measure as a team rather than per-person.
| You set up | Vendor sends | You do in vimigo |
|---|---|---|
| 1 vimiTeam team "Team A". John is on it. | Tag 1 | Link John Doe → John. Link Tag 1 → Team A. |
vimigo doesn't care whether Tag 1 maps to a vimiSales setting or a vimiTeam team. You pick which.
Scenario 3 - Multiple teams, push lands on one
You have three teams. John is only on one of them (Team B). Your vendor still uses Tag 1 for all his sales.
| You set up | Vendor sends | You do in vimigo |
|---|---|---|
| 3 teams (A, B, C). John is on Team B only. | Tag 1 | Link John Doe → John. Link Tag 1 → Team B (not A or C - John is not on those). |
Watch out: if you accidentally link Tag 1 to Team A or C, John's sales will pile up as failures because he isn't on those teams. The fix is to unlink and re-link to Team B.
Scenario 4 - John is on two teams, vendor uses different Tags to disambiguate
This is the canonical reason multi-Tag exists.
| You set up | Vendor sends | You do in vimigo |
|---|---|---|
| 3 teams. John is on Team A and Team C. | Tag 1 (for Team A sales) or Tag 2 (for Team C sales) | Link John Doe → John. Link Tag 1 → Team A. Link Tag 2 → Team C. |
The POS knows which team a sale belongs to (e.g. by the cashier picking a department). The Tag number carries that decision over to vimigo.
Scenario 5 - One Tag drives multiple updates (fan-out)
Sometimes a single sale should count toward both an individual setting AND a team setting.
| You set up | Vendor sends | You do in vimigo |
|---|---|---|
| 3 teams + 2 vimiSales settings. John is in Team B, Team C, Sales A, Sales B. | Tag 1 | Link John Doe → John. Link Tag 1 → Team B AND Tag 1 → Sales A (two mappings, same Tag). |
A single push of RM 10,000 ends up crediting both Team B and Sales A with RM 10,000 each. Useful for stores where the staff get individual commission AND the store as a team has a target.
Be careful with double-counting. If your team setting is supposed to be the sum of all individual sales (not a separate scoreboard), don't fan-out - let the team setting aggregate from the individuals instead.
Scenario 6 - Nested settings (Team's own Sales A, Sales B)
Sophisticated companies have nested settings: each team has its own copy of "Sales A" and "Sales B".
| You set up | Vendor sends | You do in vimigo |
|---|---|---|
| 3 teams. Each team has nested Sales A and Sales B. John is in Team B and Team C. | Tag 1 (for Team C's Sales B) | Link John Doe → John. Link Tag 1 → Team C / Sales B (the nested one, picked from a hierarchical dropdown). |
The Link vimiSales dropdown shows the nested hierarchy. Pick the exact spot the sale should land in.
Tag rules of thumb
- Tag is your call. Your vendor doesn't decide what Tag 1 means. You do.
- Tag is per-customer. Tag 1 in your account is unrelated to Tag 1 in another customer's account. Don't worry about it.
- Tag must exist in vimigo before it's used. A vimiSales setting must already be created (which creates the Tag in the background) before your vendor can push with that Tag. Otherwise the push fails with "tag not supported".
- A Tag can map to many things or nothing yet. Mapping is a
personal_tagsrow - one row per Tag-to-setting link. You can have a Tag with zero mappings (then sales fail until you add one) or many mappings (then sales fan out).
Setting up the integration (full walkthrough)
This is the one-time setup flow.
- Talk to your POS / CRM vendor. Ask whether they already integrate with vimigo. If yes, they'll tell you what to do next on their side. If no, ask them to look at vimigo's developer docs (we provide a vendor-facing API document - your CSM will share the link).
- Tell your vimigo CSM that you want to enable Sales Integration. They'll switch on the module and create OAuth credentials for your vendor.
- Receive credentials. Your CSM sends you four values:
client_id,client_secret,email,password. Treat these like passwords - share them only with your vendor. - Hand credentials to your vendor. Share via your vendor's secure channel (their portal, an encrypted email, etc.).
- Wait for the vendor's first test push. They'll send one or two test sales as a smoke test. Open
Settings → vimiSales Integration → Queuetab in vimigo - you should see them appear within seconds. - The test pushes will be in
FAILstatus. That's normal - nothing is mapped yet. - Map Tags and Sales People. Use the Link Sales Person and Link vimiSales tabs to set up the mappings (see the Tag scenarios above for which mapping fits your situation).
- Watch the queue go green. As you map, the cron picks up the rows on the next 5-minute pass and they flip to
SUCCESS. Sales now appear on the staff member's vimiSales record.
You're live.
Day-to-day reconciliation (the only page you'll come back to)
Open Settings → vimiSales Integration whenever:
- A new staff member joins - link them in Link Sales Person the first time their name appears.
- You add a new vimiSales setting - create the corresponding Tag mapping in Link vimiSales (otherwise the vendor's pushes for that setting will silently fail).
- A staff member changes their display name in vimigo - re-link them.
- Sales seem to stop appearing - check the Queue tab; filter by status to see what's stuck.
The two failure modes you'll see
| What you see | What it means | Fix |
|---|---|---|
| Row stuck in FAIL, error mentions "user not found" | The name your POS sent doesn't match any vimigo user exactly | Open Link Sales Person, find the unmapped name, link it to the right user. The cron will retry within 5 minutes. |
| Row stuck in FAIL, error mentions "tag not supported" or "no setting matched" | The Tag isn't mapped to any vimiSales setting yet | Open Link vimiSales, find the unlinked Tag, pick the matching setting. |
Both fixes are one-click. The cron picks up resolved rows on the next pass.
You can download the queue as CSV from the Queue tab any time - useful if you need to send it to your vendor for offline reconciliation.
Frequently asked questions
My POS does not support vimigo. Can I still use this? Your vendor needs to add support. The good news is it's a small integration on their side - we provide a complete developer document (the same one we hand to vendors who already integrate). Ask your CSM to share it with your vendor's developer.
My POS sends weird names like "STAFF-042" instead of staff names. Will that work? Yes. The "Sales Person ID" can be any text - a staff number, a name, an email - as long as your POS sends the same value every time for the same person. You then map that value to the vimigo user once in Link Sales Person.
Can I use this without vimiSales 2.0? Possible but unusual. You'd need at least the vimiSales 1.0 (legacy) module enabled. Most customers turn on Sales Integration alongside vimiSales 2.0 at the same time.
What happens if my POS sends the same sale twice?
Each sale has a unique transaction_id from your POS (typically the receipt number). vimigo deduplicates on it - re-sending the same transaction_id is safe. To correct a mis-pushed sale after it's been processed, your vendor sends a new sale with a new transaction_id and your team voids the original inside vimigo.
Can I bulk-import historical sales? Yes. Your vendor uses the bulk endpoint to upload a CSV or Excel file containing many sales rows in one go. Useful for moving historical data when you first switch on the integration.
What about commission payouts - can my payroll system pull approved payouts back from vimigo? Yes. There's a Payouts API that lets a payroll system pull all approved commission payouts (vimiSales, vimiTeam, vimiGoal, even Lucky Wheel cash rewards) and mark them as paid in their own books. Your CSM can connect you with vendors who already do this (e.g. Payroll Service).
My customer success manager mentioned "module_sales_integration" - what is that? The internal toggle for this feature. You don't see it - your CSM toggles it on for you. If your integration suddenly stops working, this toggle being switched off is one of the first things to check.
Is there an extra cost? The Sales Integration module itself is part of standard vimigo plans on most subscriptions - check with your CSM. Your POS vendor may charge a one-time setup fee for adding vimigo support to their software.