This is the second part of our series on building a controllable operating system. In the previous article, we analyzed in detail why Telegram chats kill control in a service business and how we moved all communication to Planfix. Today, we take the next step: what to do when you already have enough data in the system, but managing it becomes increasingly difficult.
1. Planfix Scaling Limits: Why an Organized System Loses Control as Projects Grow
After all communication was moved into Planfix, it felt like the problem was solved. Indeed, the chaos vanished. Messages no longer got lost, assignees were clear, escalations worked, and the entire history was preserved and accessible. The team was working not in a messenger, but in a system built on logic and control. All kinds of "conveniences" and "supporting features" appeared for the PM and the team. At this stage, it seems like enough—as they say, "we're in business!" And that's true, but only up to a certain scale.
While you have 3–5 projects, you can still keep the entire picture in your head. You remember where the risks are, where the client is waiting for a response, and where everything is moving smoothly. You can jump into a few communication tasks and quickly grasp the context. But when the number of projects reaches dozens, a shift occurs. The problem is no longer a lack of data. The problem is that there is far too much of it.
You have the complete communication history. You have tasks, statuses, comments, call recordings with text transcriptions, and process updates. Formally, you have answers to all your questions.
To get those answers, however, you have to manually:
- Open the project
- Review the latest tasks
- Read through part of the conversation
- Understand who wrote to whom
- Piece it all together into a unified picture in your head
- Draw conclusions and outline an action plan for what to do next—and most importantly, why
And you have to do this not for just one project, but for every single one. In effect, a new bottleneck emerges: not a lack of a system, but information overload. At a certain point, you catch yourself thinking that a simple management action—"understanding what's happening across projects"—takes far too much time. Worst of all, this time is spent not on making decisions, but on gathering context.
This is precisely when the need arises to see all information at a higher, consolidated level—not in micro-details, but in a summary!
A very specific requirement emerges: the ability to open a single screen at any given moment and see a concise yet meaningful snapshot of every project—without reading through dozens of tasks and chat threads.
It looks like a simple report, but behind it lies a clear set of questions that need regular answers:
- Has there been any activity from the client side over the last 24 hours?
- Has there been any activity on our side?
- If communication occurred, what was it about (a brief summary)?
- Were there any calls, and what was discussed?
- Is there actual progress on tasks?
- What are the next steps, complete with deadlines and assignees?
- Has the overall project status changed?
The key point here is that all this data already exists in the system. The problem isn't its absence; it's scattered across different formats and timelines, unaggregated.
At this exact moment, a logical question arises: what if an AI integrated into the system gathered this picture automatically, instead of a human doing it manually?
2. Automating AI Reports in Planfix: From Business Needs to Project Chronicles Integration
Once it became clear that we needed a consolidated daily digest for every project, I didn't start with the technology. I started with something simpler: the questions I wanted answered.
The first three questions were foundational:
- Was there any client activity over the past 24 hours?
- Was there any activity on our side?
- If communication occurred, what was it about (brief summary)?
By client activity, I mean any action taken in the support chat: questions, clarifications, or reactions. By our activity, I mean a response from a project manager or developer. The logic is simple: if the client shows activity, we must react. In reality, though, there are nuances.
Sometimes the client writes nothing, but we initiate communication ourselves. To me, as an operations manager, these are fundamentally different scenarios. In one case, we are reacting; in the other, we are proactively driving the project forward.
Therefore, it was essential not just to log the fact that "activity occurred," but to differentiate:
- Who initiated it
- Whether there was movement on our side
- Whether we are ensuring progress even without a client prompt
Technically, the answer lies on the surface: you need the message history with timestamps, authors, and content. That was when the idea first struck: if this data is already present, why read it manually when we can pass it to artificial intelligence for analysis and receive a structured response?
The deeper you dive, the more operational nuances surface... There are days with zero communication. Neither the client nor our team writes anything. That's normal—it doesn't mean the project has stalled. At such moments, it is vital to track not just communication, but actual task progression. Let's look at this in more detail.
Our entire development process is structured around tasks within the client's account:
- Every request is decomposed
- Every task moves through statuses: New → Approval → In Progress → Testing → Completed
- In case of revisions, it returns for rework
These statuses represent a live model of progress. Crucially, they are automatically mirrored to our internal "home" account, where the project manager sees the full picture. These status changes eliminated "blind spots"—those days when there is no chat communication, but work is actively happening.
A developer might not write a single message, yet log time, move a task to another status, or complete a portion of work. Thanks to this tracking, "invisible" labor becomes measurable.
The third vital component is phone and video calls. For us, this is the richest communication channel. A one-hour call yields more context than an entire day of chat messaging. On a call, we review the client's screen, clarify details, get expanded answers, and formulate tasks and agreements.
Historically, however, this was a pain point. A call recording is just an audio/video file. To extract value, someone had to rewatch it or take notes manually, consuming valuable time for both PMs and developers. The solution appeared with modern transcription services. We made it mandatory to record all calls, automatically transcribe them using a custom prompt, and send the full text directly into our "home" account.
From there, the transcription service's AI performs the heavy lifting previously done by the PM:
- Generates a call summary
- Extracts key agreements
- Highlights action items
- Outlines next steps
Immediately after a call, we receive a structured list of tasks, deadlines, and open questions. Here is an example from one of our actual calls:
Next Steps
• Halyna:
- Send Halyna's instructions on UTM tag implementation to the website developer.
- Research and send instructions for Unitalk ATS configuration to pass UTM tags.
- Create a Partner contact template and design the partner management workflow.
- Build a personalized marketing planner for Svitlana.
- Complete all configurations by next Wednesday.
• Svitlana:
- Add all current marketing sources to the Sources directory.
- Provide Halyna with a list of standard partner activities (e.g., webinars, articles).
- Discuss the knowledge base budget with management.
Most importantly, this requires zero team time post-call. What used to take 15–40 minutes after every meeting now happens automatically, delivering instant results to both our internal account and the client support chat. The recording link is immediately accessible to both our team and the client.
At a certain point, I realized I could consolidate all these customer touchpoints into a single framework:
- Chat communication
- Call transcripts
- Tasks and their statuses
- Time logs from developers
All this data began to accumulate. Coming from various sources at different times, it all described one thing: project health. It needed a centralized space to aggregate, so I created a custom entity in our main account called "Project Chronicle."
This is the central hub where all information is consolidated:
- Client and internal team messages
- Call transcriptions
- Task status changes
- Developer time logs
- Conclusions and next steps
The automated pipeline operates as follows:
- Data accumulates automatically throughout the day
- Every morning, this aggregated payload is submitted to AI for analysis
- The AI generates a structured daily project report
At this stage, I achieved my goal: the ability to understand what happened on any given project in 5–20 seconds. Naturally, the next milestone immediately emerged: after learning to see the past, I wanted to foresee the future.
