Unified Work Model: Communication to Work

Act 01Context

Every product has moments where a feature changes. This chapter is about a rarer moment: when the underlying model changes.

For years, LinkedPhone primarily thought about communication. Calls, messages, voicemails, tickets, contacts, each a different entity, a different screen, a different system.

Everything worked. But as the product matured, as teams grew larger, as customer relationships grew more complex, the boundaries between these entities started dissolving.

The system saw conversations. The customer saw problems.

The system saw tickets. The customer saw work.

The system saw channels. The customer saw outcomes.

Chapter theme

The challenge was never organizing communication. It was organizing everything that happens because of it.

"We thought we were managing conversations. Our customers were managing outcomes."

Executive Summary

One customer issue, living in two timelines.

Challenge

Communication and work systems evolved independently. Conversations lived in one place, tickets in another, calls elsewhere. As businesses grew, these boundaries became artificial.

Breakthrough

Customers weren't trying to manage conversations. They were trying to resolve problems. A conversation wasn't separate from work, it was the beginning of it.

Outcome

The Unified Work Model emerged. Communication became one part of a larger system built around ownership, collaboration, priority and resolution.

Transformation at a glance

ContactA person, stored as a record

ConversationA thread, disconnected from the ticket

TicketInternal work, disconnected from the thread

One work itemEvery layer, finally the same object

Timeline: 2024Desktop expansion era
Platforms: DesktopMobile
Teams: ProductDesign · Founders
Discipline: StrategyIA · Systems
Legacy: FoundationFor AI & future CRM

Where We Were

All the ingredients existed. The model didn't.

Customers could send messages, receive calls, create tickets, assign them, track conversations, manage contacts. The functionality was all there.

The original ticket system mainly functioned as an internal collaboration layer: status, priority, owner, internal discussion. Meanwhile, the actual customer conversation stayed elsewhere. This separation felt reasonable at first. As complexity increased, it started creating friction, because the same customer issue now existed in multiple places at once.

Contact, conversation, ticket, notes. All disconnected, all describing the same underlying customer issue.

Act 02Problem

The Problem

The same story, happening twice.

The break didn't surface while redesigning mobile. It surfaced while designing desktop, where two timelines finally sat side by side: a conversation timeline, and a ticket timeline.

Customer asks a question

Conversation receives updates

Internal discussion begins, separately

One problem. Two timelines.

Customer impact

Work became fragmented. Context became fragmented. History became fragmented.

Business impact

Teams needed to switch contexts constantly. Ownership became less visible.

Internal impact

More entities would only create more fragmentation, not less, as the product grew.

Investigation

What are customers actually trying to manage?

Through desktop explorations and scenario testing, a pattern emerged. Users never talked about conversations. They talked about problems.

"My customer wants a refund."

"My lead needs follow-up."

"This order is delayed."

Never: "This conversation requires management."

Recreated from an internal mapping exercise: one inbound query forks into reply, assignment and comment threads, all forced through the same ticket object — the same object agents also reached for to track work that had nothing to do with a customer at all.

Insights

Communication was a means. Never the destination.

Insight 01

Users don't manage communication. They manage outcomes.

Observation: Users described goals, not channels.
Meaning: Communication is a means, not the destination.
Implication: The system should revolve around outcomes.

Insight 02

Work starts before tickets exist.

Observation: Many decisions happen directly inside conversations.
Meaning: A ticket is often just a continuation of work already underway.
Implication: Communication and work shouldn't feel disconnected.

Insight 03

Ownership matters more than channels.

Observation: Users cared about who owns it, who follows up, who resolves it.
Meaning: Ownership is a core primitive, not a ticket-only property.
Implication: Ownership needed to travel with the work, everywhere.

Insight 04

Internal and external work are connected.

Observation: Customers and teams participate in the same resolution journey.
Meaning: Splitting them by audience broke the shared story.
Implication: The model should reflect that shared reality.

Act 03 · Turning Point

We thought we were managing conversations.

Our customers were managing outcomes.

The conversation stopped being the center. The problem became the center. Tickets, calls, messages, tasks, notes, all became supporting actors. The customer issue became the protagonist.

Exploration Lab

Two centers were tried before the real one was found.

Direction A

Conversation-Centric Model

Failed

Why it looked promising

Kept everything inside communication

Why it failed

Internal work became difficult to track
Ownership stayed unclear

Reflects reality

Scalable

Direction B

Ticket-Centric Model

Too heavy

Why it looked promising

Everything gets tracked as work

Why it fell short

Too formal for every conversation
Not every message needs a ticket

Reflects reality

Scalable

Direction C · The winner

Unified Work Model

Succeeded

Why it looked promising

Communication as one activity inside work

Why it succeeded

Flexible, scalable, closer to reality

Reflects reality

Scalable

The percentages above are illustrative evaluation scores from the exploration process, not measured data.

Breakthrough

A container, and everything else became activity inside it.

Not conversation, or ticket. A single chain the customer issue moves through, with communication as just one stage along the way.

The Work Model diagram, the centerpiece of this chapter

ProblemThe container

CommunicationOne activity, not the whole thing

OwnershipWho's responsible, always visible

CollaborationInternal and external, together

ResolutionWhat everything is moving toward

The breakthrough wasn't realizing conversations and tickets were connected. It was realizing they were never separate.

Act 04System

System Architecture

Shared primitives, not siloed fields.

Status, priority, owner, due date, tags, timeline: these no longer belonged only to tickets. They became part of the broader work system, which meant conversations could be tracked, and ownership could finally be visible everywhere.

Status

Primitive

Priority

Primitive

Owner

Primitive

Due date

Primitive

The system got centered on work, not communication.

List items

Component

Timelines

Pattern

Detail pages

Layout

Context panels

Pattern

Status indicators

Component

Assignment patterns

Pattern

Product Showcase

One work item, every layer visible at once.

Screen · Unified work item

Overview, ownership, priority, status, activity

Everything about a customer issue, in one object instead of scattered across three.

Screen · Shared timeline

Customer events and internal work, together

Assignments, notes and updates, all visible on the same shared timeline.

Interaction & Motion

The story should never feel fragmented.

Status updates, assignment changes, ownership transitions, context switching: every interaction was designed to preserve continuity, so the work item never felt like it had jumped between two systems.

Act 05Impact

Validation

It simplified how the whole team thought, not just one screen.

Tested through desktop explorations, scenario reviews, internal testing, founder discussions and customer feedback. The response was consistent.

The model felt more naturalTeams described it as matching how they already thought about their day.

More scalable than the old modelAdding new entity types no longer meant adding new fragmentation.

It simplified future thinkingLater roadmap conversations got shorter once everyone shared the same object model.

Ripple Effects

A foundational layer for everything that followed.

The Unified Work Model to 10DLC workflows and Call Intelligence, to AI automation, to Lisa. This became one of the foundational layers of LinkedPhone's future.

The evidence vault.

Beyond Scaling deck

Embed

Desktop explorations

Figma

Relationship maps

Diagram

Timeline diagrams

Doc

Whiteboards

Miro

Founder discussions

Notes

Lessons

What we believed. What we learned.

Lesson 01

People don't manage channels. They manage outcomes.

Design the object model around what customers are actually trying to resolve.

Lesson 02

The best architecture reflects reality, not implementation.

If the model requires an explanation, it's probably modeling the codebase, not the customer.

Lesson 03

Work begins before a ticket is created.

Treat the earlier stage as part of the same object, not a separate one.

Lesson 04

The most powerful simplification is changing the model.

Not redesigning the interface on top of the old one.

Legacy

Phone numbers, then conversations, then work.

This wasn't a ticket redesign, or a conversation redesign, or a desktop redesign. It was a change in philosophy: LinkedPhone started by managing phone numbers, then conversations, and eventually work itself.

The Unified Work Model became the bridge between communication and intelligence. Without it, future AI systems and future collaboration would have stayed fragmented too.

Closing

The breakthrough wasn't realizing conversations and tickets were connected. It was realizing they were never separate in the first place.