Skip to main content

SPM Data and Modeling

In the world of incentives, the correct configuration of a data model is crucial.
The formulas that transform KPIs into earnings and payouts are nothing more than functions operating on data structures: if the structure is incomplete, inconsistent or unstable, calculations become inaccurate, non-reproducible, or unmanageable.
Investing time in initial modeling reduces disputes, facilitates audits, and makes system maintenance scalable.

Key message: the success of an SPM plan starts with the data, not the formulas. Good modeling = fewer errors, fewer disputes, simpler governance.

Operational Overview: What Enters Apparound SPM and How It’s Organized​

Example of Data Sources and Flow into Apparound SPM​

  • CRM: opportunities, sales assignments, deal status → pipeline KPIs, conversions, lead attribution.
  • Quote-to-Order / Order Management: signed orders, contracts, offer configurations → activations and contractual revenue.
  • Billing / Invoice: issued invoices, taxable amount, taxes, invoice status → MRR, uplift, reconciliations.
  • Finance / Payments: payment status, defaults, reversals → cash vs accrual scenarios.
  • HR / Payroll: seller’s contractual validity, role, hierarchies → eligibility rules.
  • Provisioning / Order systems: activation status, service metrics → rewards linked to SLAs and activations.

How Apparound SPM Structures and Manages Data​

Apparound SPM organizes data on three pillars, three main categories, each designed for a specific purpose:

Organization​

  • This category hosts two entities: the Participants entity and the Partners entity.
  • No additional entity can be created in this category.
  • They are both system entities, which means they cannot be deleted and their default properties cannot be removed; however, they can be extended by adding custom properties.
  • They contain data related to the beneficiaries of compensation (sellers, agents, partners)
  • Important: please consider that participant_id and partner_id are the the point of contact between the participant/partner and all the economic and financial records linked to it (transaction, performance, payments, etc...); in order to ensure data consistency and accessibility, it is essential to preserve the integrity of this data.

Components​

  • This category hosts fully configurable and highly flexible objects used to support calculations (e.g., assigned quota, bonus pool, special rules) and model logics not directly tied to transactions.

Transactions​

  • This is the most numerous category: it hosts events representing orders, contracts, invoices, payments, activations, leads, etc.
  • It reflects the data model of the source system (with adaptations): every record in the entities of this category should include source_system, source_id, and raw_payload for auditability, as well as references to participants and components when applicable.

Integrating Data into Apparound SPM — Practical Example​

When working with CRM, ERP, Billing, HR, and Finance systems, Apparound SPM collects information about participants, transactions, and components that fuel incentive plan calculations. Proper integrations mean having consistent, traceable, and clearly modeled data — without needing to detail every single technical step.

A practical approach is to start from the most relevant data sources for plan KPIs, define IDs for participants, and determine which transactions and components are truly needed for calculation. From there, build a flexible mapping that can be implemented via Data integration, API, or bulk upload depending on the context — always keeping track of the raw payload and key relationships.

It’s best to model data early, thinking about how SPM formulas will use them: stable participants, consistent transactions, and well-defined components simplify recalculations, reconciliation, and audit processes. The goal isn’t to prescribe every step, but to outline a method: select sources, define key references, model coherently, and perform a minimal quality check before relying on formulas.

By following this approach, even complex scenarios — such as plans combining activations, recurring revenues, churn, and annual bonuses — become manageable, without introducing unnecessary complexity in the integration phase.

Practical note: every system has its own constraints. Always align on frequencies, formats, and canonical identifiers.

Use Case: Utilities​

Business request: plan rewarding new activations + recurring MRR − churn.

Involved data sources:

  • Quote-to-Order (QTO)
  • Billing
  • Finance
  • HR
  • CRM

Operational workflow:

  1. Import activations

    • Map to transactions.activation_event
    • Key fields: order_id, activation_date, seller_id, recurring_value, one_shot_value

  2. Import invoices

    • Map to transactions.invoice
    • Key fields: invoice_id, invoice_date, amount, status

  3. KPI calculation Implemented within formulas (performance/earning/payout):

    • For each seller:

      • aggregate MRR
      • sum activations
      • flag churn when contract terminated within X days

  4. Create Components

    • quota_assigned → team-assigned quota
    • bonus_pool → annual contest / bonus pool

  5. Test and validation

    • Run over a 3-month dataset
    • Reconcile MRR and activations with source systems

Quick Integration Guide for Apparound SPM​

  1. Preparation

    • Catalog data sources and their owners
    • Define canonical participant IDs
    • Establish frequency and integration method

  2. Data Mapping

    • Map source fields to Participants, Components, and Transactions
    • Normalize dates, currencies, and identifiers

  3. Import and Modeling

    • Load participants
    • Create required components
    • Import transactions with proper references

  4. Transformations and Calculation

    • Create derived fields for KPIs
    • Handle deduplication and idempotency
    • Validate data integrity

  5. Testing and Validation

    • Verify ICM formulas
    • Check incentive calculation output
    • Compare results with reference datasets for consistency

Data Modeling with Entities, Views, and Forms​

To ensure imported data is consistent and ready for compensation calculation, it’s essential to use SPM’s entities, views, and forms:

  • Entities: represent the system’s core objects and define their structure.
  • Views: allow you to create custom visualisation of data, filtering and aggregating information for specific needs.
  • Forms: provide editing interfaces, making data management clear and structured.

These tools enable proper data modeling before applying SPM formulas, preventing downstream issues and simplifying the creation of complex compensation plans.