ENHData Enhancement

Improve what’s already there.

Your CRM stores the data. Enhancement applies your business logic to it: the calculations, the categories and the rules your operation depends on and the standard object model does not represent.

Configured operations that run when you set them up and run them. Not a service that watches your CRM.

A pass is scoped, agreed and executed against a defined set of records. You decide when a pass runs and on what scope. Every pass is logged, with a snapshot taken before changes are made.

Enrichment vs Enhancement

Enrichment adds data. Enhancement improves it.

ENR · DATA ENRICHMENT

Data Enrichment brings new information into the CRM from external providers.

Data Enrichment →

ENH · DATA ENHANCEMENT

Data Enhancement works with information you already have: standardising it, reconciling it, deduplicating it, or deriving the values your revenue operation needs.

No external provider is involved in any operation on this page.

Business logic

Your business has logic your CRM wasn’t built around.

Every business has rules the standard object model does not represent: how a contract is valued, which year it belongs to, what a category is allowed to contain. Today that logic tends to end up scattered across a workflow here, a marketplace app there, an automation nobody documented, a spreadsheet somebody maintains by hand, a one-off script, or a subscription bought largely for one feature inside it.

Enhancement is one controlled place to put a specific piece of it. Defined before it runs, logged when it does, with a snapshot taken before anything changes.

Calculations your CRM does not perform
Values derived from data the CRM already holds but does not combine: contract value reconstructed from line items, allocation across a contract period, revenue placed in the year your business actually uses.
Fiscal logic that is not the calendar
If your financial year does not start in January, the CRM’s year is not your year. A pass can produce both views of the same deal rather than forcing one to stand in for the other.
Values standardised to a vocabulary you define
USA, U.S., United States, United States of America and US mean one thing to a person and five things to a territory rule, a report filter and a workflow branch. Mixbound standardises to the vocabulary your operation uses, agreed before the pass runs. A value the mapping does not cover is reported, not guessed at, and the pass is idempotent: running it twice over the same records changes nothing the second time.
Duplicates merged from an approved set
The audit finds candidate pairs; the merge happens only against the set you approve.
Derived properties, written back as fields
Once a value is calculated it lives in the CRM as a property like any other, so your reports, workflows and views can use it without knowing where it came from.

Custom scoring and business-specific validation follow the same shape: a rule you define, applied to records you scope, written back as a field. What a given pass does is configured per client rather than shipped as a fixed feature list.

Worked example

A worked example: contract value.

Mixbound has built this and used it successfully with a customer. It is the clearest illustration of what Enhancement is for.

The input

The deal, the line items actually attached to it, the contract dates and terms, and the fiscal-year rule the business uses.

The logic

Contract value reconstructed from those line items and allocated across the period the contract covers, then placed into years, both the calendar year and the fiscal year where those differ.

The output

Derived properties on the deal: a corrected contract value, and the per-year figures behind it, written back as fields your reports and workflows can use.

Why it matters

The CRM holds the commercial data but stores one amount on the deal. If your business values a contract differently from that single figure, every forecast built on it inherits the gap.

Arithmetic over dates and amounts. Nothing inferred.

Once you have defined how ACV is calculated, nothing should reinterpret it.

Mixbound encodes the rule you defined. Same inputs, same calculation, every time, and every write recorded with the value it replaced. Where that removes the need for another point solution, a one-off integration or a custom code path somebody has to maintain, that is a reason to use it. It is not a claim about what any other product costs.

Put your business logic somewhere it can be trusted.

Scope a pass against the records you choose. Every pass is logged, with a snapshot taken before changes are made.