The Engineer’s Guide to CRMs

This book is for founders and engineers building products that read from and write to their customers’ CRMs such as Salesforce and Hubspot.

Printed copies of The Engineer’s Guide to CRMs fanned out on a blue chair

Request a printed copy

Contact and shipping details

Contact details

Where should we send the book?

We’ll use these details to handle this book request. Privacy policy.

Preview the book

Selected pages from The Engineer’s Guide to CRMs

The CRM model

The CRM model: connected Contact, Company, Opportunity, and Activity records support business workflows and software that reads, subscribes, and writes across customers.

Click a diagram to explore it at full size.

7–8

Why not a spreadsheet?

A spreadsheet can store customer information when a team starts out. As the business grows, other teams may need to work from the same sheet:

  • Marketing adds campaign information.
  • Customer success adds renewal dates.
  • Leadership adds forecasts.

Each team may add its own columns. The spreadsheet becomes harder to use as the information, definitions, and handoffs multiply.

Marketing, customer success, and leadership add their own columns to a shared customer spreadsheet.
Figure 1.3. Different teams add information to the spreadsheet, increasing the complexity of what it contains.
15

Coordinating shared work

As more people contribute to customer information, teams need shared rules for ownership, status, and next steps. A CRM can require information before a deal advances, restrict who can change it, and assign work when a sale closes. It helps teams apply those rules consistently and track changes, but it cannot resolve disagreements for them.

Two Acme records have conflicting owners and statuses; a Corvid record has no owner assigned.
Figure 1.4. The duplicate Acme entries disagree about ownership and status. Corvid has no owner, so nobody is clearly responsible for the next step.

A CRM provides mechanisms for coordinating this work: shared records, permissions, change history, and workflows. These mechanisms help teams apply their process consistently, but the business still decides the rules.

16
Open original

Request a printed copy

From the foreword

By Ayan Barua

There's a generation gap in software. Building an agent that works with an enterprise's systems is a little like asking Gen Z to work with their grandparents. They move at different speeds, communicate differently, and have different ideas about how things should get done.

I ran into this problem long before agents, at Siftery and later at G2, which acquired us. We were building products that depended on other companies' software. Our engineers had to learn inconsistent APIs, understand each customer's configuration, and keep data moving as those systems changed.

I came to understand that this is a domain expertise problem.

That experience led me to my co-founder Lauren, who had been helping developers connect their applications to other services through Firebase Extensions at Google.

Together, we started Ampersand. We now work with teams at 11x, Yelp, Square, Hatch, and others to connect their products with their customers' systems of record. This book brings together what we've learned from that work and from the engineers who build and support these integrations every day.

Table of contents

  • The CRM model

  • I · What is a CRM?

    • CRM overview and connected records
    • Who uses a CRM?
    • Why not a spreadsheet?
    • How software uses a CRM

  • II · The CRM data model

    • Core objects and customer-specific schemas
    • Schema ownership and change
    • A concrete CRM model

  • III · Reading and writing CRM data

    • Reading records and receiving changes
    • Writing records, batches, and outcomes

  • IV · CRM problems in production

    • Customer-instance code and large imports
    • One status code, different failures
    • Customer changes that break connections

  • V · CRM-powered agents

    • How CRM data reaches an agent
    • Designing an AI SDR

  • VI · From one integration to enterprise infrastructure

    • Managing customer installations
    • Operating across customers
    • Regions and providers

  • VII · Appendix

    • Glossary
    • Closing perspective
    • Acknowledgments