Q1 2026 rezultatai

Trumpa praėjusio ketvirčio apžvalga: kas pavyko, kas ne, ką darome toliau.

Q1 2026 rezultatai vs planas

Pajamos ir pelnas

Q1'26 vs Q1'25

Projektų pokyčiai

Strateginiai tikslai ir OKR

Kaip strategiją paverčiame pamatuojamais rezultatais.

Įvadas

Kodėl matuojame?

• Tvari įmonės plėtra neįmanoma be aiškaus supratimo, kiek efektyviai veikiame šiandien.
• Objektyvus įmonės "sveikatos" vertinimas leidžia laiku identifikuoti problemas ir galimybes.
• Investicijos turi būti sąmoningos, pamatuotos ir kurti ilgalaikę vertę — o ne didinti išlaidų naštą.
• Matuojame tuos rodiklius, kurie strategiškai svarbūs — kad galėtumėm strategijos laikytis.

Strategija

Du strateginiai tikslai

• Įmonę išlaikyti healthy
  • Be sveikos finansinės būsenos negalime mokėti konkurencingo atlyginimo, investuoti į įrankius, mokymus ir komandos augimą.
  • Healthy reiškia ne tik "šiemet pelningi" — reiškia atsparumą blogiems ketvirčiams ir gebėjimą priimti ilgalaikius sprendimus.
  • Tai pamatas, kuris komandai duoda stabilumą, prognozuojamą karjeros augimą ir laisvę pasirinkti, kuriais projektais dirbti.
• Užtikrinti tvarų augimą
  • Stagnacija realybėje yra atsilikimas — rinka, atlyginimai ir technologijos juda pirmyn; nesivystant prarandam vietą.
  • Augimas atveria galimybes — naujus projektus, naujas kompetencijas, naujus žmones komandoje, didesnę įtaką rinkoje.
  • "Tvarus" reiškia ne bet kokia kaina — augam išlaikydami kokybę, klientų pasitenkinimą ir komandos sveikatą.

Pamatas

Išlaidų klasifikavimas

Visos įmonės išlaidos skirstomos į dvi grupes:

• COGS (Cost of Goods Sold) — klientams suteiktų paslaugų savikaina; tiesiogiai susijusi su pajamų generavimu.
• Expenses — veiklos išlaidos, leidžiančios verslui veikti ir augti:
  • S&M (Sales & Marketing) — pipeline generavimas, klientų pritraukimas.
  • R&D (Research & Development) — produkto, procesų gerinimas, inovacijos.
  • G&A (General & Administrative) — apskaita, administracija, valdymas.

COGS santykis su revenue — vienas esminių delivery efektyvumo rodiklių.

Sveikata

Įmonės sveikatos zonos (% nuo revenue)

Healthy zonoje — stiprus delivery, fokusuotas R&D, S&M generuoja pipeline. Rezultatas: stabilus pelnas ir kontroliuojamas augimas.

Sveikata

Greita diagnostika

Kiekvienas rodiklis turi dvi puses — ir per aukštas, ir per žemas atveda į problemą:

Operatyvika

Komandos paskirstymas pagal kategorijas

Kiekvieno komandos nario laikas pasiskirsto tarp COGS (klientams) ir Expenses (vidaus darbų).

Healthy payroll: 60–75% nuo revenue. Apie 65–70% viso komandos darbo laiko skiriama klientams (delivery) — likusi dalis S&M, R&D ir G&A veikloms.

Sistema

Kas yra OKR?

Žinodami, kuriose zonose esame ir kaip pasiskirsto komandos laikas, mums reikia būdo strateginius tikslus paversti konkrečiais veiksmais. Tam naudojame OKR.

• Objective — ką norime pasiekti. Kryptis, kokybinis sprendimas.
• Key Result (KR) — kaip suprasime, kad pasiekėme. Kiekybinis, su terminu, ambicingas bet realus.
• KPI (Key Performance Indicator) — nuolat sekama metrika; "pulsas" be galutinio finišo taško.
• Metrika — bet kuris pamatuojamas dydis. Ne kiekviena metrika yra svarbi.

Objective   Įmonė healthy
KR          EBITDA ≥ 15% iki 2026 Q4
KPI         COGS / revenue (sekama kas mėnesį)
Metrika     Komandos billable valandų suma

Strategic OKR #1

Įmonę išlaikyti healthy

Pamatuojami rezultatai:

• Net profit ≥ 10–15% (arba EBITDA ≥ 15–20%)
• COGS ≤ 50–55% nuo revenue
• Payroll ≤ 75% nuo revenue
• ≥ 65–70% payroll skiriama COGS (delivery)
• S&M 8–12% · R&D 5–10% · G&A ≤ 15–20%
• DSO 15–30 d.

Strategic OKR #2

Užtikrinti tvarų augimą

Pamatuojami rezultatai:

• Revenue augimas ≥ 20% YoY
• Customer retention ≥ 90% (Churn < 10%)
• Pipeline ≥ 3 mėn. revenue
• ≥ X naujų klientų / mėn.
• NPS ≥ 40
• S&M ≤ 15% nuo revenue
• ≥ 70% revenue iš ilgalaikių klientų (optional)
• LTV / CAC ≥ 3 (optional)

Kaskadavimas

Nuo strategijos iki kiekvieno žmogaus

OKR sistema veikia trim lygiais — kiekvienas žemesnis lygis paaiškina, kaip pasiektųsi aukštesnio lygio tikslai. Taip strategija pasiekia kiekvieno komandos nario kasdienybę.

ĮMONĖS LYGIS    →   Strateginiai OKR
                    Kur einam? Healthy + Tvarus augimas
                              │
                              ▼
SRIČIŲ LYGIS    →   Taktiniai OKR
                    Kaip ten nueisim? Pardavimas · Klientai · R&D · Gamyba
                              │
                              ▼
ŽMOGAUS LYGIS   →   Asmeniniai OKR
                    Ką aš darau? Konkretūs ketvirčio tikslai kiekvienam

• Kiekvienas lygis siejasi su aukštesnio lygio tikslu — nė vienas OKR neegzistuoja izoliuotai.
• Komandos narys mato, kaip jo darbas siejasi su įmonės kryptimi.
• Asmeninis OKR — aiškus kelias augimui: kompetencijos, atsakomybė, įtaka.

Kaskadavimas

Taktiniai OKR — keturi pjūviai

Strateginiai OKR yra aukšto lygio. Žemiau jie kaskaduojasi į taktinius OKR — konkretesnius rezultatus kiekvienoje srityje.

Strategic Health    →  Gamybos efektyvumas + Klientų santykiai (DSO)
Strategic Growth    →  Pardavimas ir augimas + Klientų santykiai (retention)
Abu strategic       →  R&D ir tobulėjimas

• Pardavimas ir augimas — PMs + CEO/CTO
• Klientų santykiai — PMs
• R&D ir tobulėjimas — CTO + Devs
• Gamybos efektyvumas — PMs + Devs

Taktinis OKR · Pardavimas

Pildyti ir konvertuoti pipeline

Du atskiri pipeline: nauji klientai · esami klientai (upsell)

• Pipeline užpildyti resursai ≥ 3 mėn. gamybos capacity
• Pipeline vertė ≥ 3 mėn. revenue (nauji) + ≥ 1 mėn. (upsell)
• Pipeline įvertis € / gamybos val. ≥ 150 €
• Trivian produktai pipeline'e: 20% Q2 · 25% 2026
• Naujų sutarčių apyvarta: 63 k€ Q2 · 172 k€ 2026
• Naujų sutarčių iš viso: 10+ Q2 · 30+ metinis
• Qualified leads iš performance marketingo: 30+ Q2 · 120+ 2026
• Per Q2 išsitestuoti 4 marketing kanalus: YouTube · PMax · AdWords · SEO

Taktinis OKR · Klientai

Išlaikyti ir stiprinti ryšį su esamais klientais

• ≥ 1 kartą per ketvirtį sukontaktuoti savo iniciatyva — pozityviais reikalais, ne dėl problemų
• NPS apklausa ≥ 2x/metus kiekvienam klientui
• ≥ 25% esamų klientų kreipiasi savo iniciatyva dėl papildomų paslaugų (per ketvirtį)
• Sąskaitos apmokamos per ≤ 30 d.
• ≥ 90% klientų turi abonentinę palaikymo sutartį
• Kritinių incidentų / eskalacijų ≤ 1 / ketvirtį

Pagrindas — CRM su pilna klientų informacija, komunikacijos planu ir veiksmų istorija.

Taktinis OKR · R&D

Nuolat gerinti įrankius, procesus ir paslaugų portfelį

• ≥ 1 Operational R&D iniciatyva per ketvirtį (AI įrankiai, automatizavimas, procesai)
• ≥ 1 nauja paslauga arba produktizuotas sprendimas per ketvirtį
• Kiekvienas developer pasikelia kompetencijas per ketvirtį (žinių vertinimas + individualus planas)
• Hosting / infrastruktūros incidentų ≤ 2 / mėn.
• Kiekvienas developer ≥ 1 workshop arba prezentacija per ketvirtį

Taktinis OKR · Gamyba

Teikti paslaugas kokybiškai ir efektyviai

Key Results (preliminariai):

• Billable utilization ≥ 75% (developers)
• Vidutinis ticket / užduoties sprendimo laikas ≤ X d.
• SLA laikymasis ≥ 95%
• Vienas PM valdo ≤ X klientų (kad kokybė nenukentėtų)

Šios srities OKR dar nesame iki galo konkretizavę. Kai turėsime pilną taktinių OKR planą — kalbėsimės su kiekvienu komandos nariu apie asmeninius tikslus ir siekiamus rezultatus.

Toliau

Veiksmų planas

1. Peržiūrėti metinį biudžetą ir susibiudžetuoti sritis pagal Healthy zoną. done
2. Peržiūrėti kiekvieno komandos nario įsitraukimą į konkrečią sritį. planned
3. Kiekvienai sričiai (COGS, S&M, R&D, G&A) suformuoti veiksmų planą, paskirstyti resursus, nustatyti OKR. in progress
4. Identifikuoti gaps — kur trūksta resursų arba kur jie nebus tinkamai įsisavinti. planned
5. Pagrįstai priimti sprendimus dėl žmonių samdymo arba paslaugų pirkimo. planned
6. Reguliariai matuoti strateginių OKR pažangą — Healthy rodiklius (kaštai vs revenue, sveikatos zona) ir augimo rodiklius (revenue YoY, retention, NPS) — bei reaguoti į nukrypimus. planned

Pradedame nuoseklų laiko trackinimą pagal kategorijas (Klientai · S&M · R&D · G&A) — be šito visa sistema neveikia.

Kas laukia programuotojo pozicijos ateityje?

AI jau dabar kompetentingai generuoja kodą. Per artimiausius metus greičiausiai atliks didžiąją dalį rutininio implementation darbo.

Jei „developer" pozicija yra tik apie programavimą kaip kodo rašymą — tai ji patiria realų spaudimą.

Šiandien — atviras ir nuoširdus klausimas kiekvienam:

• kur esame ir ką darome dabar?
• ką darysime ateityje?

Realybės kontūrai

Ką AI pakeičia — kur neverta konkuruoti

• Rutininis kodo rašymas — funkcijos, klasės, CRUD, boilerplate
• Sintaksė ir lookup — atsiminti „kaip Laravel'yje padaryti X", standartiniai pattern'ai
• Infrastructure / stack setup — parašyti docker-compose stack'ą arba padaryti projekto kopiją
• Greitas prototipas — 80% sprendimo per kelias minutes
• Atsikartojančios užduotys su aiškiu dėsningumu — refactoring'as, kodo formatavimas, vertimų išrinkimas

Greitis rašant kodą — tikrai ne programuotojo naudai.

Kur mūsų stiprybės

Ko AI nepakeis

• Užduoti taiklius klausimus — AI dažnai vykdo užduotį arba priima jau esantį kodą, bet nekelia klausimo, kodėl / ar to iš vis reikia
• Laikyti visumą galvoje — klientas, kontekstas, projekto istorija, business taisyklės — pilną paveikslą mato tik žmogus
• Vartotojo patogumas — kas aišku, patogu ir intuityvu, sprendžia tik tas, kuris produktą naudoja. AI gali sukurti UI, bet negali jo objektyviai įvertinti, ar patogu naudoti
• Prisiimti atsakomybę — po commit'u pasirašai tu, ne AI modelis

AI ne tik kodui

9 kasdienio darbo sritys

Didžiausias privalumas

Ne kas greičiausiai atlieka užduotį

• Rasti efektyviausią problemos sprendimą — iš visų galimų variantų atrinkti tinkamiausią pagal kliento poreikius
• Integruoti ir jungti — sujungti AI, kodą, bibliotekas, servisus į veikiantį sprendimą
• Matyti visumą — kaip dalys susijungia į sistemą, kuri sprendžia kliento problemą

Curation. Synthesis. Judgment. Tai, ko AI neturi.

Ašis 1

Mažiau rašymo → daugiau mąstymo

• Mažiau laiko skiriama kodo rašymui
• Daugiau laiko — task'o supratimui, sprendimų svarstymui, review'inimui
• Tikslas ne kodas, o efektyviai sukurtas kokybiškas sprendimas

Ašis 2

Nuo gylio → į plotį

• Anksčiau: specializacija viename siaurame domene (PHP backender, Frontender, DevOps, ...)
• Dabar: plotis ir įvairovė — gebėjimas taikyti, jungti ir integruoti skirtingas technologijas
• AI atstoja gylį (sintaksę, library detales). Plotis ir pilnas kontekstas lieka tau

Plotis vertingiau už gylį. Gylį AI uždengia, kai reikia.

Ašis 3

Nuo programuotojo prie sistemų architekto

• Ne sysadmin. Bet supranti, kur tavo kodas gyvena
• Ne DevOps. Bet moki perskaityti docker-compose.yml ir lokaliai pasileisti visą stack'ą
• Ne security ekspertas. Bet atpažinti OWASP Top 10 problemą savo kode — privalu

Architektas neima plytos į rankas. Bet žino, kaip jos sudėtos visame pastate.

Sprendimų matrica

Build · library · self-host · SaaS

• Kurti nuo 0 → tik tai, kas iš tikrųjų unikalu produktui
• Naudoti kaip biblioteką → datos, CSV, paveikslėliai, PDF, validacija (commodities)
• Self-host mikro-servisas → DB, Elasticsearch, n8n, image proxy, Varnish, Grafana — kai norisi pilnos kontrolės ir galima sutaupyti
• Paid SaaS → email delivery, Stripe, Cloudflare, Google OAuth — kai klaida ar sutrikimai turi rimtų pasekmių

Klausimas ne „ar galime tai sukurti?" — o „ar turėtume, atsižvelgiant į visa kita?"

Technology awareness

9 sritys, kurių baseline turi būti

TRIVIAN platforma

How we're building a composable e-commerce platform from Laravel packages — and where it's going.

End state

A project's composer.json

• trivian/plan-pro — the feature set (catalog, cart, orders, blog, GDPR…)
• trivian/theme-cartzilla — the storefront theme
• trivian/delivery-dpd — an optional purchased add-on

The Laravel project itself is thin — routing, config, environment. Business logic lives entirely in packages.

Package map

What's inside

• Foundation — core, mail, multidomain
• Content & Marketing — content, banners, blog, subscribers
• Catalog — catalog (products, categories, brands, variants, filters)
• Commerce — ecommerce, payment, delivery, invoices
• Operations — customer, department
• Theme — theme-cartzilla

Package architecture

Self-registering packages

• Each package has a ServiceProvider — Laravel auto-discovers it
• The provider registers with PluginRegistry: its Filament resources, routes, migrations, settings, and seeders appear automatically
• Other packages and the host project need to know nothing about it — no manual wiring
• Add a package to composer.json → admin panel gains new sections, routes register, migrations run

Extensibility

The project can override almost anything

• Views — publish a package view, customize it; the package respects the project copy
• Controllers — swap in a project-level controller via the service container or route override
• Models — extend a package model in the project, bind the subclass in the container
• Settings — packages expose config keys; projects override them in config/ or env

Packages provide sensible defaults. Projects customize without touching package source.

Quality

Testing with Pest

• Every package ships its own test suite — unit and feature tests co-located with the code
• Tests run against a real database; no mocked layers that diverge from production
• New functionality requires a test; CI fails if tests don't pass

Knowledge base

Everything is documented

• Data architecture — one doc per model group: fields, relationships, casts, behaviors
• Development log — every feature starts with a plan doc, ends with a results doc
• Architecture notes — non-obvious decisions captured where the code can't explain itself
• All docs live in /docs and are served as a browsable Docsify site

FilamentPHP

Server-driven admin UI

• Built on Livewire + Alpine.js + Tailwind CSS — the TALL stack
• Define resources, forms, and tables in PHP — Filament generates the UI
• Why we chose it: rapid CRUD generation, built-in auth & permissions, consistent UX, great DX
• Current result: 39 resources across 13 packages — products, orders, pages, menus, customers, GDPR, settings…

Current state

Why Bootstrap — and why it's temporary

• The Cartzilla theme is a purchased HTML/CSS theme built on Bootstrap 5
• Integrating it as-is was the fastest path to a working, polished storefront
• The theme is fully isolated in trivian/theme-cartzilla — the rest of the platform doesn't care
• Swapping the theme = swapping the package; core business logic is untouched

Direction

TALL for future themes

• TALL = Tailwind + Alpine.js + Livewire + Laravel
• Next purchased or custom themes will use Tailwind instead of Bootstrap
• Livewire is already in use for storefront components (cart, catalog filters, checkout)
• Admin panel (Filament) is already fully TALL — consistent mental model across the stack

Current setup

Monorepo with Composer path repositories

• All packages live in packages/trivian/ inside one git repository
• Composer loads them as local path dependencies — no publishing required
• Changes are instant; no need to tag or release during development
• Tests, migrations, and seeders for each package co-located in the same repo

Future versioning

Semver: minor auto, major manual

• Minor versions — backward-compatible additions; projects update automatically via composer update
• Major versions — breaking changes (renamed models, removed features, changed contracts); projects must explicitly bump the version constraint
• Plans pin their package dependencies; upgrading a plan = upgrading a group of packages together
• End goal: packages published to a private registry; a fresh project pulls everything from Composer with no local monorepo needed

Komanda

Kas prie ko prisideda

• PO — Gvidas (50%+) — produkto vizija, backlog, prioritetai, code review autoritetas
• 2 × TDEV (~30–40% kiekvienas) — core platformos vystymas
• 4 × DEV (~5–10%) — klientų projektai + periodiškas prisidėjimas prie platformos
• CTO — Giedrius — strategija, platformos architektūros approve, infrastruktūra

Core R&D: ~1.5 FTE. Bendrai su indirect R&D per klientų projektus: ~15–18% įmonės dev resursų.

Pagrindiniai principai

Kaip mes dirbame

• MVP-first — veikiantis funkcionalumas svarbiau nei nupoliuotas; trūkumai → Polish Backlog
• Platforma-first — generic feature'ai kuriami platformos lygyje, ne kliento-specific kontekste
• Klientų projektai prisideda — naudojame feature'us, kuriuos ir taip planavome kurti
• Async kur įmanoma — meet'ai tik tiems sprendimams, kurių async neišsprendžia
• Claude Code kaip multiplier — feature detalizacija, ticket'ai, programavimas

Atsakomybės

Visi feature request'ai eina per PO

• Sales / PM — renka klientų poreikius, perduoda PO (ne tiesiai dev'ams)
• PO — sprendžia: platforma ar customization? Rašo ticket'us su acceptance criteria. Nustato prioritetus.
• Dev komanda — gauna aiškius, aprobuotus ticket'us; neužsiima scope derybomis

PO yra filtras tarp biznio ir dev komandos. Tai apsaugo dev'us nuo klientų spaudimo ir užtikrina platformos brandinimo discipliną.

Ritualai

Meet'ų struktūra

• #trivian-daily Slack — kasdienė async sinchronizacija (PO + TDEV, 5 min individualiai)
• Sprint planning — 1× per 2 sav., 60 min; sprint goal + backlog
• Sprint demo — 1× per 2 sav., 30–45 min; progresas matomas visiems
• Trivian showcase — 1× per 2 sav., 30 min; naujų feature'ų pristatymas extended DEV'ams
• Arch sync — 1× per sav., PO + CTO; architektūriniai sprendimai ir ADR'ai

Motyvacija

Ketvirtinis OKR ciklas

• OKR'ai apima 3 plotmes: Produktas, Kokybė, Procesai
• Konkretūs skaičiai bus nustatomi kartu su Gvidu
• Mid-quarter review po 6 sav. — koregavimai jei reikia

AI gamybos procese

Kaip užduotys keliauja nuo kliento poreikio iki pridavimo klientui — ir kur ir kaip AI keičia kiekvieną etapą

Keturi etapai nuo poreikio iki pristatymo

• 01 Poreikiai · klientas + PM + AI
• 02 Užduotis programuotojui · PM + AI
• 03 Sprendimo įgyvendinimas · DEV + AI
• 04 Validacija ir pridavimas · PM + AI

PM išsiaiškina ir suderina su klientu, ko tiksliai reikia

• Biznio poreikis ir tikėtinas rezultatas
• Kas techniškai įmanoma, koks effort
• Panašių sprendimų pavyzdžiai
• Rezultatas — su klientu raštu suderintas poreikis

Ar programuotojas šitame etape dalyvauja? Priklauso nuo situacijos, sprendžia PM'as, kaip efektyviau. AI gali padėti atsakyti į daugelį klausimų greičiau ir pigiau. Bet faktas tas, kad programuotojo darbas tiesiogiai priklauso nuo to, kaip gerai darbas šiame etapas atliktas.

PM aprašo užduotį programuotojui

PM formuluoja techninę užduotį programuotojui. Tai ne copy-paste kliento pageidavimai, bet ir:

• Biznio kontekstas — kodėl to reikia, ką tai keičia?
• Panašūs pavyzdžiai — kur tai jau buvo daroma?
• PM įžvalgos — į ką atkreipti dėmesį, galimos rizikos, "corner cases"
• Techninio įgyvendinimo vizija — pagal kurią buvo vertinamas effort
• UX perspektyva — kaip tai veikia iš vartotojo pusės

PM žino produktą — ne kodą

Svarbūs apribojimai: PM suformuluoja užduotį turėdamas pilną biznio ir projekto know-how bei suprasdamas vartotojo kelią (UI/UX), bet neturint prieigos prie kodo. Tai gairės programuotojui — ne konkretus techninis sprendimas.

Čia AI labiausiai padeda PM: struktūruota, detali užduoties dokumentacija anksčiau buvo labai imli laikui ir neįdomus darbas. Dabar tai greitai ir net aiškiau atlieka AI. Sarbu sutarti ir suprasti, kad visa pateikta informacija yra tikrai perskaityta ir patvirtinta PM — tai ne perteklinis tekstas dėl akių, o vertinga informacija, svarbi tinkamai atlikti užduotį.

Formatas:

• Flow nesikeičia. Užduotys lieka Trello.
• Prie užduoties prisegamas detalus aprašymas: eksportuotas .md failas arba read-only nuoroda į AI chat'ą (deja, nėra galimybės kolaboruoti).

Techninis sprendimas ir įgyvendinimas su AI pagalba

1. Programuotojas perskaito PM užduotį
2. Kartu su AI agentu — turint kodo ir architektūros kontekstą — suformuluoja techninį planą
3. Jei kažkas prieštarauja PM aprašytam sprendimui — būtina aptarti su PM prieš pradedant implementuoti
4. Patvirtinus techninį planą, kodas rašomas su AI agento pagalba
5. Programuotojas peržiūri kiekvieną pakeitimą, supranta kodą ir priimtus sprendimus

Atsakomybė visada lieka žmogui

• AI yra tik priemonė
• Rezultatas priklauso nuo suteikto konteksto
• Už galutinį sprendimą atsako tas, kas naudojasi priemone siekdamas rezultato
• DEV peržiūri kiekvieną pakeitimą ir supranta kodą
• Bug, security ar performance issue — atsako tas, kas merge'ino
• Nėra dalykų, kuriuos „padarė AI ir neaišku kaip/kodėl"

Ši nuostata neleidžia AI tapti pretekstu blogai kokybei. Priešingai - turėtų padėti kurti kokybiškesnius sprendimus.

Ne greičiau, o kokybiškiau

• Sutaupytas laikas eina į testavimą, dokumentavimą, edge case'us
• Tikslas — kokybiškesnis rezultatas, ne vien tik greitis
• Dokumentavimas ir testavimas - tai kas buvo labai imlu laikui, ir ko nemokėjom efektyviai daryti
• Rezultatas dabar lengvai dokumentuojamas su AI — galima paruošti .md ataskaitą, kas, kaip ir kodėl atlikta, kokie scenarijai buvo ištestuoti.

PM validuoja ir priduoda sprendimą klientui

• Palygina DEV ataskaitą su pirminiu poreikiu
• Patikrina, kaip tai veikia iš vartotojo pusės (UI/UX)
• Suformuluoja galutinę ataskaitą klientui suprantama kalba
• Priduoda darbą klientui

AI dalyvauja kiekviename etape — atsakomybė žmogui

• Po pietų — Tema 06: realūs E-Lab projektų pavyzdžiai
• Live demo, kas pavyko, kas ne
• Diskusija ir jūsų klausimai

Klausimai prieš pietus?

AI panaudojimas, II dalis - realūs pavyzdžiai ir diskusija

Marketingas: Social Media, SEO, reklamos kampanijos

Q1 = pamatai. Q2 = matavimas.

// Šio ketvirčio kontekstas

Šiandien — kas paleista. Kitam ketvirtiniam — kas iš to veikia.

Trivian — paleisti pamatai per Q1

Trivian — paleisti 4 įsigijimo kanalai

🎬 Video reklama

Platforma: YouTube Paleista: kovo pab. Tikslas: awareness

🎯 PMax

Platforma: Google Paleista: kovo pab. Tikslas: konversija

🔍 Search Ads

Platforma: Google Paleista: kovo pab. Tikslas: platus raktažodžių spektras (visas funnel)

📈 SEO

Organinė paieška Pamatas: vasaris Tikslas: ilgalaikis srauto šaltinis (rezultatai per 3–6 mėn)

Q1 — pirmieji 3 mokami kanalai. SEO — investicija į ateitį.
Q2: matuosim, kuris kanalas atneša geriausius leadus.

Trivian — kiekvienas kanalas veda į savo landing

🎬 Video reklama Žmogus dar nepažįsta produkto — reikia susipažinti

🎯 PMax 🔍 Search Ads

Žmogus jau ieško sprendimo — reikia greitai parodyti vertę

TITULINIS Pilna istorija, produkto apžvalga

DEDIKUOTAS PUSLAPIS Konkretūs planai, kainos, sava CTA ⭐ tik iš reklamos

Strategija: skirtingas vartotojo etapas → skirtingas puslapis.

Trivian content — paleisti 3 kanalai, dirba lygiagrečiai

📝 Blog 5 įrašai / ketvirtis · tikslas: 2/mėn

SEO + pardavimų medžiaga

📱 Social media Facebook + LinkedIn · 1 post/sav.

Fokusas Q1: reguliarumas, Trivian pristatymas

✉️ Newsletter Q1: sukurta visa infrastruktūra

Mailerlite · welcome email · popup · asmeniniai kvietimai

Q2: blog 2+/mėn, newsletter — pirmieji prenumeratoriai, social — pradedam matuoti engagement.

E-lab — toliau generuojam leadus

E-lab matavimo sistema atsinaujins Q2 — pradėsim matuoti ne tik leadų skaičių, bet ir jų vertę pipeline'e.

Q2 prioritetai

Q2: sukuriam matavimo sistemą

Šiandien turim paleistų kanalų, bet matavimas fragmentuotas. Q2 fokusas — sutvarkyti, ką ir kaip matuojam.

Pardavimai: apžvalga

Q1 2026 rezultatai, aktyvūs procesai ir artimiausių mėnesių planai.

Q1 2026

Pardavimų rezultatai

Projektų apžvalga

Projektų apžvalga

Daugiau nei 150h

Pagrindiniai klientai

50–150h ir mažiau

Vidutiniai ir mažesni

• Rubisolis — 133h — Mirae paleidimas + nauja support sutartis.
• Autonova — 58h — sunkiai juda. Tiekėjai nestabilūs, prekių per daug, servas silpnas.
• Jaukurai — 41h
• KPanorama — 32h
• Sangaida — 19h
• Open24 — 16h — smarkiai sumažėjęs valandų skaičius.
• Skorpionas — 1h
• Heliopolis — 0.25h — pagaliau pasirašėm sutartį. Pradėti darbai ant Trivian.

Imperija — data leak

• Kas atsitiko Saugumo incidentas — duomenų nutekėjimas. Vyksta tyrimas.
• Ką pakeitėm Permigravo į mūsų serverį. Atlikti skenavimiai, 2FA ir t.t. Atlikti pakeitimai.
• Fokusas Kliento fokusas į saugumą — aukšto prioriteto.

Toliau

Q2 prioritetai