Mājaslapas palaišanas rēķins pasaka, cik maksāja to uzbūvēt. Tas vēl nepasaka, cik uzņēmumam vajadzēs, lai pēc gada joprojām darbotos pieteikumu forma, klienti redzētu aktuālo informāciju un komanda spētu atjaunot vietni pēc neveiksmīga labojuma. Pirmajam gadam vajag atsevišķu budžetu, kurā redzama gan naudas plūsma, gan cilvēku darbs. Šeit aprakstīta budžeta sastādīšanas metode, ko var izmantot vienkāršai uzņēmuma lapai un pielāgot vietnei ar rezervācijām, vairākām valodām vai sistēmu savienojumiem. Summas tālāk ir tikai ilustratīvas.
1. Nosakiet, kam vietnē jādarbojas visu gadu
Uzskaitiet ne tikai lapas, bet arī klienta darbības. Piemēram, klients atrod pakalpojumu, pārbauda darba laiku, aizpilda pieteikumu un saņem apliecinājumu. Darbinieks tikmēr saņem pieteikumu, nolasa vajadzīgos laukus un zina, kam tas jāapstrādā. Abas ķēdes daļas ir uzturēšanas tvērumā, ja bez kādas no tām uzņēmums nespēj izpildīt solīto. Ar formulējumu “vietne ir pieejama” vien nepietiek, jo sākumlapa var atvērties arī tad, kad pieteikumi vairs nenonāk pie darbiniekiem.
Katram ceļam norādiet atbildīgo, pārbaudes veidu un pieļaujamo pārtraukumu. Ja rezervāciju kalendārs ir galvenais pasūtījumu kanāls, tam būs citāda prioritāte nekā vecam jaunumu arhīvam. Pārbaudiet arī mazāk redzamas atkarības: uzņēmuma pastkasti, automātisko paziņojumu piegādi, failu glabātuvi un piekļuvi domēnam. Salīdzinot uzturēšanas piedāvājumus, turiet šo sarakstu blakus. Tad varēsiet redzēt, kuram piedāvājumam katrs darbs patiešām ir cenā un par ko uzņēmumam būs jāvienojas atsevišķi.
2. Sadaliet izdevumus trīs grupās
Fiksētās izmaksas atkārtojas pēc zināmas likmes vai līguma. Piemēri ir ikmēneša hostings, ikgadējs domēna pagarinājums vai atbalsta abonements. Mainīgās izmaksas ir atkarīgas no patēriņa vai darba daudzuma: nosūtīto ziņu skaita, papildu glabāšanas vai stundām ārpus saskaņotā apjoma. Vienreizējās izmaksas ir konkrēti darbi, kurus budžetā ieplāno noteiktā mēnesī, piemēram, datu pārnešana, novecojušas veidnes nomaiņa vai atjaunošanas izmēģinājums pēc nodošanas.
Vienu pakalpojumu var būt nepieciešams sadalīt divās rindās. Ja pakalpojuma plānā ir mēneša maksa un papildu maksa par pārsniegumu, pamatsumma pieder pie fiksētā, bet pārsniegums pie mainīgā. Atsevišķi ierakstiet arī uzsākšanas maksu, ja tāda ir paredzēta līgumā. Budžetā atzīmējiet, vai cena ietver nodokļus, kādā valūtā rēķinu izraksta un kurš pārbauda aprēķinu. Ja summa nav zināma, norādiet pieņēmumu un termiņu tā precizēšanai. Tukša šūna nedrīkst izskatīties pēc apstiprinātas nulles.
3. Savāciet līgumus un atjaunošanas datumus
Izveidojiet sarakstu, kur katrai pozīcijai ir piegādātājs, līguma īpašnieks, konta turētājs, nākamais rēķina datums un lēmuma termiņš. Rēķina un lēmuma datums var atšķirties: par abonementa maiņu var būt jāizlemj pirms automātiskās pagarināšanas. Ja izstrādes laikā kādu licenci iegādājās ārpakalpojuma sniedzējs, noskaidrojiet, kas notiek, ja sadarbība beidzas. Tas attiecas arī uz maksājumu metodi, rēķinu saņemšanu un administratora piekļuvi.
Turiet dokumentus uzņēmumam pieejamā vietā un budžetā iekļaujiet saiti uz līgumu vai rēķinu, nevis paroli. Pierakstiet, kā paziņojumi par termiņiem sasniedz aizvietotāju atvaļinājuma laikā. Pirmajā mēnesī salīdziniet nodoto sarakstu ar faktiskajiem kontiem un maksājumiem. Ja atrodat divas licences vienam un tam pašam darbam, pirms atteikšanās noskaidrojiet, kuru izmanto produkcijā un vai pastāv datu eksporta iespēja. Šāda pārbaude ietaupa ne tikai abonēšanas izmaksas: tā mazina iespēju nejauši atslēgt darbam svarīgu funkciju.
Pārņemot darbu no izstrādes komandas, izspēlējiet vienu praktisku situāciju. Cilvēkam ar uzņēmuma piešķirtu piekļuvi jāspēj atrast licences termiņu, pārbaudīt pēdējo rēķinu un noskaidrot, kam jāpiesaka izmaiņas. Ja viņš var tikai pārsūtīt jautājumu iepriekšējam izstrādātājam, informācijas nodošana vēl nav pabeigta. Īpaši pārbaudiet domēna reģistrētāja un hostinga konta nošķīrumu. Pakalpojumus var nodrošināt dažādi uzņēmumi, un piekļuve vienam kontam parasti nav piekļuve otram. Budžeta kalendārā atzīmējiet arī brīdi, kad pārbaudīsiet, vai šīs piekļuves pēc darbinieku maiņas joprojām ir derīgas.
4. Pārbaudiet, kas ietilpst hostingā
Uzņēmumam noder detalizēts apraksts par to, ko sedz hostings: serveri, datu pārsūtīšanu, rezerves kopijas, testa vidi, uzraudzību un tehnisko atbalstu. Nepieņemiet, ka visas šīs pozīcijas ir iekļautas. Noskaidrojiet, kā piegādātājs rīkojas, sasniedzot krātuves vai datplūsmas robežu, kā arī to, cik ātri iespējams pāriet uz citu plānu. Pārbaudiet, vai rēķinā atsevišķi parādās e-pasta vai failu glabāšanas pakalpojumi.
Salīdzinot divus plānus, apskatiet arī darba apjomu, ko nāksies segt pašiem. Lētāks rēķins var nozīmēt, ka kādam uzņēmumā regulāri jāuzrauga resursi un jāizpilda atjaunošanas darbi. Dārgāks plāns savukārt nepalīdz, ja līgumā nav skaidrs, kas pārbaudīs pieteikumu formu pēc kļūmes. Ja plānots sezonas reklāmas vilnis, pajautājiet, kā pieaugums tiks mērīts un kā noteiks pārsnieguma cenu. Izdevumu prognozē atsevišķi ierakstiet pamata patēriņu un mēnesi, kad gaidāms lielāks pieprasījums. Tādējādi komanda var laikus salīdzināt lētāku optimizāciju ar resursu palielināšanu.
5. Licencēm pārbaudiet pagarinājuma nosacījumus
Izmantojiet vietnē faktiski aktīvo tēmu, spraudņu un ārējo rīku sarakstu. Pie katra ieraksta norādiet licences izmantošanas vietu un kas notiek, kad beidzas termiņš. Dažos gadījumos beidzas atbalsts vai atjauninājumu saņemšana; citos mainās pati pakalpojuma pieejamība. Šo atšķirību nevar noteikt pēc viena vispārīga noteikuma. Pārbaudiet piegādātāja aktuālos nosacījumus un savu līgumu.
Vienam uzņēmumam var būt vairākas vietnes, atsevišķa testa vide un viena licence ar ierobežotu aktivizāciju skaitu. Ja testa videi jāiegādājas atsevišķa licence, tās izmaksas nedrīkst pazust aiz vispārīgas rindas “testēšana”. Pārbaudiet arī, vai sākuma atlaide attiecas uz nākamo periodu, vai vajadzīgi atsevišķi lietotāju konti un kas saglabā piekļuvi, mainoties sadarbības partnerim. Ja kāds rīks šķiet lieks, vispirms izpētiet tā ietekmi uz veidnēm, datu eksportu vai sūtījumiem. Izņemšanu plānojiet kā nelielu pārbaudāmu darbu ar atgriešanās iespēju, ja atklājas slēpta atkarība.
6. Aprēķiniet atjauninājumu darbu, ne tikai licences
WordPress kodola, tēmas un spraudņu atjaunināšana ir darbība, kurai jāparedz laiks. Vienkāršā vietnē pietiks ar īsu pārbaudi, bet vietnei ar maksājumiem, daudzvalodu saturu vai individuāliem blokiem var vajadzēt pārbaudīt vairākus ceļus. Pirms izmaiņām nosakiet, vai vajadzīga testa vide, kā iegūst atjaunošanas punktu un kas apstiprina rezultātu. Pēc izmaiņām apskatiet svarīgākās lapas, formu, e-pasta piegādi un attiecīgās integrācijas.
Budžetā atdaliet regulāro pārbaudi no kļūdas labošanas. Līgumā var būt iekļauta atjauninājuma uzlikšana, bet par nesaderīga pielāgojuma pārveidošanu var būt atsevišķa maksa. Noder konkrēts piemērs, ko izrunāt ar piegādātāju: “Pēc atjauninājuma pieteikuma forma vairs nesūta ziņu. Kas atjauno iepriekšējo stāvokli un kas maksā par cēloņa labošanu?” Vienojieties par pārbaudes pierādījumu, piemēram, ierakstu ar izmaiņu datumu, pārbaudītajām darbībām un atbildīgo. Bez šādas atzīmes pēc vairākiem mēnešiem būs grūti saprast, vai problēma sākās pēc konkrēta atjauninājuma.
7. Ieplānojiet atjaunošanas izmēģinājumu
Paziņojums “rezerves kopija izveidota” neparāda, vai vietni iespējams atjaunot. WordPress administrēšanas rokasgrāmata skaidro, ka tipiskai WordPress vietnei pilnai atjaunošanai vajag gan failus, gan datubāzi. Uzņēmumam vēl jāzina, kur kopija atrodas, kurš tai var piekļūt un kā rīkoties, ja pazūd piekļuve primārajam kontam.
Ieplānojiet izmēģinājumu atsevišķā vidē un pārbaudiet tajā konkrētas lietas: vietne atveras, var pieslēgties, attēli nav pazuduši un jaunākā saglabātā informācija ir pieejama. Testā nepieļaujiet ziņu izsūtīšanu reāliem klientiem. Fiksējiet, cik ilgi faktiski aizņēma atjaunošana un līdz kuram brīdim dati bija atgūstami. Ja uzņēmums pieļauj tikai īsu pārtraukumu vai mazu datu zudumu, salīdziniet to ar izmēģinājuma rezultātu. Budžetā atsevišķi lieciet kopiju glabāšanu, izmēģinājumu un konstatēto trūkumu novēršanu, jo tās ir atšķirīgas izmaksas ar atšķirīgu ieguvumu.
Pirmajā izmēģinājumā var izrādīties, ka trūkst ārēja pakalpojuma iestatījumu vai dokumentācijas. Piemēram, atjaunotajā lapā pieteikuma forma ir redzama, bet tās savienojums ar nosūtīšanas pakalpojumu nav atjaunots. Pierakstiet, kas jāpārbauda ārpus pašas WordPress vietnes, un norādiet, kura komanda kontrolē attiecīgos kontus. Pirms testēšanas izdomājiet arī drošu aizstāšanas adresi un pārliecinieties, ka testu var apturēt. Pēc izmēģinājuma sagatavojiet īsu atskaiti: izvēlētā kopija, pārbaudītās darbības, neatjaunotie elementi un labojumu īpašnieks. Šis pieraksts palīdz salīdzināt atkārtotu izmēģinājumu pēc būtiskām vietnes vai piegādātāja izmaiņām.
8. Pārbaudiet integrācijas no sākuma līdz galam
Pieteikums var būt saglabājies vietnē, bet ne CRM; ziņa var būt nosūtīta, bet nenonākt paredzētajā pastkastē. Uzturēšanas budžetā jābūt vietai arī šādu plūsmu pārbaudei. Izvēlieties vienu testa pieteikumu, nosakiet atpazīstamu testa pazīmi un salīdziniet rezultātu avotā, saņēmēja sistēmā un paziņojumā. Pēc testa dzēsiet vai atzīmējiet testa ierakstu, lai tas neiekļūtu uzņēmuma klientu statistikā.
Pierakstiet, ko darīt, ja ārējais pakalpojums nav sasniedzams, mainās lauka formāts vai beidzas autorizācija. Ja kļūdas laikā saglabātais pieteikums tiek nosūtīts vēlreiz, pārbaudiet, vai nerodas dublikāts. Lauku atbildību var noteikt ar datu lauku karti. Uzturēšanas līgumā precizējiet, kura puse reaģē uz paziņojumu, kādi labojumi ir iekļauti un kuram jāpiesaka piegādātāja atbalsts. Iespējams, vienkārša periodiska pārbaude konkrētai plūsmai ir lietderīgāka nekā vēl viens vispārīgs uzraudzības rīks bez noteikta atbildīgā.
9. Atvēliet laiku satura un mobilās pieredzes pārbaudei
Uzturēšana ietver arī informācijas pareizību. Izveidojiet sarakstu ar lapām, kurās nepareiza informācija rada tūlītēju problēmu: darba laiki, adreses, pieteikuma soļi, noteikumi, pieejamās valodas un pakalpojumu apraksti. Pierakstiet, kurš pārbauda faktus, kurš veic izmaiņas un kā tās tiek apstiprinātas. Ja lapai ir vairākas valodas, vienojieties, kura persona pārbauda, ka vienas valodas labojums atspoguļots arī pārējās vajadzīgajās versijās.
Pēc izmaiņām izpildiet galveno klienta darbību tālrunī, ne tikai atveriet sākumlapu datorā. Lēni attēli, pārklājošas pogas vai neredzams kļūdas paziņojums var atstāt darījumu nepabeigtu. Par mērījumu secību skatiet mobilās ātrdarbības ceļvedi. Budžetā paredziet laiku satura īpašniekam, redaktoram un pārbaudei. Ja šie darbi ir iekšēji, tos var uzskaitīt stundās atsevišķi no naudas izdevumiem. Tas palīdz izvairīties no situācijas, kad uzturēšana formāli ir pasūtīta, bet neviens nevar pateikt, kas jālabo.
10. Uzzīmējiet divpadsmit mēnešu naudas plūsmu
Rindās ierakstiet izmaksu veidus, bet kolonnās divpadsmit mēnešus no vietnes palaišanas. Rēķinu plānojiet tajā mēnesī, kad tas būs jāmaksā. Gada licences summu gada pārskatā var dalīt ar divpadsmit, tomēr naudas plūsmas tabulā viss maksājums paliek faktiskajā mēnesī. Ja vienā mēnesī sakrīt domēna atjaunošana, licences un uzraudzības darbi, vadītājs to redz pirms rēķinu pienākšanas.
Pievienojiet kolonnas “plāns”, “faktiski” un “starpības iemesls”, lai budžets palīdzētu pieņemt lēmumus arī pēc palaišanas. Rindas īpašniekam jāprot paskaidrot, kāpēc izmaksas mainījās: patēriņa kāpums, jauns darbs, nepareizs pieņēmums vai rēķina pārcelšana. Saistību ierakstiet arī tad, ja rēķins vēl nav saņemts. Atsevišķi atzīmējiet, ko var atlikt un kas nepieciešams darbības nepārtrauktībai. Ja plāns jāsamazina, uzņēmums tādējādi redz, vai atliek uzlabojumu vai atsakās no darba, kas vajadzīgs, lai svarīga funkcija turpinātu darboties.
Piemēram, ja domēna rēķins pienāk trešajā mēnesī, licences septītajā, bet integrācijas pārbaude plānota devītajā, attēlojiet tos kā trīs atsevišķus naudas izdevumus. Kad darbu apstiprina agrāk, pievienojiet arī saistības datumu. Varat izveidot vienkāršu atzīmi par to, vai maksājums ir neizbēgams, apspriežams vai vēl nav apstiprināts. Tas īpaši noder, ja uzturēšanu finansē vairākas nodaļas. Viena redz kopējo summu, bet otra plāno savas komandas stundas. Tādā gadījumā uzturiet kopīgu atsauci uz vienu budžeta rindu, lai viens un tas pats darbs netiktu apmaksāts vai uzskaitīts divreiz.
11. Aprēķiniet bāzes un noslodzes scenāriju
Sāciet ar pašreizējiem rēķiniem un zināmo darba apjomu. Bāzes scenārijā iekļaujiet regulārās maksas, paredzamo mainīgo patēriņu un ieplānotos vienreizējos darbus. Noslodzes scenārijā mainiet tikai pamatotus pieņēmumus, piemēram, sezonālu pieteikumu kāpumu, papildu ziņu apjomu vai vajadzību pēc ilgākas pārbaudes. Katram pieņēmumam norādiet, no kurienes tas nāk un kā to pārbaudīsiet, kad būs faktiskie dati.
Ja vietne ir jauna un datu vēl nav, izmantojiet nelielu diapazonu un vienojieties, kad to aizstāsiet ar novērojumiem. Svarīgs ir brīdis, kad izmaksu pieaugums maina lēmumu. Ja pakalpojuma limits tiks pārsniegts, vai labāk pāriet uz citu plānu vai samazināt nevajadzīgos sūtījumus? Ja atbalsta stundas regulāri pārsniedz līgumā paredzēto, vai jāmaina uzturēšanas apjoms vai jānovērš atkārtots cēlonis? Scenārijs noder tikai tad, ja tam piesaistīta darbība, datums un cilvēks, kas pieņems lēmumu.
12. Rezervi piesaistiet konkrētiem riskiem
Rezerves budžets ir apstiprināta iespēja rīkoties, ja notiek kaut kas ārpus plānotās ikdienas. Sarakstā var būt bojāta formas piegāde, nesaderīgs atjauninājums, neplānota licences nomaiņa vai papildu darbs pēc atjaunošanas. Pie katra riska pierakstiet iespējamo darbību, tās aptuveno apjomu un cilvēku, kas drīkst izdevumus apstiprināt. Ja risks jau ir paredzēts kā noteikts vienreizējs darbs, nelieciet to rezervē otrreiz.
Vienojieties, kā ārpus darba laika rīkoties ar incidentu, kas tieši ietekmē klientus. Var būt vajadzīgs atšķirīgs apstiprināšanas slieksnis steidzamai darbībai un plānotam uzlabojumam. Rezerves summu pārskatiet, kad mainās vietnes nozīme uzņēmumam. Piemēram, pēc tiešsaistes rezervāciju ieviešanas manuālās apstrādes laiks un klientu informēšana kļūmes gadījumā var būt svarīgāka nekā agrāk. Ja ceturksnī rezerve nav izmantota, tas vēl nenozīmē, ka tā jāiztērē. Pārbaudiet, vai pieņēmumi joprojām atbilst riskam.
13. Ilustratīvs piemērs: viena uzņēmuma pirmā gada plāns
Šie ir izdomāti skaitļi aprēķina demonstrēšanai. Tie nav CANIMAPS DIGITAL piedāvājums, tirgus vidējā cena vai reāla klienta rezultāts. Pieņemsim, ka uzņēmums maksā 45 EUR mēnesī par hostingu un 95 EUR mēnesī par regulāru atbalstu. Divpadsmit mēnešos tie kopā ir 1680 EUR. Domēns maksā 24 EUR, licences 156 EUR gadā. Tātad fiksētā daļa ir 1860 EUR.
Mainīgais patēriņš bāzes scenārijā ir 20 EUR mēnesī jeb 240 EUR gadā. Atjaunošanas izmēģinājumam paredz 180 EUR, bet vienreizējai integrācijas pārbaudei 220 EUR. Bāzes plāns kopā ir 2500 EUR. Ja noslodzes scenārijā sūtījumi un glabāšana izmaksā vēl 120 EUR, tas sasniedz 2620 EUR. Uzņēmums var atsevišķi apstiprināt 350 EUR rezervi incidentiem; tad bāzes finansējuma ietvars ir 2850 EUR. Šis piemērs parāda, kā saglabāt atsevišķus pieņēmumus. Tas neparedz nodokļus, un konkrētā budžetā tie jāuzskaita konsekventi atbilstoši uzņēmuma vajadzībām.
Izmantojot šos piemēra skaitļus, regulārais bāzes maksājums ar mainīgo daļu būtu 160 EUR mēnesī. Mēnesī, kurā jāmaksā gada licence, tas pieaugtu līdz 316 EUR, ja citi darbi tajā nenotiek. Ja tajā pašā mēnesī ieplāno arī atjaunošanas izmēģinājumu, naudas vajadzība sasniedz 496 EUR. Tātad vienāds gada kopsummas sadalījums pa mēnešiem neatklātu šo atšķirību. Rezerves finansējums savukārt nav ikmēneša rēķins: tas tiek izmantots tikai tad, kad iestājas apstiprinātais nosacījums. Pierakstiet to atsevišķi, lai varētu atšķirt ikdienas darbības izmaksas no pieejamā finansējuma iespējamai kļūmei.
14. Vienojieties par atbildību un darba pieņemšanu
Pie katras budžeta rindas norādiet cilvēku, kurš spēj pasūtīt, pārbaudīt vai apturēt attiecīgo darbu. Piegādātājs var uzturēt serveri, bet uzņēmuma darbinieks apstiprina pakalpojumu informāciju un saņem klientu pieteikumus. Nosakiet arī aizvietotāju. Ja par kļūmi uzzina tikai viens cilvēks un viņš nav sasniedzams, reakcijas laiks praksē būs ilgāks par dokumentā rakstīto.
Definējiet pieņemšanas kritēriju: “Pieteikums no tālruņa parādās CRM un testa ziņa nonāk pārbaudes adresē” pasaka vairāk nekā “forma pārbaudīta”. Atbalsta piedāvājumā izšķiriet reakcijas laiku no atrisināšanas laika. Atbilde stundas laikā nenozīmē, ka bojājums tajā pašā stundā tiks novērsts. Pierakstiet, kā tiks paziņots par pagaidu risinājumu un kad uzņēmums var apstiprināt papildu izmaksas. Ceturkšņa pārskatā runājiet par to, kas praksē prasīja vairāk darba un kurš process jāpārveido, nevis tikai par to, vai iztērēta paredzētā summa.
15. Pārskatiet plānu ik ceturksni un pirms pagarinājuma
Pirmajā ceturksnī salīdziniet budžetu ar rēķiniem un darba pierakstiem. Pārbaudiet, vai faktiskā uzturēšana notiek paredzētajā ritmā un vai atjaunošanas izmēģinājums nav atlikts. Otrajā pārskatā var apskatīt integrāciju kļūdu skaitu, satura labojumu apjomu un licences, kuru atjaunošanas lēmums tuvojas. Izmantojiet tikai novērotos datus: atsevišķa veiksmīga pārbaude vēl neparāda visu gada darbību.
Pirms pagarinājuma salīdziniet izmaksas ar klientam svarīgajām darbībām. Ja izdevumi pieauguši, meklējiet cēloni: vairāk klientu, lielāki faili, atkārtotas problēmas vai apjoms, kas nepamatoti paplašināts. Ja nepieciešama pāreja pie cita piegādātāja, paredziet laiku piekļuvju nodošanai, datu eksportam, testa atjaunošanai un informēšanai. Lai saglabātu pārskatāmību, jaunajā gada plānā atzīmējiet, kuras izmaiņas kļūst par regulāru pienākumu, kuras paliek atsevišķi projekti un kuri riski vēl nav atrisināti.
16. Ko paņemt līdzi uz uzturēšanas sarunu
Sagatavojiet vienas lapas pārskatu: galvenie klienta ceļi, piegādātāju un licenču saraksts, pēdējie rēķini, termiņi, atjaunošanas pārbaudes rezultāts un neatrisinātie jautājumi. Ja kādu dokumentu vai piekļuvi vēl nevarat atrast, norādiet to tieši. Tad pakalpojuma sniedzējs var skaidri atdalīt esošo izmaksu uzskaiti no darba, kas jāveic, lai noskaidrotu faktisko situāciju. Budžeta tabulai pievienojiet nākamā pārskata datumu, lai sākotnējais novērtējums kļūtu par regulāru vadības rīku.
Ja pārskatāt jau strādājošu lapu, sāciet ar vienu pārbaudi, kas vislabāk parāda uzņēmuma risku: testa pieteikumu, licences pārbaudi vai atjaunošanas mēģinājumu. Ja vietne vēl nav palaista, vienojieties par šiem soļiem nodošanas laikā. CANIMAPS DIGITAL var pārrunāt jūsu vietnes uzturēšanas vajadzības. Konkrētais darbu apjoms un ārējie pakalpojumi jāizvērtē pēc faktiskās vietnes un vienošanās; pieteikums sarunai pats par sevi nav pasūtījums.
Parādiet arī vienu ierakstu no esošā budžeta, kuru grūti pārbaudīt. Piemēram, ja rindā “tehniskais atbalsts” ir tikai gada summa, lūdziet to sasaistīt ar paredzētajām pārbaudēm, darbu biežumu un rīcību kļūmes gadījumā. Tikai tad varēsiet salīdzināt divus piedāvājumus ar līdzīgu kopsummu un saprast, kurš sedz jūsu uzņēmuma prioritātes. Pirms vienošanās nosakiet, kur glabāsies izpildes pieraksti un kurš tos pārskatīs.