Five tools to one Attio workspace: how we rebuilt the patient journey for a Swedish health-tech team in 9 days

Most fragmented CRM setups look the same from the outside. Sheets for the customer list. Typeform for the intake forms. A separate marketing tool for the emails. Calendly for the bookings. Gmail as the actual system of record, because that is where the team works. Every tool does one thing well and none of them talk to each other.

This is the story of consolidating exactly that setup for a Swedish health-tech business, and the data model decision that made it possible.

Elfcare runs health checks for individuals and corporate partners. The team needed one workspace to see a patient from first form submission through to ongoing care and retention. Their data was spread across Google Sheets, Typeform, Brevo, Gmail, and Calendly. In nine days we put everything into one Attio workspace, built a data model around the patient journey instead of around the old tools, and automated ten workflows that were running by hand.

Here is how it went.

The stack we walked into

Before the migration, the team's day looked like this.

A new patient filled out a Typeform on the website. The submission went to Google Sheets. Someone on the team copied the row into Brevo to send the welcome email. They created a Calendly invite, watched for the booking, and updated a separate sheet when the appointment was confirmed. After the appointment, 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 one needed manual Slack approval before any email went out. Repeat submissions from existing customers were silently dropped by the old automation, because the deduplication rule was matching on form ID instead of person identity.

Nothing about this 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.

The cost of running this stack was about two hours of admin per day, roughly 40 hours a month, at a typical Swedish admin rate of 350 SEK per hour. That is around 14,000 SEK a month in wages spent on copying data between tabs.

The constraint that drove the data model

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 figure out who is a lead and who is a patient.

This works until it stops working. Two things break first. Lifetime value gets calculated by hand in a spreadsheet because there is nowhere on a People record to roll up examination revenue from multiple visits. And the team starts losing track of which appointment they are talking about, because every appointment is a note on the same person, in chronological order.

Elfcare needed both numbers and the journey to stay clean. So we did not put everything on People. We separated identity, care status, and individual visits into three objects.

People stayed as the source of truth for identity and email threads. A People record has a status (Lead, Ongoing patient, Retention), a source, and a type (B2C or B2B partner). One person record per human, regardless of how many forms they fill out or how many times they come back.

Patient is a custom object created only when a person is actively under care. A Patient record links back to a Person and carries the next examination date, the count of past examinations, and the total lifetime value rolled up from every examination they have ever had.

Examination is a custom object with one record per visit or health check. Date, type, value, products, notes. Atomic and immutable. Each examination is its own row, not a paragraph buried in a Patient note.

The reason this three-object split is the right call for any clinic or care provider running on Attio is that it lets two reports be trivially correct. Lifetime value per patient is a rollup. Examination volume by month is a count. Both of those numbers are impossible on a single-object model and trivial on this one.

Why People keeps the email threads, not Patient

This is the design choice that 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. Anchoring threads to Patient would leave those conversations homeless until the moment the person became a patient, and then you would have to backfill the history. Nobody does the backfill.

A retention contact is not currently a patient either. After their care ends, the relationship continues. The person is on the Retention list, getting follow-up communications a month before and a week before the next recommended check. Anchoring threads to Patient would orphan that history again.

Anchoring threads to People keeps the full communication history attached to the human, regardless of whether they are currently a lead, a patient, or in retention. The Patient object becomes a clean record of active care episodes, not the dumping ground for everything the team has ever sent the person.

The ten workflows

Once the model was in place, ten workflows turned the fragmented day-of-admin into something that ran itself.

Lead capture from website forms. Both Typeform forms and the Google Sheets form flow into Attio via Relay. If a person already exists, the source attribute is updated and the existing record is reused. If they do not, a new Person is created. A Slack approval step gates the first outbound email so the team controls voice on cold replies.

Auto-create Patient on status change. When a Person's status changes to "Ongoing patient", a linked Patient record is created automatically and linked back to the Person. No duplicate data entry.

Rollup patient lifetime value. Every new Examination triggers a workflow that sums all examination values for the linked Patient and writes the total to a Total Value attribute on the Patient. The number stays correct without anyone reaching for a calculator.

Route patients by examination type. When an Examination is logged, the related Patient is pushed onto the right list view based on examination type. Full health check goes to one list. Specific tests go to another. The team sees only the patients they are working with that week.

Retention automation. When a Patient is marked done after a care episode, the Person's status flips to Retention and the Patient is moved off the active list. Four scheduled workflows then move the Patient through retention stages: one month before the recommended follow-up, and one week before. The team does not chase. The system surfaces.

Typeform follow-up sync. Completed post-visit Typeforms find the matching Patient and populate the right attributes on the record (satisfaction score, follow-up notes, any flagged issues). The form data does not live in a separate tool.

The remaining four workflows handle B2B partner intake, Rotary Club outreach, repeat-customer detection on the deduplication path, and Calendly booking sync. None of them are exotic. Together they are the difference between a team copying rows between sheets all day and a team that opens the workspace, sees what needs attention, and works.

The dashboard the team actually uses

A consolidated workspace is only useful if the numbers the team looks at every week come out of it.

We built one Patient dashboard. Four views.

Patients. Count of active patients, split by examination type. The team sees how heavy the next month's care load looks.

Examinations. Count per month and per quarter. The volume metric.

Revenue. Sum of examination values per month and per quarter. The money metric.

ARPU. Average revenue per patient per month and per quarter. The efficiency metric, which is what tells the team whether they are running a healthy business or a busy one.

These four views are now the meeting agenda. They were not possible on the old stack because the data lived in five places and nobody was going to pivot five sheets every Monday morning.

The split between B2C, B2B, and Rotary

Elfcare runs three motions, not one. B2C patients book through the website. B2B corporate partners run group health checks for their employees. The local Rotary Club runs its own outreach campaign for an annual screening event.

The fragmented stack collapsed all three into the same flat list, which made every campaign metric a mess. The Attio model separates them cleanly.

B2C patients land on People with type "B2C" and flow through the patient pipeline. B2B partners are Companies, with their employees as People linked to the partner Company. Rotary Club contacts are People with a source attribute that puts them on a separate list, so the team can see how the Rotary campaign is performing without it polluting the B2C numbers.

Three motions, same workspace, separate reports. The team stopped asking "is this number including Rotary?" because the filters are obvious now.

What we were honest about

One thing did not survive the consolidation cleanly.

The old Brevo setup had a long history of email send logs. Some of those threads sat in Brevo's UI and were not in Gmail. Pulling them into Attio cleanly would have required Brevo's export, a one-off import, and a fuzzy match against new People records. We did a partial import for 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 the recent sends were the only ones they referenced. If the team had been using Brevo as a true CRM rather than as a sender, this would have been a bigger problem. As it was, we flagged it on the second call and moved on.

This is the kind of thing that has to come up early. If we had not mentioned it, the team would have logged in on day one, gone looking for a 2024 campaign, and lost trust at the wrong moment.

The result

Five tools became one workspace in nine days.

Three objects (People, Patient, Examination) model the patient journey the way the team actually works, not the way the old tools forced it.

Ten workflows automated the day-of-admin that used to cost roughly two hours a day, freeing up around 40 hours a month or about 14,000 SEK a month in wages.

One dashboard, four views (Patients, Examinations, Revenue, ARPU) runs the weekly meeting off the same workspace the team is logging into all day.

Three motions (B2C, B2B partners, Rotary) live cleanly side by side on the same data model, with separate reports and no polluted numbers.

The Elfcare team now operates the workspace independently.

> "George was very helpful in setting up our Attio records and workflows from scratch. Always available on Slack and replied within no time. Recommend! 5++++ stars"

> — Julia Elf, Elfcare

What this case is about, beyond Elfcare

Three patterns from this build come up on almost every health-tech, clinic, or care-provider workspace we touch.

Separate identity from care status from individual visits. The single-object People model breaks the moment a patient comes back twice. Three objects (Person, Patient, Examination) keep email threads on the human, active care on the Patient, and atomic revenue on the Examination. 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 a patient anymore. The thread belongs to the human across all those phases. Anchoring threads anywhere else creates a backfill problem the team never gets around to.

Run multiple motions on the same data model with attribute-based separation. B2C, B2B, and partnership campaigns belong in the same workspace, not in separate tools. Separate them with type and source attributes, not by spinning up parallel records. Cross-motion reporting becomes trivial. So does next year's audit.

If you are running a health-tech or care business on five tools and your weekly numbers live in a spreadsheet, the move to Attio is not just a tool swap. It is a chance to put the patient journey back where it belongs.

The full structured case study for Elfcare lives at craftt.io/case-studies/elfcare. The generic playbook for clinics and care providers lives at Attio for healthcare and clinics. If you want to talk through your own setup, book a call.