When clients needed
more than leads.

It started with a healthcare client

A healthcare client needed to keep managing people after they became patients. A lead captured the initial enquiry, but ongoing patient care needed different information, workflows, and connections to doctors.

The client also wanted repeat enquiries attached to the existing patient and a separate directory for doctors.

We started developing a Patient module. Then other requests came in: one client needed agent workflows; another needed to manage documentation. The details were different, but each request called for records and processes beyond the CRM’s existing modules.

Adding fields to Leads would only take us so far. A doctor and a patient needed their own records and workflows.

We started looking for the pattern behind the requests

The CTO and I explored whether a shared configuration system could handle these needs. We researched how other CRMs supported custom business objects and used those examples to assess how the approach could work in Ledsak.

We chose to build Entity. Instead of developing a fixed module for each new request, the team could configure supported record types, fields, activities, relationships, and workflows.

That changed the design problem. We needed to make configuration understandable and decide where administrators needed freedom—and where the system needed protection.

Keep familiar interactions. Let the business model change.

Administrators can give an Entity a name, identifier, description, icon, and active status. They can define its fields, choose which activities are available, and rename activities such as Notes, Calls, Tasks, Meetings, and Emails to suit their terminology.

For the lists and record details, I reused the patterns already established in Leads. The complex design work was in the behavior behind those screens: what could change, how records connected, and what happened when a record moved into another workflow.

Reusing the interface let us focus on those questions while keeping the experience consistent across the CRM.

Give administrators flexibility with a protected foundation

I proposed locking the definitions of fields the system depends on, including Pipeline, Stage, Created By, Assigned User, Status, and timestamps. Administrators can add business-specific fields, but they can’t edit or delete these system-field definitions. The CTO reviewed and approved the approach.

The CTO also proposed Reference and One-to-Many field types. These let businesses connect records—for example, linking a Patient to a Doctor.

The same model can support a Family Entity connected to several individuals who share contact information. That’s a configuration the framework supports; it isn’t a confirmed client deployment.

Make conversion carry the context forward

I proposed prefilling information during conversion, making field mapping configurable, and retaining the original record. The CTO helped define which fields could be mapped and how the mapping would work technically.

An administrator maps source fields to destination fields. When a user starts conversion, the destination form carries over the mapped information. The user reviews it, adds anything else required, and selects the appropriate pipeline and stage.

For the healthcare client, a Lead becomes a Patient record with its own workflow. The Patient keeps a reference to the original Lead, and the Lead remains stored.

We also let administrators choose whether converted Leads remain visible in the Leads listing. Some businesses want them available for reference; others want that workspace focused on active enquiries. When visible, the converted Lead carries a Patient tag.

The mapping system supports multiple source objects, so the approach can extend beyond Lead-to-Patient conversion.

A matching phone number doesn’t always mean the same person

Businesses identify people differently. Administrators can choose a unique ID, phone number, email, a combination, or another configured field for matching. Incoming enquiries that match an existing Patient can then be associated with that record.

Shared contact details make this less straightforward. Family members might use one phone number, so automatically treating every match as one person could connect an enquiry to the wrong record.

For manual entry, the system alerts the user when a matching number exists. For external enquiries treated as re-enquiries, newly submitted details are kept in notes so staff can compare them and verify the person’s identity. A Family structure can also be configured where it fits the business.

This preserves the information needed for review. It still depends on people checking ambiguous matches, so incorrect associations remain a risk to evaluate.

Where I led, and where we worked together

I owned the UX/UI design and translated our product decisions into the configuration and record workflows. The CTO and I worked closely on the underlying behavior, with different contributions along the way.

A reusable foundation became a ready-made starting point

The healthcare client actively uses the Patient and Doctor setup. Entity has also been implemented in real estate and EdTech, with healthcare seeing the strongest adoption.

As more healthcare requirements came in, the team built a Patient Module integration on top of Entity. Enabling it creates a Patient Entity with default fields and a pipeline. The implementation team then adjusts the setup to suit the client.

That gives the team a head start on common healthcare needs while leaving room for each business’s process.

Implementation impact — less client-specific development

According to the CTO’s estimates, work that previously took around 20 days of client-specific development and workflow implementation could be configured in 2–3 days using Entity, for requirements the framework supports.

That suggests an estimated 85–90% reduction in implementation time for comparable scope. These are the CTO’s retrospective estimates; they weren’t independently measured, and comparable testing and deployment scope hasn’t been verified.

Creating custom fields was still part of both approaches. The saving came from reusing supported functionality instead of rebuilding the business workflow for each client.

CTO estimates for comparable supported requirements. Testing and deployment scope was not verified.

The work continued after release

I observed how clients used Entity and collected feedback through the Business Development team. We’re using those inputs to keep iterating as different businesses put the system to work.

We haven’t yet measured usability improvements. The concrete result so far is that Entity supports business records beyond Leads across several industries, and now powers a predefined Patient setup too.

What this changed about how I approach requests

This project made me pay closer attention to what repeated requests have in common. Patient management, agent workflows, and documentation initially looked like separate features. Looking across them helped us see a product capability we could reuse.

It also made the cost of flexibility clear. Someone still needs to understand the fields, relationships, mappings, and matching rules they configure. Protecting system fields was one safeguard. Configuration errors and ambiguous matches are areas I want to keep evaluating as the system grows.