Forem: Michael Zelensky

Support SLA Escalation: Prevent Silent Breaches With Event-Driven Automation

Michael Zelensky — Tue, 10 Feb 2026 04:53:20 +0000

Most support SLAs do not fail loudly.

They fail quietly, until the breach is already recorded and the customer is already waiting.

In many teams, SLA risk is invisible. Escalations rely on memory, dashboards someone has to remember to check, or manual Slack messages. Engineering work is often created late, without context, or not tracked at all.

This post describes an alternative approach: treating SLA as a system-level concern, not a human responsibility.

The core problem

Support teams usually face the same patterns:

Tickets bounce between queues with no clear owner
SLA risk becomes visible only after the breach
Escalations depend on heroics instead of systems
Engineering work is created inconsistently or too late

These are not people problems. They are process and architecture problems.

The idea: SLA as an event-driven workflow

Instead of dashboards and manual checks, the system continuously evaluates SLA state and reacts automatically.

At a high level:

Ticket created or updated → event emitted
Routing assigns owner and starts SLA timers
SLA state is evaluated continuously
At-risk and breach thresholds emit escalation events
Escalations assign explicit ownership
Engineering work is created with full context when needed
A daily digest summarizes risk, breaches, backlog aging, and exceptions

Nothing is silent. Nothing depends on memory.

Architecture principles

This solution is built around a few simple principles.

Event-first design

Everything is driven by events, not direct integrations. Tickets, SLA state changes, escalations, and task creation are all events.

Integration-agnostic

The workflow does not depend on Zendesk, Intercom, Slack, Jira, or Linear specifically. These systems are adapters. The core logic stays the same.

Explicit ownership

Every escalation has a clear owner and next action. No ambiguous responsibility.

Tracked work

When escalation reaches engineering, real tasks are created and tracked with links and context. No shadow work.

Demo setup

The current working implementation runs on:

An internal Issue Tracker System (ITS)
An internal event bus

There are no live Zendesk, Intercom, Slack, or Jira integrations in the demo. This is intentional. The goal is to prove the workflow, not a specific connector.

The same architecture plugs into real systems depending on the stack a team uses.

What teams get in the pilot

The pilot focuses on one end-to-end flow:

Routing rules and escalation runbook
SLA timers with at-risk and breach detection
Automatic escalation with ownership
Engineering task creation with full context
Daily SLA digest
Audit trail of key actions and ownership changes

No migrations. No heavy setup. One workflow, done properly.

Who this is for

B2B SaaS support teams
Support Ops, CX Ops, Support Systems owners
Teams that escalate to engineering weekly
Teams discovering SLA breaches too late

Full walkthrough and diagram

A detailed breakdown, including the system diagram and full explanation, is available here:

https://liteed.com/blog/support-sla-escalation-launch

If you’ve seen SLAs fail silently in your organization, this is usually the first workflow worth automating.

10 Reasons Your Teams Need an Automation Core

Michael Zelensky — Sat, 31 Jan 2026 03:02:50 +0000

10 Reasons Your Teams Need an Automation Core

Most teams do not have an automation problem.

They have a system boundary problem.

Automation is often built “here and there” with scripts, no-code tools, and vendor workflows. Business logic becomes fragmented. Ownership blurs. Every change feels risky. Operations remain fragile even as tooling grows.

An automation core is the opposite approach.

It is a single, deliberate system where workflows live, run, are observed, audited, and rolled back. It is infrastructure for operations, not a collection of hacks.

Below are ten practical reasons why teams eventually need an automation core.

1. Manual ops do not fail loudly. They fail silently, then all at once.

Small mistakes accumulate invisibly:

skipped steps
wrong values
missing checks

Nothing breaks immediately.

Then one trigger — volume, a change, an audit — exposes everything at once.

2. Script glue has no ownership.

Automation logic often lives in:

personal repositories
cron tabs
shared folders
tribal knowledge

When it breaks, everyone and no one is responsible.

The bus factor is always one.

3. Tool UIs hide real state.

Most automation tools show a workflow, not:

execution history
data lineage
partial failures

When something goes wrong, diagnosis becomes guesswork instead of inspection.

4. No boundaries mean a high blast radius.

When workflows span multiple tools, every change has unknown side effects.

A safe deploy requires:

clear system boundaries
contracts between components
controlled entry points

Without these, small tweaks cause large outages.

5. No audit trail, no accountability.

Sooner or later someone asks:

who changed this
when
why
and what else it affected

If logic lives in emails, dashboards, and ad-hoc scripts, there are no answers.

Incident reviews turn into stories instead of evidence.

6. Rollback is manual and risky.

Ad-hoc automation rarely supports rollback.

Without versioned workflows and controlled state:

rollback means manual cleanup
data inconsistencies remain
confidence drops

Rollback is not optional in production systems.

7. Observability added later is too late.

If logs, metrics, and alerts are not first-class:

signals are missed
failures are discovered by customers
SLAs break silently

Observability must be part of the core, not an afterthought.

8. Owning the core speeds delivery.

When teams own their automation core, they reuse the same primitives:

authentication
events
retries
alerts
UI components

New internal tools ship faster.

Technical debt still grows — especially in the LLM-coding era — but it becomes visible and manageable.

9. Custom dashboards beat generic tools.

Operations need purpose-built interfaces:

queues
exceptions
approvals
timelines

Generic vendor UIs force workarounds and distort how work is actually done.

10. One core, one UI, less context switching.

The biggest UX tax inside companies is context switching.

Every new tool means:

a new mental model
a new UI
a new source of truth

A shared automation core reduces cognitive load across the entire organization.

Conclusion

Automation is no longer about saving time on individual tasks.

It is about owning how the business runs.

Teams that rely on script glue and disconnected tools accumulate hidden risk.

Teams that invest in an automation core gain ownership, observability, and control.

If automation cannot be owned, observed, and rolled back, it is not automation.

It is risk.

Original article:

https://liteed.com/blog/automation-core-10-reasons

I Spent 4 Months Trying To Build A Million Dollar AI Automation Platform. Here Is What Actually Happened.

Michael Zelensky — Sun, 07 Dec 2025 18:47:51 +0000

Four months ago I started an experiment. The goal was extreme: compress the entire lifecycle of a startup into a single sprint and use AI to guide me through everything.

Not only engineering.

Business.

Positioning.

Marketing.

Execution.

I wanted to see if AI could act as my cofounder where I lacked real experience and I would simply execute.

It did not work out that way.

But I learned more in these four months than in the previous four years.

Goals vs Reality

Planned outcomes:

• Build an automation platform and a chatbot product

• Complete a market research project

• Publish content and grow traffic

• Find customers

• Launch a clear value proposition

Actual outcomes:

• Platform built

• Market research project completed (with almost no traffic impact)

• One automation lead that did not convert

• Three beta testers for the chatbot

• Zero revenue

• Near zero traffic

And the unexpected part: I ran out of financial hope when my only serious automation client turned out not to be real.

What AI Was Good At

AI was excellent for execution:

• code

• architecture

• flows

• technical writing

• rapid prototyping

I would not have built this fast without it.

What AI Was Bad At

AI was not useful for:

• positioning

• storytelling

• messaging

• distribution

• understanding people

• sensing danger or giving critical feedback

A human advisor would have raised red flags early.

AI supported decisions that were fundamentally wrong. It reinforced flawed assumptions because it cannot feel when something is off.

The worst mistake supported by AI: believing that if I build a solid platform, write posts, and publish a site, users will appear. This model stopped working years ago, yet AI echoed it back to me as if it were still valid.

Product vs Reality

I wanted to prioritise publicity.

But my technical background pulled me back into building.

In the end the foundation had to be built anyway, so the mistake was partially inevitable. But it delayed the true bottleneck: reach.

Without an audience:

• no one sees what you build

• no one tests it

• no one trusts it

• no one buys it

Traffic is not an outcome of good work.

Traffic is its own job.

What I Learned About Myself and the Process

• AI assisted development can replace 80 to 90 percent of engineering effort if you can architect and review well.

• AI cannot replace judgment in strategy and marketing.

• The web is no longer the primary traffic source for new products.

• Market research that you do not translate into immediate action has limited value.

• Security matters immediately: your first visitors are scanners, not users.

• Extreme discipline works but burns out your social and emotional system. There is a limit.

I tried an ascetic routine: 6 AM to 10 PM work, no social life, no entertainment, strict food and sleep discipline, long-distance running, daily workouts, standing desk, meditation. It worked for two months. After that the lack of social support became a liability.

The Realisation

Everything technical was solvable.

Everything human was the bottleneck.

Attention, distribution, trust, emotion, narrative.

These are not engineering problems.

What Happens Next

The next sprint will be different.

No focus on sales.

The focus will be on reach, authority, consistent content, and building an audience.

Not chasing money.

Building momentum.

This is the pivot I needed.

Final Thoughts

Four months of intense work produced no revenue, but they revealed the essential truth. AI is great at development and execution. It is not a strategist and not a daily guide. It cannot warn you when your assumptions are wrong. It cannot tell you that your plan is unrealistic. It cannot feel the market.

I built the platform. I built the systems. I pushed AI assisted development to the limit.

But the real bottleneck was not product. It was reach.

The market does not reward effort.

It rewards attention.

This sprint gave me clarity and corrected my worldview.

Now I know exactly what must happen next.

The work continues.

Full video report: https://www.youtube.com/watch?v=hhBdGaUpyJI

More about Liteed: https://liteed.com

The New Digital-First Shift: AI Makes Development Easy, Marketing Becomes the Hard Part

Michael Zelensky — Thu, 27 Nov 2025 08:47:41 +0000

The New Digital-First Shift: AI Makes Development Easy, Marketing Becomes the Hard Part

Over the last two years AI has quietly reshaped software development.

A single developer can now produce features at the speed that once required a team.

This creates a surprising new reality for digital-first businesses:

Development is no longer the main bottleneck.

Marketing is.

Let’s break down why this shift is happening and what it means for devs and founders.

1. Development Speed Is Growing Exponentially

AI accelerates almost every part of engineering:

Implementation
Refactoring
Boilerplate generation
Documentation
Testing
DevOps guidance

One engineer can now automate internal tasks, maintain small systems, and ship features end-to-end.

If a company historically spent Y hours per week building and maintaining systems, automation pushes this toward Y/10.

Operational work shrinks dramatically.

2. Marketing Does Not Scale Like Engineering

Software scales globally with almost zero marginal cost.

Marketing does not.

Even with AI tools, the core problems remain human:

How do we explain the product clearly?
How do we differentiate in a noisy market?
How do we build trust with strangers?
How do we position ourselves against near-identical competitors?
How do we reach people at the right time?

You can automate the operations of a business.

You cannot automate trust at the same speed.

3. Massive Supply, Slow Demand Growth

Automation means each company can serve many more clients without increasing headcount.

Supply increases quickly.

But the number of customers in the world stays roughly the same.

People do not suddenly buy 10x more products just because they become easier to build.

This imbalance creates a simple market pattern:

More competitors
Faster product cloning
Lower prices
Higher visibility pressure

Engineering becomes a solved problem.

Distribution becomes the unsolved one.

4. Why Marketing Budgets Will Increase

As operations become cheap, companies shift resources:

Engineering → stays stable

Operations → shrink

Marketing → grows

When the core product takes less time to build, the biggest lever becomes:

storytelling
positioning
community
reach
content
onboarding
education

The future digital-first org has fewer operators and more people working closer to the customer.

5. The Talent Shift Is Real (and Developers Benefit)

Automation frees people who previously spent all day on manual tasks.

Their domain expertise does not disappear.

It becomes more valuable when redirected.

We will see more transitions like:

Ops → customer success
Support → education and docs
Analysts → content and community
Engineers → product marketing and technical storytelling

Developers who can explain, teach, write, or build audience will have an unfair advantage.

6. Practical Examples of the Shift

Examples happening already:

Manual data cleanup replaced by pipelines → freed hours redirected to writing docs
Support triage automated → team now focuses on tutorials and onboarding paths
Engineers build fewer internal tools → more time building public demos and growth tools
Ops staff reduced → replaced by growth and marketing hires

This is not about layoffs.

It is about rebalancing.

7. What This Means for Developers and Founders

For developers:

Coding will get even faster
The market value moves toward context, product sense, and communication
Being “just” a coder becomes rare
Technical storytelling becomes a valuable meta-skill

For founders:

The competitive edge becomes distribution
The best products will not win by default
The loudest or clearest will
Marketing will determine survival, not feature lists

For teams:

Automation is the baseline
Marketing is the new frontier
Companies that recognize this early will grow faster

Conclusion

AI reduces the cost of software creation.

Automation reduces the cost of operations.

The bottleneck shifts to the one area that does not scale automatically:

marketing, communication, and trust.

The next decade belongs not just to those who can build fast,

but to those who can reach and educate their audience effectively.

The Automation Bottleneck: Why Teams Do Not Automate Even When They Know They Should

Michael Zelensky — Mon, 24 Nov 2025 07:16:53 +0000

When computers first entered workplaces, some companies resisted the switch. Paper workflows felt normal and "good enough" until computer driven teams suddenly outpaced them in speed, accuracy, and scale.

The same pattern is happening now with automation.

Teams that still rely on manual workflows look increasingly outdated: slower, more error prone, and dependent on people acting as improvised routers between systems. Everyone knows automation is needed. Yet nothing changes.

The issue is not tooling. It is bandwidth.

The Hidden Loop That Blocks Automation

Most engineering teams live inside a constant loop of operational noise:

fixing incorrect data by hand
bouncing between tools to answer simple questions
recreating the same spreadsheets each week

Everyone agrees these things should be automated "soon".

But manual work creates exceptions, exceptions generate more manual work, and the cycle sustains itself. Firefighting fills the week. The work that would eliminate firefighting never receives a time slot.

Automation is important, but never urgent.

The Actual Constraint: Attention

Tooling is abundant today:

workflow orchestrators
integration platforms
job queues
schedulers
internal automation frameworks
AI assistants

Most teams already have the technology required to automate routine work.

What they lack is focused attention.

Automation requires uninterrupted deep work: mapping real processes, identifying state transitions, defining responsibilities, formalizing triggers. This work cannot be done between incident pings or in ten minute gaps.

If no protected time exists, automation remains a theoretical improvement rather than an engineering task with an owner.

The Cost of Remaining Manual

Manual workflows quietly degrade engineering output:

decision making suffers because data is late or inconsistent
scalability stalls because each new customer increases coordination load
onboarding slows because institutional knowledge lives in messages, not systems
risk increases because critical steps depend on memory instead of automation

Most importantly, engineers stay stuck solving the same recurring problems instead of removing them.

How Teams Break the Cycle

You do not need a big transformation program. You need one well designed automated pipeline.

A practical approach:

Pick one workflow that repeatedly slows you down
Map how it actually works today
Mark every step that is pure data movement or mechanical validation
Automate just this one flow within 2 to 4 weeks
Give one owner enough protected time to do it properly

Once the first automated path exists, the next ones become easier. Patterns stabilize. Language becomes shared. Wins become visible.

After this foundation exists, AI becomes genuinely useful, not as a patch over chaotic processes but as an amplifier for systems that already behave correctly.

Conclusion

Automation is no longer an optimization. It is baseline engineering hygiene in the same way that CI, version control, and observability became baseline.

If every week feels busy but nothing improves, it is a signal. You are postponing the work that would eliminate most of the chaos.

Original long form version:

https://liteed.com/blog/automation-bottleneck

Most Automation Isn't Really Automation

Michael Zelensky — Thu, 20 Nov 2025 13:10:22 +0000

Most “Automation” Isn’t Really Automation

A practical look from a developer’s perspective

Developers see it every day.

A spreadsheet macro. A Python script on someone’s laptop. A cron job gluing two APIs. An AI tool used for a quick repetitive task. Every team has these microautomations lying around.

Useful, yes.

Scalable, no.

If you want the long-form writeup that inspired this, it’s here: https://liteed.com/blog/automation-approach.

1. Microautomation: helpful, but fragile

Microautomation shows up as:

scripts
exports
macros
tiny AI helpers
scheduled tasks

They reduce friction but fail the moment you need:

documentation
monitoring
handoff between people
consistent behavior
scaling across teams

This helps the individual, not the organization.

2. AI and agents are just the new microautomation

AI looks powerful, but in practice behaves like upgraded macros:

great for isolated tasks
no state
no supervision
no guarantees
no integration into real processes

An agent writing reports or cleaning data helps a person. It does not automate the workflow.

3. Heavy tools like CRM and ERP don’t solve this

CRMs, ERPs, and PM suites offer built-in workflows.

They solve standard patterns, but real business processes rarely match the template.

Common problems:

partial automation
rigid flows
painful customization
limited integration
yet another silo

Buying software is not the same as automating a process.

4. Real automation lives in the BPA layer

The BPA layer is where real orchestration happens. It connects:

microtasks
AI calls
system-to-system steps
data transformations
approvals
retries
routing
audit trails
observability

This is what turns local shortcuts into a predictable system.

A BPA layer transforms:

a checklist into a workflow
a script into a service
an AI agent into one controlled step
a CRM into a participant instead of the center

5. A platform ties everything together

A proper automation platform gives developers structure:

flow definitions
integrations
safe AI execution
monitoring
governance
consistency
repeatability

Without this layer, companies accumulate disconnected hacks forever.

For reference, the platform I build follows this exact approach: https://liteed.com.

Final thoughts

Most “automation” at work is microautomation. Helpful and clever, but fragile and isolated.

Real automation requires:

orchestration
state
integration
reliability
observability

Without these elements, it remains just another smart script on someone’s machine.