The sale and the enrollment are the same record.
Most retailers keep the customer in one system and enroll them in another. Conduit keeps one record, and the market status on it is read back from the transaction chain rather than typed by a person.
Off your desk
You stop keeping a spreadsheet of who was sold what, and re-keying it into a second system to enroll them.
Without this
What this looks like today.
A sale closes in a CRM, or a spreadsheet, or an agent's inbox. Somebody then re-keys the name, the address and the plan into whatever talks to the market. From that moment there are two records of the same customer, and they begin to drift — the CRM says the account is live, the market says the 814 was rejected on a bad address nine days ago.
The address is where most of it goes wrong. A unit number in the wrong field, a street type abbreviated the way the agent says it out loud, and the enrollment comes back unexecutable. By the time anyone notices, the requested start date has passed and the customer is still with the incumbent, wondering why they were promised a switch.
None of this is hard work. It is just work that nobody should be doing, and that gets quietly skipped on the busiest week of the month.
How it works
Customers & enrollment, in detail.
Every prospect, customer, service address and ESI ID in one book of business — from first quote to an active account.
One record, from prospect to active
A prospect and a customer are the same aggregate at different points in its life, so converting one does not copy it into a new object with a new id. Every service address, ESI ID and contract sits under it, and the history stays attached through the conversion — the note the agent left before the sale is still there after it.
Fields you define, without a schema change
Retailers track things nobody else does: the channel, the broker, the promotion code, the reason a deposit was waived. Custom fields are defined per organisation and stored as structured JSON on the record, so adding one is a configuration change rather than a release. They are searchable and they come back through the API like any other field.
Addresses normalised before they can fail
An address is validated and normalised to a real deliverable USPS address at the point somebody types it, with typeahead against Texas addresses — not at the point the market rejects it. The enrollment carries the normalised form, which is the form the TDSP is matching against.
The funnel wired straight to the market
Quote, enroll, 814, activate is one path rather than a handoff between two teams. Requesting an enrollment emits the 814_01; the acceptance, the historical usage and the initial read land back on the same record as they arrive. Nobody types a status, because the status is the chain.
Migrating a book you already have
Bulk import takes a file, maps its columns to fields, validates every row, and shows you a dry run of exactly what would be written before anything is. Failures come back as a list you can fix and re-run, rather than a partially-imported book you now have to reconcile.
At a glance
- Prospects and customers with fields you define yourself, no schema change required
- Address entry that normalises to a real USPS deliverable address before it becomes an enrollment
- Bulk import with column mapping, validation and a dry run before anything is written
- The enrollment funnel wired straight to the market: quote, enroll, 814, activate
Connected
What this leans on.
Nothing here is a separate product with an integration between it and the rest. These are the capabilities this one shares a record and a ledger with.
Questions
The ones we actually get.
Is this a CRM? Would it replace Salesforce?
It replaces the spreadsheet or the light CRM most retailers use to track who was sold what before they are enrolled. It is not a general sales-automation suite, and it does not try to be — what it has that a general CRM cannot is the service address, the ESI ID and the live market chain on the same record.
Can we track fields that are specific to us?
Yes. Custom fields are defined per organisation and require no schema change or release to add. They behave like first-class fields: searchable, importable, and returned through the API.
What happens when an enrollment is rejected?
The rejection lands on the account with its reason code, and the account's status reflects it immediately rather than at the next time someone checks the market. Rejections that are really inadvertent gains can be opened as a MarkeTrak case from the record itself.
Can we import a book of customers we already have?
Yes — customers, service accounts and open cases import in bulk with column mapping, per-row validation and a dry run that shows what would be written before anything is committed.
The rest of the platform
One customer record, one ledger, one audit trail.
See it against your own book.
Bring a month of real transactions and a TDSP invoice. Customers & enrollment is easier to judge against data you already argue about than against a demo tenant.