A CRM, ERP, and buyer-operations platform solve different parts of a preconstruction operating model. A CRM usually owns relationship and sales context, an ERP or approved finance system owns financial records, and a buyer-operations layer coordinates cross-system workflows, policies, tasks, communications, and exceptions without becoming the source of truth for every record.
Compare responsibilities, not product labels
Software category names are useful shortcuts, but they do not define what a specific implementation can or should own. Two products described as CRMs may expose different records, workflows, permissions, and integration options. The same is true for ERPs, document systems, portals, and workflow platforms.
Start with operating responsibilities:
- Which system is authoritative for each record?
- Which team can approve a change?
- Which cross-system work needs coordination?
- Which actions may be automated under approved policy?
- Which conditions require human review?
- Which evidence must remain traceable?
Capabilities vary by product, edition, configuration, and release. Verify them in the current vendor documentation and in the developer's configured environment before making an architecture decision. This article compares operating roles, not named vendors or products.
What the CRM should own
A CRM commonly owns relationship and sales context. Depending on the developer's setup, that can include:
- prospect and buyer records;
- relationship history;
- sales ownership;
- approved contact preferences;
- opportunity or reservation context;
- sales-stage activity; and
- communication history created within the CRM.
The CRM may also offer automation, document, payment, or portal capabilities. Those features should be evaluated against the developer's actual responsibility map rather than assumed from the product label.
After reservation, the CRM can remain authoritative for buyer and relationship context while other systems own contracts, financial records, documents, or inventory. A buyer-operations workflow can read the permitted CRM context and coordinate actions without copying every CRM record into a competing database.
What the ERP or finance system should own
The ERP or approved finance system should remain authoritative for the financial records assigned to it. Depending on the operating model, those may include:
- approved payment schedules;
- receivable or ledger records;
- posted transactions;
- matching and allocation states;
- reversals, disputes, corrections, or refunds;
- cleared status; and
- finance-approved references and outcomes.
The distinction between schedule and transaction is important. A schedule describes an approved expectation; a transaction record describes what finance has recorded. A buyer message, document upload, expected date, or external notification should not overwrite the authoritative finance state.
The payment operations workflow coordinates approved schedule context, finance status, communication, and exceptions while keeping financial authority with the designated system and team.
What a buyer-operations layer coordinates
A buyer-operations layer connects the operating work that crosses authoritative systems. It can coordinate:
- the buyer, unit, project, and lifecycle context required for a task;
- approved document requirements and review states;
- policy-controlled buyer communication;
- payment follow-up based on approved sources;
- tasks and handoffs across sales, operations, finance, and closing;
- exception detection, assignment, and resolution evidence;
- readiness evidence before an authorized review; and
- an activity record showing which source and policy supported an action.
The layer should not absorb the authority of the systems it connects. It can create an operational state such as "ready for finance review," but it should not claim a transaction cleared unless the approved finance source supports that state. It can record that a document was received, but it should not claim the document was sufficient unless an authorized reviewer recorded that decision.
This coordination model is reflected in Asterisko's document readiness, buyer servicing, and closing readiness workflows.
Map each operating subject to one authoritative source
The likely source below is a starting point, not a universal assignment. A developer should replace it with the systems, policies, and owners used in its own environment.
| Operating subject | Likely authoritative system | Cross-system workflow use |
|---|---|---|
| Buyer identity | Approved CRM or buyer identity system | Connect the correct buyer to unit, tasks, and permitted communications |
| Relationship | CRM | Provide sales ownership, lifecycle context, and approved preferences |
| Unit | Approved inventory or project system | Anchor documents, payments, communication, and readiness to the correct unit |
| Contract | Approved contract repository or contract system | Expose the authorized contract state without letting workflow infer legal effect |
| Schedule | Approved contract, ERP, or finance system | Coordinate milestones and policy timing without changing approved terms |
| Transaction | ERP or approved finance system | Drive permitted actions from recorded status and route conflicts to finance |
| Documents | Approved document repository or contract system | Track receipt, review, approval, provenance, and exceptions as separate facts |
| Communication | Approved CRM, portal, or communication record | Apply approved templates, permissions, timing, and escalation policy |
| Task | Workflow or approved task system | Assign routine work and exceptions with owners, states, and evidence |
| Readiness | Approved readiness record | Assemble evidence and request an authorized decision without self-approving |
One system can own several subjects, and an implementation may expose overlapping features. The control is that each subject has one designated authority at a given point in the operating model.
Decide whether to improve, integrate, or add a workflow layer
Use these ordered questions as a decision tree:
-
Is the underlying record correct, governed, and accessible in its current system?
If no, improve the source system, data ownership, permissions, or operating policy first. Integration cannot make an unreliable source authoritative. -
Can the current system support the required workflow without duplicating authority?
If yes, configure and govern that capability before adding another layer. -
Does the work depend on context from another authoritative system?
If yes, evaluate an integration that exposes the minimum permitted context and preserves provenance. -
Does the operating path cross several systems, teams, and policies?
If yes, a workflow layer may help coordinate actions, handoffs, and exceptions without replacing the sources. -
Are exception owners and human decision boundaries defined?
If no, define them before automating. A new platform will not resolve ambiguous authority. -
Can the proposed design show why each action occurred?
If no, add source, policy, actor, timestamp, and exception evidence before deployment.
The result may be a combination: improve one source, integrate a limited set of approved records, and add workflow coordination only around the cross-system journey.
Human review, permissions, and exception ownership
System boundaries do not remove the need for decision boundaries. Define which actions a person or workflow may take, on which records, under which policy, and with which evidence.
Human review is appropriate when:
- buyer, unit, contract, schedule, transaction, or document records conflict;
- a requested action changes an approved term, obligation, or authoritative record;
- a document requires sufficiency, validity, or legal review;
- a transaction is unmatched, partially matched, reversed, disputed, or unclear;
- a communication falls outside approved content or permissions;
- a buyer requests legal, accounting, lending, title, or jurisdiction-specific interpretation; or
- a readiness, release, approval, or closing decision requires authority.
Every exception should have a named owner, visible state, source evidence, allowed resolution path, and authorized outcome. Permissions should follow least-access principles and the developer's security, privacy, and retention policies.
Questions to ask during product evaluation
Ask each prospective system or configuration the same responsibility-based questions:
- Which operating subjects can it own as an authoritative source?
- Which subjects can it read without copying or redefining them?
- How does it preserve source provenance and record freshness?
- Which actions can be limited by role, project, state, and policy?
- How are workflow states and policy versions recorded?
- How are duplicates, retries, and delayed source updates handled?
- Can routine work stop when records conflict or context is missing?
- How are human review, exception ownership, and resolution evidence represented?
- Can sensitive fields remain in the authoritative system?
- What current documentation supports the required APIs, events, permissions, and limits?
- How can records and evidence be exported if the operating model changes?
Evaluate these answers against a mapped buyer journey and representative exceptions. A feature list alone does not show how the configured systems will divide responsibility.
Where Asterisko fits
Asterisko is designed as a buyer-operations layer for preconstruction developers. It coordinates workflows on top of existing systems, including approved CRM, ERP or finance, document, communication, and project records.
It is not positioned as a universal replacement for every CRM, ERP, buyer portal, document repository, or professional review process. The operating model keeps those systems authoritative for the subjects assigned to them while Asterisko coordinates context, policy, tasks, communications, handoffs, and exceptions.
Start by mapping one buyer journey and assigning each operating subject to an authoritative source. Then identify the cross-system steps that remain disconnected. Explore buyer servicing as one coordination pattern, and verify all required capabilities against current vendor documentation and the developer's actual configuration before choosing whether to improve, integrate, or add a workflow layer.
