Open Mercato CRM: Capabilities and Operating Model

Public releases versus current source

1. v0.4.5Public release

   Multiple CRM pipelines with configurable stages, drag and drop, and pipeline switching.

2. v0.4.10Public release

   Customers v2 redesigned the people and company model and CRUD surfaces.

3. v0.6.3Public release

   Sales pipeline kanban with lanes, filters, stuck and overdue indicators, quick creation, and stage management.

4. v0.6.5Latest verified public tag

   Redesigned deals list.

5. 01911d00eCurrent source, not a reviewed public tag

   Later CRM entities, email, reporting, map, interaction, permission, and integration evidence is labeled current source.

The local 0.6.6 changelog section has no matching tag in the reviewed checkout. It is not treated as a release here.

Product capability versus operating decision

State describes evidence for a mechanism. The not-established flag marks missing evidence for a packaged capability in the reviewed scope; it does not mean a custom application can never add it.

CRM operating model in seven decisions

1. 1

   Outcome and persona

   Name the business decision, user, baseline, success evidence, and accountable owner.

2. 2

   Record and relationship model

   Define person, company, relationship, deal, source, identity, duplicate, and retention rules.

3. 3

   Lifecycle and pipeline

   Define each stage purpose, entry, exit, owner, probability, close-date, aging, exception, win/loss, and change policy.

4. 4

   Interaction and work policy

   Choose activity, interaction, note, task, email, handoff, privacy, and completion rules.

5. 5

   Data, access, and system boundaries

   Assign systems of record, organization scope, roles, integration, reconciliation, migration, and exit.

6. 6

   Measures and acceptance

   Define formulas, data prerequisites, missing-data behavior, tests, tolerances, and business acceptance.

7. 7

   Stewardship and operations

   Name data, process, service, incident, configuration, upgrade, support, and decommission owners.

A pipeline is not a sales method

For every stage, record purpose, entry and exit evidence, owner, probability and close-date policy, aging or stuck rule, exceptions, win and loss meaning, and the owner of definition changes.

Custom fields and dictionaries need governance

For each item define name, meaning, type, required, default and null rules, validation, access, sensitivity, source, owner, lifecycle, migration, reporting use, and deprecation.

Personal email, privacy, and asynchronous timing

Current source describes an optional personal Gmail or IMAP and SMTP mailbox workflow. Sending starts from a Person record, inbound messages link by primary address and thread, and processing happens in the background. Privacy is owner-only by default. Sharing applies to one email, visibility changes are audited, and the administrator permission for another user’s private content remains inert.

This does not establish a shared inbox, campaigns, bulk marketing, consent management, or guaranteed delivery time. The project must test provider behavior, addresses, delay, outage, privacy, and handoff.

KPIs, stage totals, and the map are bounded current-source surfaces

Deal summaries cover pipeline value, active deals, won-this-quarter value, win rate, stage breakdown, top owners, and a six-month series. Stage aggregates disclose currencies and missing rates. The map is paginated and depends on usable locations. Results depend on organization scope, status meaning, complete values, base currency, rates, locations, and update discipline.

These APIs do not establish universal BI, forecasting, quota, commission, or territory management.

Two hypothetical examples

CRM acceptance plan

• Normal create, read, update, and delete for each record type
• Duplicate prevention and deterministic identity decisions
• Required, format, dictionary, custom-field, and business validation
• Person, company, role, deal, and task relationship integrity
• Allowed, denied, reopened, won, lost, and exceptional stage transitions
• Wrong-organization and wrong-tenant isolation
• Denied permission on view, edit, export, bulk, email, and configuration
• Bulk-action mixed success, itemized failure, retry, and reconciliation
• Undo, redo, history, identity, relationship, and custom-field preservation
• Email private owner-only content, per-email sharing, audit, and no admin bypass
• Integration outage, timeout, duplicate, ordering, replay, and manual recovery
• Stale source data and conflicting updates
• Missing exchange rate and partial currency conversion disclosure
• Missing or invalid location in the deal map
• Authorized export field and row reconciliation
• Backup, recovery, and supported restoration of CRM state
• KPI, stage, report, and source-record reconciliation

Stop estimation or launch

• A turnkey software-as-a-service sales method is required with no implementation team.
• Customer master data has no accountable owner.
• Person, company, account, and relationship identity are undefined.
• No system of record or reconciliation rule exists.
• A required capability is unsupported and has no accepted custom or integration path.
• No integration and outage owner can reconcile external data.
• Security, privacy, access, email, or export decisions have no owner.
• No business acceptance owner or measurable evidence exists.
• No ongoing process, data, configuration, support, or upgrade steward exists.

What this guide does not prove

It does not prove production readiness, sales outcomes, adoption, compliance, security, provider quality, migration completeness, integration availability, implementation time, total cost, or future roadmap. Repository tests prove named cases, not acceptance of a specific deployment. The module README contains older status wording, so current entities, routes, tests, user guides, and tags have higher evidence priority.