Consolidated 5 tools into 1 Attio workspace built around the patient journey.

Before the migration, the team's day looked like this. A new patient filled out a form on the website. The submission went to Google Sheets. Someone copied the row into Brevo to send the welcome email, created a Calendly invite, watched for the booking, and updated a separate sheet when the appointment was confirmed. After the appointment, the notes lived in Gmail. If the same patient came back six months later through a different form, the new submission landed in a different sheet and the old context was gone.

Two website forms made it worse. Each needed manual Slack approval before any email went out, and repeat submissions from existing customers were silently dropped, because the deduplication rule matched on form ID rather than on person identity.

Nothing about that is unusual. It is the shape every services business arrives at when each tool was bought to solve one problem and the integration was left for later. Every step was someone copying data between tabs.

Most fragmented stacks get consolidated by putting everything on People: one big object with thirty fields, one of which is status, and the team filters by status to work out who is a lead and who is a patient. That works until it does not, and two things break first. Lifetime value gets calculated by hand in a spreadsheet, because there is nowhere on a People record to roll up revenue from multiple visits. And the team loses track of which appointment they are discussing, because every appointment is a note on the same person in chronological order.

Elfcare needed both the numbers and the journey to stay clean, so identity, care status and individual visits became three objects rather than one. The reason this split is the right call for any clinic running on Attio is that it makes two reports trivially correct: lifetime value per patient is a rollup, and examination volume by month is a count. Both are impossible on a single-object model.

This design choice comes up on every health-tech setup. The instinct is to anchor email threads to Patient, because the team thinks of the relationship as "I am emailing this patient". That instinct is wrong for two reasons.

A lead is not a patient yet. Most early conversations happen with someone who has not booked their first health check, and anchoring threads to Patient would leave those conversations homeless until the person converted — after which somebody would have to backfill the history. Nobody does the backfill.

A retention contact is not currently a patient either. After care ends the relationship continues, with follow-up communications a month and a week before the next recommended check. Anchoring threads to Patient would orphan that history too.

Anchoring to People keeps the full communication history attached to the human regardless of phase, and leaves the Patient object as a clean record of active care episodes rather than a dumping ground for everything ever sent.

Elfcare runs three motions, not one: B2C patients booking through the website, B2B corporate partners running group health checks for employees, and a local Rotary Club running its own annual screening campaign. The fragmented stack collapsed all three into one flat list, which made every campaign metric a mess.

In the new model, B2C patients land on People with type B2C and flow through the patient pipeline. B2B partners are Companies with their employees as linked People. Rotary contacts are People with a source attribute that puts them on a separate list, so the campaign's performance is visible without polluting the B2C numbers. Three motions, one workspace, separate reports — and the team stopped asking whether a given number included Rotary.

One thing did not survive the consolidation cleanly. The old Brevo setup held a long history of email send logs, some of which existed only in Brevo's UI and not in Gmail. Pulling them into Attio cleanly would have needed a Brevo export, a one-off import and a fuzzy match against new People records. We imported the most recent six months of campaign sends; older campaign history stayed in Brevo, archived and accessible by login but not stitched into the new workspace.

The team accepted the trade because the campaign history was already noisy and only the recent sends were ever referenced. Had Brevo been used as a true CRM rather than a sender, this would have been a bigger problem. We flagged it on the second call and moved on — which is the point. If we had not mentioned it, the team would have logged in on day one, gone looking for an old campaign, and lost trust at the worst possible moment.

• Separate identity from care status from individual visits. The single-object People model breaks the moment a patient comes back twice. Three objects keep email threads on the human, active care on the Patient and atomic revenue on the Examination, so lifetime value becomes a rollup instead of a spreadsheet.
• Anchor email history to People, not to Patient or Deal. A lead is not a patient yet and a retention contact is not one anymore; the thread belongs to the human across all those phases. Anchoring it anywhere else creates a backfill nobody gets around to.
• Run multiple motions on one data model with attribute-based separation. B2C, B2B and partnership campaigns belong in the same workspace, separated by type and source attributes rather than parallel records. Cross-motion reporting becomes trivial, and so does next year's audit.