En samlad arbetsyta som tar bort Excel-kontrollen, gör gruppbiljetterna säljbara och kortar svarstiderna, utan att byta CRM, utan cutover och med första leverans inom veckor.
Säljprocess-dokumentationen och kontrolldokument-genomgången pekar åt samma håll: CRM:ets kärna gör sitt jobb. Det som begränsar kapacitet och marginal är allt som hanteras vid sidan av, i Excel, Gmail, Dropbox och PDF:er.
Lagren byggs som moduler i en och samma arbetsyta, en inloggning, en navigation. Varje modul läser kundens egen data via befintliga API:er, äger sin egen struktur hos oss och ersätter ett specifikt Excel- eller Gmail-moment. Idag är arbetet utspritt över fem ställen: CRM, Gmail, Excel, Dropbox och Sabre. Efter planen är det två: CRM:et för offert och kundportal, arbetsytan för allt annat.
Tio säljare och en kundportal med levande bokningar störs aldrig. Varje lager tas i bruk när det är bättre än det det ersätter.
Första lagret adresserar den uttalade kapacitetsflaskhalsen direkt, inte efter ett plattformsprojekt.
Lagren är fristående och flyttbara. Om CRM-frågan väcks senare tas det beslutet kallt, och allt byggt följer med.
Ambitionen är tydlig: samla datan och arbetet på ett och samma ställe. Vägen dit är spegling av CRM:et i arbetsytan, och den görs klokast nivå för nivå, moment för moment, inte som ett beslut om allt på en gång.
Arbetsytan visar allt: bokningar, fakturor, kunder, expenses, uppdaterat var 5–15 minut plus on-demand. För de få inmatningsmomenten finns djuplänkar som öppnar exakt rätt bokning i CRM:et. Riskfri, kräver ingen medverkan från systemleverantören.
Admins skrivlista i CRM:et är ändlig: flyginfo, biljett- och fakturauppladdning, fakturametadata, statusflaggor, expenses. De moment som görs oftast får skrivväg direkt från arbetsytan, ett i taget, loggat och avstängbart. Då försvinner CRM-hoppen för admin nästan helt.
Arbetsytans kopia blir primär och CRM:et avvecklas. Kräver skriv-paritet för säljarnas hela vardag, kundportalen och sajtens formulär, den dyra delen. Nivå 1+2 bygger ~80% av rampen dit, så optionen är gratis att hålla öppen och beslutet kan tas kallt, senare.
| Arbetsmoment | Idag | Fas 0 | Med skriv-spegling |
|---|---|---|---|
| Kontroll av bokningar | Excel | Arbetsytan | Arbetsytan |
| Flyginfo-inmatning | CRM, fritext | CRM via djuplänk | Arbetsytan |
| Biljett- & fakturauppladdning | CRM | CRM via djuplänk | Arbetsytan |
| Statusflaggor & betalmarkering | CRM | CRM via djuplänk | Arbetsytan |
| Kundnotiser ("faktura klar" m.fl.) | CRM, manuella klick | Påminnelsemotorn | Påminnelsemotorn |
| Gruppbiljetter & allotments | Excel | Excel tills Fas 1 | Arbetsytan |
| Lead-fördelning | Gmail-mappar | Gmail tills Fas 2 | Arbetsytan |
| Offertskapande & kundportal | CRM | CRM | CRM, tills nivå 3 ev. beslutas |
Admin-teamets manuella verifiering är den uttalade flaskhalsen, dokumenterad ner på kolumnnivå i kontrolldokumentet och i videogenomgången. Kontrollcentret speglar bokningsdatan automatiskt, strukturerar det som idag är fritext och flaggar avvikelser istället för att låta människor leta efter dem.
Flygsegment och dagsprogram AI-parsas ur befintlig fritext, med osäkra rader flaggade för manuell bekräftelse i ett enkelt kompletteringsformulär, samma inmatning som görs i Excel idag, fast en gång och strukturerat.
Flygdatan som idag matas manuellt finns redan strukturerad i Sabre (PNR). Read-only-uppslag kan autofylla kontrollcentrets flygsektion, men API-accessen är en avtalsfråga med några veckors ledtid och ligger medvetet utanför kritiska linjen. Beställningen initieras nu, och kopplingen pluggas in när den landar, oavsett vilken fas som då pågår. Allt fungerar utan den.
Gruppbiljetter köps upp till tio månader i förväg med deadlines mot flygbolagen, men säljarna saknar synlighet i säljögonblicket. Konsekvensen är dokumenterad: kunder får marknadsbiljetter medan egna platser står osålda, reas ut eller brinner inne. Detta är fasen med direkt marginalpåverkan.
Svarstid styr hit rate, med Ottos egna ord, och idag fördelas leads genom att mail flyttas mellan Gmail-mappar. En lead-kö med ägarskap, status och svarstidsklocka ger överblicken, och prioriteringen byggs på ett underlag ingen annan har: attributionsdatan vi samlat sedan april, formulärfälten och de historiska konverteringsmönstren per källa, destination och budget.
Telefonleadsen, de varmaste enligt säljteamets egen erfarenhet, får samma behandling: samtal transkriberas (lokal Whisper, ljudet lämnar aldrig EU-miljön) och sammanfattas strukturerat in på lead-kortet, destination, budget, resenärer, nästa steg, istället för att bo i säljarens minne.
I linje med verksamhetens DNA: prioriteringen föreslår, människor säljer. Ingen automatisering av rådgivningen.
Beslutas tillsammans när lagren är i drift och har bevisat sig. Kandidater, alla förberedda av datafundamentet:
Kalendertid, inte arbetstid. Sabre-spåret löper parallellt och påverkar ingen fas.
Att replikera nio moduler på ny stack flyttar fritext-problemet till en ny databas och parkerar de verkliga smärtorna bakom månader av paritetsarbete och cutover-risk. Frågan kan tas senare, från en starkare position.
Skräddarsytt, personlig kontakt och flexibilitet är affären. Allt som byggs tar bort repetitiv administration och förbättrar överblick, säljrollen förstärks, ersätts inte.
Avtalsprocessen får ta sin tid. Fas 0 fungerar fullt ut med AI-parsad fritext plus manuell komplettering, Sabre-uppslag blir en förbättring, inte ett beroende.
Lagren läser kundens data via kundens egna API-åtkomster och äger sin struktur hos oss. Inget beroende av tredje parts kodbas, releasecykler eller goodwill.
Dev Studio-konto på byråns PCC och API-tillägg via er Sabre-kontakt. Lång ledtid, noll brådska i övrigt, därför startas den först.
En person ur admin-teamet som kör kontrollcentret parallellt med Excel under två veckor och säger vad som saknas.
Inför Fas 1: nuvarande gruppbiljett- och allotment-ark, så modellen byggs efter verkligheten och historiken följer med.
Inför Fas 2: vilken leverantör, och finns samtalsinspelning med export? Det avgör vägen för samtalstranskribering, befintlig växel räcker oftast.
| Risk | Nivå | Hantering |
|---|---|---|
| Fritext-parsningens kvalitet | Medel | Osäkra rader flaggas alltid för manuell bekräftelse, aldrig tyst gissning. Piloten mäter precision innan Excel pensioneras. Sabre-uppslag ersätter parsningen för flyg när accessen finns. |
| Sabre-avtalets ledtid eller utfall | Låg | Utanför kritiska linjen per design. Vid nej eller långbänk fortsätter parsning + komplettering, fullt fungerande. |
| Systemleverantörens API:er förändras | Låg | API:erna driver leverantörens egen admin och sajten, de kan inte stängas utan att bryta deras eget system. Accessen går via kundens konto. Daglig synk ger oss dessutom historiken lokalt. |
| Adoption hos admin-teamet | Medel | Pilot side-by-side med Excel, kontrollcentret vinner på meriter eller byggs om tills det gör det. Excel stängs inte av förrän teamet själva släpper det. |
| Scope-glidning mot CRM-byte | Låg | Avgränsningarna i sektion 05 är del av planen. CRM-frågan har en egen beslutspunkt efter Fas 2, inte tidigare. |
Det här är arbetsunderlaget bakom Fas 0, grundat på skarpa anrop mot Catch-API:et. Det visar var varje kolumn i dagens Excel-kontrolldokument kommer ifrån: vad som autofylls, vad som parsas ur fritext och vad som är blockerat tills vi har rätt access. Det här är byggdokumentation, inte kundmaterial.
Varje kolumn klassas efter hur den fylls. Det avgör vad som blir noll handpåläggning, vad som kräver en bekräftelse och vad som väntar på access. Resterande ~30% är dagsprogrammet (blockerat på access), inrikesflyg (delvis manuellt av naturen) och pass/transfer (blir egna fält, lika lite jobb som Excel men på ett ställe).
Hämtas strukturerat från Catch REST-API. Ingen handpåläggning.
Finns som fritext i API:t, AI-parsas till struktur, osäkra rader flaggas.
Räknas fram av oss ur AUTO-data, t.ex. ålder vid avresa, datum-expansion.
Fält vi själva äger och lagrar, admin matar. Fanns bara i Excel förut.
Kräver admin-RPC-token (sessionsbaserad, ej löst) eller webbyrå-access.
Kan inte automatiseras, av verksamhetens natur (t.ex. inrikesflyg utställt på plats).
Dagens Excel-kontrolldokument mappat mot källa och hur det fylls. Sex vyer byggs ovanpå: avgångsmånad, flygkontroll, fakturakontroll, "vem är var när", påminnelser och read-only partnervy.
| Kolumn | Källa | Hur | Fas 0 |
|---|---|---|---|
| 1 · Kundnamn, per avresemånad | AUTO | bookings + persons.namn, månad = DATE(flight departure) | Ja |
| 2 · Status (grön / %) | AUTO EGET | booking.status + payment_status som grund, vår kontroll-checklista ovanpå | Ja |
| 3 · Origin (NO/SE/DK) | AUTO | assignment.channel | Ja |
| 4 · Pass-status | EGET | finns ej i API:t, admin markerar i vår vy. Ev. auto om pass laddas som attachment | Ja* |
| 5 · E-mail (samlad) | AUTO | persons.email + customer.email | Ja |
| 6 · Destinationstaggar | PARSE | titel + offer, lättparsad ur title/program | Delvis |
| 7 · Antal resenärer (pax) | AUTO | bookings.pax / properties.people | Ja |
| 8 · Barn i sällskapet | HÄRLED | persons.dob (100% täckning) → ålder vid avresa: barn 0-11, ungdom 12-15, vuxen 16+ | Ja |
| 9 · Ankomst: flyg intl | AUTO PARSE | flight_information.departure = datum (AUTO), segment i .from = fritext (PARSE) | Ja, flaggat |
| 10 · Hemresa: flyg intl | AUTO PARSE | flight_information.arrival = datum, .to = fritext, arrivalDayAfter-flagga finns | Ja, flaggat |
| 11 · Biljettyp (PNR/grupp/klient) | HÄRLED RPC | e-ticket-attachments = egen PNR. Gruppbiljett kopplas i Fas 1 | Delvis |
| 12 · Inrikesflyg (källa) | MANUELLT PARSE | ofta ej utställt förrän på plats (guide). Det som finns ligger i fritext | Begränsat |
| 13 · Transfers (bokad?) | EGET | kontroll-checkbox vi äger, ev. ledtråd ur expenses (supplier) | Ja* |
| 14 · Faktura Safari (fått?) | AUTO | persons.invoices (number, amount, deadline, paid/remaining, PDF) | Ja |
| 15 · Faktura inrikes/transfer | AUTO MANUELLT | invoices visar fakturan, radsplit safari vs flyg kräver PDF-OCR (Block C) | Delvis |
| 16 · Leverantörsfaktura (expenses) | AUTO | booking_expenses.status (paid/unpaid) per supplier_id | Ja |
| 17 · Dag-för-dag-program | RPC | ej i REST, bor i webbyråns resource-CMS. Kräver RPC-token eller export | Nej |
* Pass och transfer fanns bara i Excel även förut, de blir egna fält hos oss, lika lite jobb men på ett ställe och flaggbara.
Princip: spegla CRM:et som läst referens, äg vår egen struktur ovanpå. Catch är sanning för det operativa (bokning, offert, kund, faktura). Vår data är sanning för det vi tillför (kontroll, parsning, inventory, leads). Vi skriver aldrig tillbaka i Fas 0-1.
booking_id (FK speglad), pass_status, transfer_booked, inrikesflyg_ok, kontroll_klar, kommentar, uppdaterad_av/at.
riktning, from/to-flygplats, tider, flight_no, parse_confidence (0-1), behover_bekraftelse. Ersätts av Sabre när access finns.
dag_nr, datum (härlett avresedatum + dag-1), land, ort, boende, rumstyp, måltid. Kräver RPC-token eller webbyrå-export. Låser upp "vem landar på Zanzibar dag X".
typ, trigger_datum, status, hanterad_av. TBA-flyg = framtida avresa + tomt flygfält. properties.remindDepartureSoon speglas som grund.
Verifierat skarpt mot api.safariresor.se. Läsning funkar med vår nyckel. Skrivning kräver en sessionsbaserad token vi inte har, det är den enda riktiga blockern för skriv-spegling och dagsprogram.
Bas /rest/, auth Bearer med vår långlivade nyckel. Svarar: booking, offer, inquiry + listor. Svarar EJ: trip, resource, program, customer, supplier. Dagsprogram och leverantörer finns alltså inte i REST.
Bas /, action i POST-body, auth via HEADER token: sessionstoken. Vår Bearer ger "Expired token, log out and in", alltså sessionsbaserad och kortlivad. Blocker för skriv-spegling (N2) och dagsprogram. Otto-fråga mot Catch.
| API-fält (GET /rest/booking/id) | → vår användning |
|---|---|
| id, nr, status, payment_status | bookings (speglat) |
| channel (NO/SE/DK) | origin |
| persons[].dob (100%) | ålderskategori (barn/ungdom/vuxen) |
| persons[].invoices[] | fakturakontroll: number, amount, deadline, paid/remaining, PDF |
| properties.remindDepartureSoon | påminnelse-grund (finns redan) |
| flight_information.departure/arrival | ut/hem-datum (AUTO) |
| flight_information.from/to (HTML-fritext) | flygsegment (PARSE, flagga osäkra) |
| attachments[] | e-tickets (= egen PNR-signal), reseunderlag |
| expenses[] | leverantörsstatus: supplier_id, valuta, pris, status |
| offer_resource_manager_url | webbyrå-CMS (baksidan) där dagsprogram bor |
Alla Otto-ägda med lång ledtid mot Catch, Sabre eller webbyrån. Inget av dem stoppar Fas 0, men de avgör hur långt automationsgraden når och när skriv-spegling blir möjlig.
Långlivad token för admin-API:et. Blocker för skriv-spegling (N2) och dagsprogram-läsning. Otto → Catch.
Alternativ väg till resource/dagsprogram om RPC-token dröjer. Otto → webbyrå.
PCC, Dev Studio, egen IATA vs konsolidator. Ej kritiska linjen, autofyller flyg när den landar. Otto → Sabre.
Leverantör + finns inspelningsexport? Avgör vägen för samtalstranskribering. Fas 2. Otto.