Core Concepts
Understanding the foundational concepts behind Breadbox will help you use the platform more effectively and configure it to match how your MSP actually operates.
MRR vs ARR
MRR (Monthly Recurring Revenue) is the primary metric in Breadbox. It represents the predictable monthly revenue from a contract — the sum of all service line monthly equivalents. Every revenue field in the platform displays MRR first, with ARR as a secondary figure.
ARR (Annual Recurring Revenue) is simply MRR × 12. The platform computes this automatically — you never enter ARR directly.
Service lines with non-monthly billing (quarterly, annual) are normalized to a monthly equivalent for MRR calculations. A $6,000/year backup service contributes $500/month to MRR. This gives you an accurate apples-to-apples MRR number across all contracts regardless of billing frequency.
Why MRR matters: Dashboard charts, churn forecasts, pipeline value, and profitability calculations all run on MRR. Keep your service line data accurate and the rest of the platform's analytics are reliable.
Accounts vs Contacts
In Breadbox, Accounts and Contacts are completely separate objects connected through a flexible many-to-many relationship. This is intentional and different from most CRMs.
An Account represents an organization — a client company, a prospect, or a parent holding company. All contracts, deals, health scores, QBRs, and touchpoints belong to accounts.
A Contact represents a person. That person can be associated with multiple accounts simultaneously with different roles at each. This solves a real MSP scenario:
- A CFO who serves as Budget Owner for two of your client companies
- An IT consultant who is Technical Contact at three different accounts
- An insurance broker who referred multiple clients and is also a contact at one
When you update a contact's email or phone number, it updates everywhere that contact appears — no duplication.
Health Scores
Every account has a health score from 0 to 100. It's a composite of 9 signals, each weighted by importance. The score is shown as a color-coded badge:
Health scores recalculate daily and on demand. They are stored historically so you can see trends: is this client's score steadily declining over 3 months? That's a churn signal worth acting on early.
Pipeline vs Contracts
The Pipeline tracks deals that haven't closed yet. A deal has a stage, a probability, an expected close date, and estimated MRR. It's how you manage what might become revenue.
A Contract tracks what has been sold and is now active. It has service lines, actual MRR, an SLA tier, and a renewal date. It's how you manage existing recurring revenue.
When a deal closes (moves to Closed Won), you transition from pipeline to contract. The system can auto-create an onboarding project at this point to begin the delivery phase.
Org isolation
Every piece of data in Breadbox belongs to your organization exclusively. Your accounts, contracts, contacts, and health scores are completely invisible to other MSPs using the platform. This isolation is enforced at three independent layers:
- Application layer — every API call filters by your organization ID
- Database layer — PostgreSQL Row-Level Security prevents cross-tenant queries
- Integration test layer — automated tests verify Org A cannot see Org B's data
Lifecycle stages
Every account moves through a defined lifecycle from prospect to (ideally) a long-term active client. The full flow is:
Lifecycle transitions can happen manually or automatically. For example, when a deal moves to Closed Won, the account automatically transitions to WON (then ONBOARDING). When a health score drops below a threshold, the account can auto-transition to AT_RISK.
Backward transitions are allowed. An AT_RISK account that you've successfully stabilized can move back to ACTIVE. Every transition is logged in the activity feed.