NT kainoraštis svetainėje: pilnas įgyvendinimo vadovas

NT projekto kainoraštis svetainėje privalo rodyti šiuos laukus: buto tipas, aukštas, plotas (m²), kaina už m², bendra kaina, PVM statusas, prieinamumo būsena (galimas / rezervuotas / parduotas) ir rezervacijos nuoroda su depozito sąlygomis. Tai minimumas, kurį galite nukopijuoti tiesiai į RFP arba CMS laukų specifikaciją.

Papildomai rekomenduojami laukai:

• Buto plano nuotrauka arba PDF
• Unikalus buto numeris / identifikatorius (unit_id)
• Paskutinio atnaujinimo data
• Kainos galiojimo pastaba (pvz., „Kaina galioja iki 2026-08-01“)

Profesionalus patarimas: Šį sąrašą įklijuokite į pirmą RFP skyrių kaip „privalomų laukų sąrašą“ — tiekėjas iš karto supras, ką reikia pristatyti.

Pagrindinės išvados

Kainoraštis NT projekto svetainėje veikia kaip pardavimo įrankis tik tada, kai jis tikslus, teisingai struktūrizuotas ir reguliariai atnaujinamas pagal aiškų procesą.

Turinys

• Ką rodyti kiekvienoje kainų lentelės eilutėje?
• Kaip sukurti CMS duomenų modelį kainoraščiui?
• Kaip išdėstyti kainoraštį, kad jis parduotų?
• Ką privalote nurodyti viešai pagal Lietuvos reikalavimus?
• Kaip pridėti struktūrizuotus duomenis prie kainoraščio?
• Kas atsakingas už kainų atnaujinimą ir kaip tai organizuoti?
• Ką agentūra turi pristatyti ir kiek tai kainuoja Lietuvoje?
• Greiti šablonai: CSV antraštės, copy ir JSON pavyzdys
• Kaip užtikrinti kainoraščio prieinamumą visiems naudotojams?
• Kaip teisingai rodyti kainas pagal lietuviškas konvencijas?
• Kodėl aiškus kainoraštis sutrumpina pardavimo ciklą
• DMNT NT kainoraščio paketas jūsų projektui
• Šaltiniai
• Dažniausiai užduodami klausimai

Ką rodyti kiekvienoje kainų lentelės eilutėje?

Kiekvienas laukas turi ne tik informatyvią, bet ir teisinę funkciją. Neteisingai suformatuota kaina arba praleistas PVM užrašas gali sukelti ginčus su pirkėjais.

Rezervacijos mygtuko mikrotekstas: „Rezervuoti — depozitas 2 000 €“. Šis formatas aiškiai nurodo pirkėjui finansinį įsipareigojimą prieš paspaudžiant.

Eksporto antraštės (CSV / JSON): unit_id, unit_number, floor, type, area_m2, price, price_per_m2, price_currency, vat_included, availability, plan_url, price_valid_from.

Kainos pagrindimas pagal CPVA metodiką turi remtis objektine sąmata, lokalinėmis sąmatomis arba anksčiau atliktų panašių darbų įkainiais. Mikrotekste pakanka trumpos nuorodos: „Kaina pagrįsta objektine sąmata.“

Kaip sukurti CMS duomenų modelį kainoraščiui?

NT svetainės veikia kaip e-parduotuvės: reikia duomenų bazės, eksporto funkcijų ir redaktorių sąsajos. Struktūra: objektas → butas → kainos variantai.

Redaktoriaus sąsajai būtinos funkcijos:

• Versijų peržiūra (galimybė palyginti dabartinę ir ankstesnę kainą)
• Automatinis įspėjimas, kai kaina nebuvo atnaujinta ilgiau nei 30 dienų
• Staging aplinka prieš publikavimą

Profesionalus patarimas: Naudokite price_version_id kaip UUID — tai leidžia tiksliai atsekti, kuri kainų versija buvo aktyvi konkrečią dieną, jei kyla ginčas su pirkėju.

Kaip išdėstyti kainoraštį, kad jis parduotų?

Filtrai ir rūšiavimas yra pirmasis konversijos veiksnys. Rekomenduojami filtrai: kainų intervalas, kambarių skaičius, aukštas, prieinamumo statusas. Rūšiavimas: kaina (didėjančia / mažėjančia tvarka), naujausiai pridėti, „geriausias pasiūlymas“.

Dizaino žymės (angl. badges) veikia, kai yra kontrastas. Žymė „Paskutinis“ raudona spalva ant rezervuoto fono, „Akcija“ geltona, „Geriausias“ žalia. Svarbu: žymės turi veikti kartu su filtrais, t. y. filtruojant pagal statusą žymė išlieka matoma.

Mobiliuosiuose įrenginiuose lentelės vaizdas neveikia. Naudokite kortelių išdėstymą: pagrindinė informacija (tipas, plotas, kaina) matoma iš karto, o detalės atsidaro modaliniame lange. Plano PDF atidaromas paspaudimu ant kortelės.

Aiškus sutaupymo rodymas ir mėnesinio mokėjimo ekvivalentai gerina konversijas. A/B testavimo idėjos: bendra kaina prieš mėnesinę įmoką kaip pagrindinį skaičių. KPI: paspaudimų ant „Rezervuoti“ rodiklis ir kontaktų formos užpildymai.

Profesionalus patarimas: Rodykite mėnesinę įmoką šalia bendros kainos — daugeliui pirkėjų mėnesio įmoka atrodo prieinamiau nei bendra kaina, nors tai tas pats butas.

Ką privalote nurodyti viešai pagal Lietuvos reikalavimus?

Teisinis skaidrumas apsaugo ir pirkėją, ir vystytojus. Kontrolinis sąrašas:

• Kainos galiojimo data (pvz., „Kaina galioja iki 2026-08-01“)
• PVM statusas prie kiekvienos kainos
• Rezervacijos sąlygos: depozito dydis, grąžinimo tvarka, terminas
• Kainos pagrindimo šaltinis (objektinė sąmata arba tiekėjų pasiūlymai)
• Nuoroda į duomenų tvarkymo politiką prie rezervacijos formos

Pavyzdinės formuluotės mikrotekstui:

Prie rezervacijos formos būtina trumpa privatumo pastaba: „Jūsų duomenys tvarkomi pagal mūsų privatumo politiką ir naudojami tik rezervacijos tikslais.“ Mokėjimo duomenys turi būti tvarkomi per sertifikuotą mokėjimų tarpininką, ne saugomi svetainės duomenų bazėje.

Kaip pridėti struktūrizuotus duomenis prie kainoraščio?

JSON-LD su Offer ir priceSpecification padeda paieškos sistemoms suprasti pasiūlymus ir gali pagerinti matomumą per turtingus fragmentus (rich snippets).

Kiekvienas parduodamas vienetas gauna atskirą Offer objektą su šiais laukais:

• @type: „Offer“
• name: buto pavadinimas / ID
• price: skaitinė reikšmė
• priceCurrency: „EUR“
• priceValidUntil: data ISO formatu
• valueAddedTaxIncluded: true / false
• availability: schema.org būsena (pvz., schema:InStock, schema:SoldOut)
• priceSpecification: objektas su price, priceCurrency, valueAddedTaxIncluded

Kai projekte yra daug vienetų (pvz., 50+ butų), naudokite OfferCatalog kaip apgaubiančią struktūrą. Atskiri Offer objektai tinka mažiems projektams arba kai kiekvienas vienetas turi unikalų aprašymą.

SEO kopijos patarimai: meta pavadinime nurodykite projekto pavadinimą ir miestą. Ištuštėjusius variantus pažymėkite noindex ir nustatykite canonical į pagrindinį kainoraščio puslapį. SEO draugiška NT svetainė reikalauja, kad kiekvienas indeksuojamas variantas turėtų unikalų turinį.

Profesionalus patarimas: Patikrinkite JSON-LD naudodami Google Rich Results Test įrankį prieš publikuodami — klaidos struktūroje neleidžia rich snippets atsirasti paieškos rezultatuose.

Kas atsakingas už kainų atnaujinimą ir kaip tai organizuoti?

Aiškus procesas užtikrina, kad kainoraštis internete niekada neatsiliktų nuo realybės.

1. Pradinis įkėlimas: marketingo komanda parengia CSV, programuotojas importuoja į CMS.
2. Vidaus patikrinimas: projektų vadybininkas patikrina kainų pagrindimą.
3. Teisinė patikra: teisininkas arba finansų atstovas patvirtina PVM formuluotes ir rezervacijos sąlygas.
4. Publikavimas per staging aplinką: pakeitimai pirmiausia matomi vidinėje aplinkoje.
5. Periodiniai atnaujinimai: rekomenduojama kas savaitę arba iš karto po kiekvieno kainos pakeitimo.

Rolės ir SLA:

• Redaktorius (marketingas): įveda pakeitimus, inicijuoja patvirtinimą
• Duomenų atsakingasis (projektų vadybininkas): tikrina kainų atitikimą dokumentams
• Teisininkas / finansų atstovas: galutinis patvirtinimas prieš publikavimą
• Programuotojas: techninis publikavimas, ne vėliau kaip per 24 val. po patvirtinimo

Automatiniai įspėjimai: el. pašto pranešimas, kai kaina nebuvo atnaujinta ilgiau nei 14 dienų, arba kai CSV importas aptinka neatitikimą tarp price_version_id reikšmių.

Ką agentūra turi pristatyti ir kiek tai kainuoja Lietuvoje?

Standartinis NT kainoraščio paketas apima: reikalavimų surinkimą, CMS modelio konfigūravimą, redaktorių sąsają, JSON-LD integraciją, testavimą (QA), CSV importą, apmokymus ir palaikymą bei SLA dokumentą. DMNT svetainių kūrimo paketai suteikia orientacinę informaciją apie kaštų struktūrą.

Kainodaros struktūra: projektinis mokestis už sukūrimą ir mėnesinis abonementas už palaikymą (rekomenduojama 100–300 €/mėn. priklausomai nuo atnaujinimų dažnumo).

RFP kontrolinis sąrašas tiekėjui:

• Privalomų laukų sąrašas (žr. 1 skyrių)
• CSV importo ir eksporto reikalavimai
• JSON-LD Offer / priceSpecification integracija
• Atsakomybės už duomenų tikslumą aprašymas
• SLA: publikavimo terminas po patvirtinimo (pvz., 24 val.)
• Versijų istorija ir rollback galimybė

Greiti šablonai: CSV antraštės, copy ir JSON pavyzdys

CSV antraštės (kopijuokite tiesiai į RFP):

Copy šablonai:

• Rezervacijos mygtukas: „Rezervuoti — depozitas 2 000 €“
• PVM paaiškinimas: „Kaina nurodyta be PVM“
• Kainos galiojimas: „Kaina galioja iki 2026-08-01“
• Parduota žymė: „Parduota — žiūrėti kitus variantus“

Minimalus JSON-LD fragmentas (laukų sąrašas):

@context: schema.org
@type: Offer
name: [unit_number]
price: [price]
priceCurrency: EUR
priceValidUntil: [price_valid_from + 30 dienų]
valueAddedTaxIncluded: false
availability: schema:InStock
priceSpecification:
  @type: PriceSpecification
  price: [price]
  priceCurrency: EUR
  valueAddedTaxIncluded: false

Profesionalus patarimas: CSV faile niekada nenaudokite kablelio kaip dešimtainio skiriko — naudokite tašką (62.40, ne 62,40). Klaidos dėl dešimtainių skirtukų yra dažniausia importo nesėkmės priežastis.

Kaip užtikrinti kainoraščio prieinamumą visiems naudotojams?

Prieinamumas (angl. accessibility) pagal WCAG 2.1 AA standartą yra ne tik gera praktika, bet ir būsimas teisinis reikalavimas ES rinkoje.

Pagrindiniai reikalavimai kainoraščio lentelei:

• Lentelės antraštės (<th>) turi turėti scope atributą, kad ekrano skaitytuvai (pvz., NVDA, VoiceOver) teisingai interpretuotų eilutes ir stulpelius.
• Spalvinės žymės (galimas / rezervuotas / parduotas) negali perteikti informacijos tik spalva. Šalia spalvos būtinas tekstinis žymėjimas arba ikona su aria-label.
• Kontrastas: teksto ir fono kontrastas turi būti ne mažesnis nei 4,5:1 (normaliam tekstui) pagal WCAG 2.1 kriterijų 1.4.3.
• Rezervacijos mygtukas turi turėti aprašomąjį aria-label, pvz., „Rezervuoti butą A-304, 2 kamb., 62 m²“.
• Filtrai ir rūšiavimas turi būti pasiekiami klaviatūra be pelės.

Mobiliajame variante patikrinkite, ar modalinis langas su detalėmis užrakina fokusą (focus trap) ir grąžina jį į kortelę uždarius.

Kaip teisingai rodyti kainas pagal lietuviškas konvencijas?

Lietuvoje galioja aiškios skaitinių duomenų formatavimo taisyklės, kurios skiriasi nuo angliškų.

Kainų formatavimas:

• Dešimtainis skirtukas: kablelis (151 980,00 €, ne 151,980.00 €)
• Tūkstančių grupavimas: tarpas (151 980 €, ne 151.980 €)
• Valiutos simbolis: po skaičiaus su tarpu (151 980 €, ne €151 980)
• Kaina už m²: „2 450 €/m²“ (be tarpo prieš „/“)
• Procentai: „10 %“ (su tarpu tarp skaičiaus ir simbolio)

Datos formatas: „2026 m. rugpjūčio 1 d.“ arba sutrumpintai „2026-08-01“ (ISO 8601 duomenų laukuose). Mėnesių pavadinimai rašomi mažąja raide.

Valiuta visada EUR. Jokio konvertavimo į kitas valiutas be aiškios pastabos, nes tai gali suklaidinti pirkėją dėl galutinės sumos.

Kodėl aiškus kainoraštis sutrumpina pardavimo ciklą

Dažniausia klaida, kurią matome dirbdami su NT projektais: kainoraštis svetainėje atnaujinamas nereguliariai arba rodo kainas be PVM statuso. Pirkėjas skambina, klausia tikrosios kainos, vadybininkas aiškina. Tas pokalbis kainuoja laiko ir pasitikėjimo.

Kai kainoraštis yra tikslus, atnaujinamas pagal aiškų procesą ir rodo visus privalomus laukus, pirkėjas ateina į pokalbį jau apsisprendęs. NT projektų pardavimo greitis tiesiogiai priklauso nuo to, kiek informacijos pirkėjas gauna be papildomų klausimų.

Kitas dažnas pastebėjimas: versijų istorijos nebuvimas. Kai kaina pasikeičia, o rezervacijos sutartyje nurodyta senoji suma, kyla ginčas. change_log laukas ir price_version_id yra ne techninis perteklius, o apsauga nuo tokių situacijų.

Galiausiai, JSON-LD integracija dažnai atidedama „vėlesniam etapui“. Praktiškai tai reiškia, kad ji neįgyvendinama niekada. Struktūrizuoti duomenys turi būti projekto dalis nuo pradžių, nes vėlesnis pridėjimas kainuoja papildomai.

DMNT NT kainoraščio paketas jūsų projektui

Jūsų projekto kainoraštis gali veikti kaip pardavimo įrankis, o ne tik informacinis puslapis. DMNT sukuria NT kainoraščio sprendimus, kurie apima visą procesą: reikalavimų parengimą, CMS konfigūravimą su versijų istorija, CSV importą, JSON-LD integraciją ir SEO paruošimą.

Skirtumas nuo standartinio svetainių kūrimo: dirbame tik su NT projektais, todėl žinome, kokie laukai reikalingi, kaip suformuluoti PVM pastabas ir kaip sukonfigūruoti atnaujinimo procesą, kurį galės valdyti jūsų marketingo komanda be programuotojo pagalbos. Regioninis patyrimas apima projektus visoje Lietuvoje.

Norėdami gauti pasiūlymą, užpildykite kontaktų formą DMNT svetainių kūrimo puslapyje arba atsiųskite RFP su šio straipsnio kontroliniu sąrašu. Atsakome per 1 darbo dieną.

Šaltiniai

• Investicijų projektų rengimo metodika
• Kaip sukurti efektyvų produktų palyginimo puslapį… – Nušauk žinią pirmas

Dažniausiai užduodami klausimai

Kokie laukai privalomi NT kainoraščiui svetainėje?

Privalomi: buto tipas, aukštas, plotas (m²), kaina už m², bendra kaina, PVM statusas, prieinamumo būsena ir rezervacijos nuoroda su depozito sąlygomis.

Kaip teisingai nurodyti PVM prie kainos?

Prie kiekvienos kainos nurodykite aiškiai: „Kaina nurodyta be PVM“ arba „Galutinė kaina su PVM“. Galutinė suma su PVM turi būti pateikta rezervacijos sutartyje.

Ar JSON-LD struktūrizuoti duomenys būtini NT kainoraščiui?

Jie nėra privalomi teisiškai, tačiau Offer ir priceSpecification JSON-LD leidžia paieškos sistemoms rodyti kainas tiesiogiai paieškos rezultatuose, kas gerina matomumą.

Kiek kainuoja NT kainoraščio sprendimas Lietuvoje?

Paprastas kainoraštis su CSV importu kainuoja apytiksliai 800–1 500 €; pilnas sprendimas su rezervacijomis, JSON-LD ir SLA siekia 3 500–7 000 €.

Kaip dažnai reikia atnaujinti kainoraštį svetainėje?

Rekomenduojama atnaujinti kas savaitę arba iš karto po kiekvieno kainos pakeitimo. Automatiniai įspėjimai padeda užtikrinti, kad kainoraštis neatsiliktų nuo realybės ilgiau nei 14 dienų.

Rekomendacija

• UGC ir atsiliepimai NT projektams: praktinis 2026 vadovas
• Leadų kokybė NT projektuose: praktinis žaidimo planas
• Nekilnojamojo turto marketingas 2026 | DMNT
• Nuotraukų optimizavimas SEO: praktinis vadovas NT svetainėms