The Engineer’s Guide to CRMs

A CRM’s primary function is to enable an enterprise sales team’s resources and processes to more efficiently make revenue, aka more money.

Who uses a CRM?

Engineers often sit far from sales, but to build on top of a CRM, they need context on who they are building for.

• // Prospecting: finding new buyers.
• // Qualifying: determining whether a potential buyer has a problem the team can solve, along with the money and authority to buy.
• // Pitching: demonstrating the product or showcasing the value the team can provide.
• // Closing: agreeing on terms, pricing, and contracts to secure revenue.

Other roles use the CRM too: management reviews the pipeline and forecasts revenue; marketing examines where deals come from; and customer success tracks renewals and schedules check-ins. (Paraphrased from Joel’s interview.)

Why do sales teams need a CRM?

For an individual salesperson, the CRM helps answer questions about a particular account: Who are we talking to? What happened last? What needs to happen next?

These responsibilities are often represented as a pipeline or funnel in which prospective buyers gradually become customers. Sales teams need to track:

Buyers and companies: who the buyers are, their responsibilities, and where they work. Pipeline stage: where each prospective deal stands. Interactions: activity involving sales, marketing, and the buyer. Relationships: the connections across those people, companies, deals, and interactions.

Many small teams start tracking this information in a spreadsheet. That can work for a few people. As a team grows from 10 people to 100, coordinating data, access, and workflows becomes harder.

Familiar engineering problems

Sales collaboration introduces familiar engineering problems:

A CRM provides a maintained, customizable platform for evolving sales processes. Companies can build on that platform instead of maintaining a custom spreadsheet-based sales system.

Engineers building on a CRM must understand its reliability, scalability, access, and workflow guarantees. These depend on the product and configuration. Integrations must respect them as business processes evolve.

Engineers building on CRMs need to understand the core entities, their relationships, and how a sales team adapts them to its process.

A sales team commonly tracks:

• // Buyers: their roles and responsibilities.
• // Companies: the organizations where buyers work.
• // Pipeline position: where a potential sale stands.
• // Interactions: conversations, tasks, and events.
• // Relationships: how those records connect.

CRMs map these concepts into standard objects. The names vary by provider:

Standard objects help a company get started, but a CRM reflects decisions made for the business at a particular time. CRM architects help teams translate their sales operations into objects, fields, relationships, permissions, and workflows that can evolve.

Custom objects

When the company’s language does not fit the standard model, it may define its own objects:

• // Real estate: properties, listings, addresses, and prices.
• // Recruiting: job postings, hiring managers, departments, and applications.
• // Retail: inventory, SKUs, warehouses, and suppliers.

Discover before reading

An application may encounter an object or field only at runtime. It needs schema introspection to discover names, types, relationships, and required fields, then map that customer-specific model into concepts the application or agent understands.

Engineers may expect a fixed set of endpoints. A CRM integration must accommodate a flexible, customer-owned data model.

A founder-led sales process might need only a list of contacts, a few notes, and a simple set of deal stages.

After the company hires its first sales team, it may add owners, tasks, and a shared pipeline.

As the organization grows, it may introduce territories, qualification criteria, revenue attribution, approvals, specialized roles, and different processes for different products or customer segments.

Post-sales teams create more requirements. The company may need to track onboarding, product adoption, account health, renewals, and expansion opportunities.

Enterprise customers may introduce security reviews, procurement stages, legal approvals, parent-child account structures, and many stakeholders inside the same buying process.

The CRM grows alongside the business.

• // New people bring new requirements.
• // New products change what the company needs to understand.
• // New customer segments change the way opportunities are evaluated and relationships are managed.

The CRM reflects the current but evolving state of the business.

Traditional application databases are often designed around a model that developers hope will remain relatively stable. Schema migrations are expensive, and changing existing data structures can break downstream behavior.

A CRM faces a different organizational pressure: the process it represents may continuously change as the business itself evolves its products, services, and sales process.

The schema reflects how the organization has evolved. Old fields, abandoned workflows, inconsistent conventions, and one-off automations are often the residue of earlier versions of the business.

A single CRM record on its own is often not enough to know its business context. A contact identifies a person, but only after following a person’s relationships with their company and the actions they take can an agent meaningfully understand who the contact is in the business context.

For agents, reading from a CRM involves:

1. 01 Finding the records.
2. 02 Tracking their relationships.
3. 03 Interpreting the records and fields based on business rules.

Reading from CRMs is closer to creating a view than finding a specific resource or document. An agent helping to prepare for a sales call needs access to contacts, companies, opportunities, emails, meetings, and other resources to reconstruct the business context needed to meaningfully understand how to prepare for the call.

The CRM may be designed to enable engineers to fetch resources through a predictable API, but the engineer must also understand the core business questions, which likely require a sequence of calls to understand the resource graph and business context.

Anusha describes subscriptions as useful when a product needs to detect a change within seconds or minutes and then act on it.

CRMs store the business context across multiple objects that then can be reconstructed for different views. When getting a change event, the service must also navigate the CRM graph through its relationships to hydrate the rest of the information.

Applications and agents read CRM records to reconstruct business context. Writing to a CRM record means taking action in a business process.

Writing depends on the business responsibility

• // A sales development rep may record a contact and their calls in the CRM.
• // A new call may update the status of the deal in the pipeline.
• // A new contact may be added to a company account and marked as the owner.

Understand the affected workflow

The company’s sales process determines its stages, permissions, assignment rules, and required fields.

CRM records show previous interactions and the current stage of a deal. Workflows use that information to assign tasks and coordinate next steps.

What data can be safely written and what is too high-risk to be written programmatically are distilled into write rules and processes.

Writing to the CRM at scale also brings different challenges. Writing each record separately can consume quota quickly.

Anusha describes collecting event-triggered write actions over a period and submitting them together.

For custom control over events, some CRMs support adding logic directly inside a customer’s instance.

Adding software to a customer’s instance has its own challenges. The code has to be installed, tested, updated, and possibly removed in an environment the integration team does not control.

The Salesforce version of this code is an Apex trigger which can run automatically in response to record changes or change events.

Jay shares how Ampersand added filter events to reduce quota usage, but the difficulty appeared during removal.

Engineers often build on a test instance, but the real challenge is when the production instance may have custom specialized workflows that may not be maintained and also block external development.

When reading large amounts of data, a CRM cannot supply the data all in one read. Reading the data may require a backfill, which reads the data in batches. Jay shares the challenges of reading data at scale.

Many APIs may not be documented. Jay shares how error codes may mask errors.

Most CRMs are designed for people interacting on the web, not necessarily via their APIs. These APIs may have many undocumented edge cases that you wouldn’t necessarily know unless discovered through multiple instances and patterns begin to form.

Jay shares how changes in users may break a working connection in an integration.

Human change in organizations can get complicated for everyone involved. The underlying CRM also reflects the same complications.

Engineering summary

Engineers often want to set and forget. Building with CRMs may not be the case since the underlying users and permissions may continuously be changing.

Changes in people are also not always predictable. Maintaining an unforeseen change may require intervention from customer support or investigation with the end consumer to find out what has changed in the customer’s business, which then gets reflected in their CRM setup.

CRMs used by large teams may see large changes; they may not know what is happening in the company, much less their CRM. Maintaining this integration then may require patient customer support to help find the right people to solve the problem.

An AI sales development representative (SDR) assists with or automates parts of a sales workflow. A sales representative may offload data-intensive or communication tasks to it.

Work the agent can support

• Prospecting

  Scan databases for accounts that match the company’s ideal customer profile.

  READ

• Data enrichment

  Find missing email addresses, phone numbers, job roles, and company information.

  READWRITE

• Lead qualification

  Cross-reference information from websites to prioritize prospects.

  READ

• Communication

  Draft personalized emails and coordinate follow-ups and scheduling.

  READWRITESUBSCRIBE

Each responsibility crosses several layers. These operations describe CRM interactions; other services have their own interfaces.

1. 01

   Context · READ

   Retrieve needed records and fields. Combine them with other systems or public information, retaining the source of each fact.

2. 02

   Orchestration · SUBSCRIBE + READ

   Receive changes and select a workflow. Read current records if an event lacks context. Requests and schedules can also trigger work.

3. 03

   Reasoning · Use context

   Assess a prospect or draft a message. Reasoning alone needs no CRM write. Request additional reads through tools; pass proposed changes to the action layer.

4. 04

   Action · WRITE + READ

   Check permissions and required approvals, then update the intended record. Verify the response or read back the result. Email and calendar actions use their own services.

Example: SUBSCRIBE to new leads → READ context → propose enrichment → WRITE approved fields and verify.

Building a single integration with a CRM can be done using an API that gives read and write access.

However, building a product or an agent for other businesses is a different story.

Every customer is a separate business with its own CRM configuration and customizations, and is constantly changing.

Each customer brings its own configuration

If you have 100 customers, each with their own CRM, your product must manage 100 customized CRMs. Each has its own connection and authentication, permissions, object and field schema, field mappings, new records, and errors.

Each customer’s CRM may also be evolving, which can trigger reauthentication, schema drift, or an integration that stops working.

Observability becomes a requirement

Since every customer’s data integration can break for independent reasons, an observability layer that detects changes in the connection and in reads and writes becomes essential to fixing an installation and allowing the application or agent layer to continue working.

Some errors need human intervention

Some errors are shared across providers and can be built into the infrastructure, while some are highly specific to the provider or even the customer’s instance, needing customer support to navigate the complex CRM configuration changes.

An infrastructure layer for the product

The product needs a management layer to maintain those integrations and support their reliability. It needs observability to know which integrations have been successfully set up, are still working and moving data, and which are broken.

Eventually all products that need access to CRMs will need an infrastructure layer to manage their provider integrations; it is just a matter of scale.

Different countries and regions have different laws on how data is handled. The need for different product surfaces and separate data orchestration adds a level of management complexity in addition to just managing installations.

Handling data across regions also has downstream impact on product flows and onboarding. Maintaining infrastructure requirements also comes with maintenance and support from product engineering.

Building for each provider may be different. Patterns are useful, but assumptions have to be tested.

Providers may also update their requirements or even make undocumented changes that express different errors. Maintaining domain expertise per provider becomes part of the infrastructure problem when building for multiple integrations at scale.

CRM

Software used to organize customer relationships and the work around them.

Company / Account

A record representing an organization.

Contact

A record representing a person.

Opportunity / Deal

A potential sale, often tracked through stages.

Activity

A recorded interaction or task; its representation varies by provider.

Schema

The available record types, fields, and relationships.

Field mapping

A correspondence between a CRM field and a concept used by another system.

Custom object

A customer-defined record type added beyond the CRM’s standard objects.

Custom field

A customer-defined field added to a standard or custom object.

Backfill

Retrieving historical data to establish context or fill a gap.

Incremental read

Retrieving changes since a previous point.

Change notification

A signal that something changed, with contents determined by its source.

Subscription

A mechanism for receiving notifications when CRM records change.

Hydration

Retrieving additional record data after receiving a notification.

Checkpoint

Recorded progress used to continue or recover work.

Authentication

Establishing the identity used for a connection.

Authorization

Determining what that identity is permitted to access or change.

Scope / CRM permission

An OAuth scope limits what a connection may request; a CRM permission limits what the connected user may access. Either can constrain the integration.

Installation

One customer’s configured connection, including its identity, permissions, schema mappings, and sync state.

A CRM begins as a place to store customer information.

As the company grows, it becomes the shared memory of the organization, a coordination layer for its revenue teams, and a model through which leaders understand the business.

Four connected roles

Record. Preserve the organizations, people, opportunities, and activities that make up customer relationships.

Remember. Reconstruct what has happened, what the customer needs, and what the company has promised.

Coordinate. Direct people, processes, and tools toward the next useful action.

Learn. Turn patterns across many relationships into a better understanding of how the business creates customer value.

CRMs help the company scale the business by helping to find prospective customers, build relationships, turn potential deals into revenue, deliver value, retain customers, and expand accounts over time.

The CRM reflects the current state of the business but never contains the complete truth. It is highly customizable, continually changing, and shaped by the people and processes that maintain it. The CRM gives an organization a shared model to act on.

Engineers building agents and products that need their customers’ CRM data must design for this living system and also treat their data integrations as infrastructure. Their infrastructure must manage all their customers’ integrations, continuously build for edge cases, and plan for how their product will scale across customers and regions. Finally, supporting reliable CRM integrations means they must have a dedicated customer service team for human edge cases that not even their customers fully understand.

Engineers need to ask how they will maintain the underlying infrastructure and whether this is a problem they want to own.