March 15, 2026 Jorge Jiménez
Most operations disasters don't happen at scale. They happen at 15 people when the informal systems that worked at 5 people finally break under the weight of complexity nobody planned for. The startup that was nimble at seed stage becomes the 40-person company where nobody knows who owns what, approvals disappear into email threads, and onboarding a new hire takes three weeks of tribal knowledge transfer.
This is a playbook for the inflection points. Not an exhaustive operations manual, but a guide to the specific moments where adding structure pays off and where adding structure too early kills speed. The line between those two is narrower than most founders think.
At this stage, your operations "system" is the founder's brain. That's fine. The priority is finding product-market fit, not optimizing fulfillment. But three habits set you up for the next phase:
Write down what works, not everything you do. When a customer interaction goes well — a fast resolution, a deal that closed quickly — write down the exact sequence of steps. You're creating the raw material for future SOPs without the overhead of formal documentation.
Pick one communication channel and commit. Startups that let WhatsApp, Slack, email, and SMS coexist without rules create a documentation void. Every decision made in WhatsApp is a decision that disappears after 90 days. Pick a channel for customer-facing work and a separate one for internal coordination.
Track the three numbers that actually matter. Not vanity metrics. For most early-stage ops teams: time to first response, order or request fulfillment time, and customer-reported error rate. If you can track those three weekly, you'll know exactly when something breaks before it becomes a crisis.
This is where most operations problems originate. The team is big enough that information doesn't flow automatically, but small enough that formal processes feel like bureaucracy. The classic mistake is waiting until you feel the pain to add structure. By then you're firefighting, not building.
The priority at this stage is defining ownership. Not org charts — ownership. For every recurring process, there should be one person who knows the answer to "is this working?" That person doesn't have to execute it. They just have to notice when it's broken.
Customer communication: Who owns the standard for response time? Who reviews the cases where the process failed? If two different people give different answers to that question, you don't have an owner — you have a shared responsibility that nobody takes seriously.
Request routing: When a customer WhatsApp message comes in, what happens? If the answer involves someone deciding in real time, that's not a process — it's a habit. Document it, even if it's simple. "Messages about billing go to support inbox. Messages about technical issues go to product team. Everything else goes to ops." That's enough.
Hiring and onboarding: The first time you onboard someone, write down every step you took. Not a polished document — a rough list. The second time, give that list to the new hire and ask them to update it as they go through the process. By the third hire, you have a functional onboarding doc with almost no extra work.
At 25 people, you have enough recurring processes that automation starts paying for itself. But the sequence matters. Teams that automate before they document create automated chaos — you're just making your broken process run faster and at higher volume.
The rule: document it, run it manually for two weeks, then automate it. That two-week window catches the edge cases that kill automated workflows. A customer who replies to a confirmation message with a question. An order that falls outside the standard parameters. The exception that breaks the rule. You need to know about those before you automate, not after.
Rank your recurring manual tasks by two factors: frequency and cognitive load. A task that happens 50 times a day and requires zero judgment (sending a confirmation message, updating a status field, logging a received order) is your first automation target. A task that happens once a week and requires context and judgment is your last.
For most operations teams at this stage, the highest-value automations are: incoming message triage, order status notifications, appointment confirmations, and follow-up sequences for unresolved support tickets. Combined, these typically account for 40-60% of manual operations work.
Every automated workflow needs a fallback. "If the automation can't handle it, route it to [specific person]" is not a failure — it's a safety net. The worst automated workflows are the ones that silently fail: the message never gets delivered, the CRM field never gets updated, the ticket never gets assigned.
Build monitoring in from the start. A simple daily count of "items that hit the fallback" tells you whether your automation is handling the real workload or just the easy cases. If the fallback is catching 30% of volume, the automation isn't working — it's just sorting.
Past 60 people, operations stops being a function and becomes infrastructure. It's the substrate that other teams run on. At this point, the ops team's job isn't to execute — it's to build and maintain the systems that allow other teams to execute without needing ops involvement for every decision.
Two things become critical that weren't important before:
Visibility across systems. When you have five teams each using different tools, the ops team needs a consolidated view of what's actually happening. Not reports from each team — actual data from the systems themselves. If your CRM says 200 open tickets and your WhatsApp inbox shows 340 active threads, someone needs to reconcile that discrepancy before it becomes a customer problem.
Change management. Changing an automated workflow at 60 people affects 60 people. The team that was happy to try a new process at 10 people needs advance notice, documentation, and a rollback plan at 60. The operations team that skips this step will spend more time managing the fallout from changes than it saved by making them.
Different stages need different instrumentation:
Stage 1 (0-10 people): Response time, fulfillment time, error rate
Stage 2 (10-25 people): Add ownership clarity score (who knows if each process is working?), escalation frequency
Stage 3 (25-60 people): Add automation fallback rate, workflow completion rate, manual intervention percentage
Stage 4 (60+ people): Add cross-system data reconciliation rate, change rollout success rate, ops-to-business ratio
Automating before documenting (Stage 2 → 3 transition): The process looked obvious when one person was doing it. When you automate it and it handles 500 cases a day, the edge cases become a crisis.
Adding process without removing process (Stage 3 → 4 transition): Companies pile new workflows on top of old ones. Six months later, nobody is sure which one is canonical. Retire old processes explicitly when you replace them.
Treating ops as a cost center when it's actually infrastructure (Stage 4): When operations is the system that 60 people depend on to do their jobs, cutting the ops team's budget isn't cost reduction — it's degrading your company's ability to function. The ROI calculation needs to account for the cost of what breaks when ops is understaffed.
Pick your current stage. Identify the one process that's causing the most friction right now. Write down exactly how it currently works — every step, every decision point, every person involved. Time how long it actually takes from trigger to completion.
That audit is the foundation. Once you know what the process actually is (not what you think it is), you can decide whether to document it better, own it more clearly, or automate it. Most teams skip straight to automation and wonder why it doesn't work. The document-first step is not optional.
The companies that scale operations well aren't the ones with the most sophisticated tools. They're the ones that understand their processes well enough to know which problems tools actually solve.
Written by Jorge Jiménez, CEO & Co-Founder of Conectamos. Questions about scaling your operations? Talk to the team.