Ett förslag på hur arbetet kring CRM:et kan samlas i en arbetsyta, kontroll, lager och leads, byggt ovanpå det som redan finns istället för att byta system. Tänkt som utgångspunkt för en gemensam diskussion, inte ett färdigt beslut.
Säljprocess-dokumentationen och genomgången av kontrolldokumentet pekar åt samma håll: själva CRM:et fungerar. Det som tar tid och är svårt att överblicka är allt som hanteras utanför det, 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 tar sig an det mest tidskrävande momentet direkt, utan att vänta in ett helt plattformsprojekt.
Lagren är fristående och flyttbara. Om CRM-frågan väcks senare tas det beslutet kallt, och allt byggt följer med.
Målbilden är att samla datan och arbetet på ett och samma ställe. Vägen dit är att spegla CRM:et i arbetsytan, och frågan att diskutera är hur långt vi går. Vår utgångspunkt är att ta det nivå för nivå, moment för moment, snarare än 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 Catch.
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, vilket är det mest omfattande steget. Nivå 1+2 bygger ändå ungefär 80% av vägen dit, så optionen kan hållas öppen utan extra kostnad och beslutet tas i lugn och ro längre fram.
| 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 ett av de mest tidskrävande momenten, dokumenterat 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 åtkomsten kräver konto och har en viss ledtid, och ligger medvetet utanför kritiska linjen. Vi driver åtkomsten parallellt och pluggar in kopplingen när den är på plats, 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 ibland marknadsbiljetter medan egna platser står osålda eller säljs till underpris. Det är här påverkan på marginalen är mest direkt.
Svarstiden påverkar hur många som konverterar, och idag fördelas leads genom att mail flyttas mellan Gmail-mappar. En lead-kö med ägarskap, status och svarstidsklocka ger överblicken, och prioriteringen kan bygga på underlag vi redan har: attributionsdatan vi redan samlat, 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 de tidigare lagren är i drift. Möjliga kandidater, alla förberedda av datafundamentet:
En grov skiss, kalendertid och inte arbetstid, tänkt att justeras tillsammans. 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 faktiska problemen bakom månader av paritetsarbete och cutover-risk. Frågan kan tas senare, från ett bättre utgångsläge.
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.
Åtkomsten får ta den tid den tar. 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 Safariresors data via era egna API-åtkomster och äger sin struktur hos oss. Inget beroende av Catchs kodbas, releasecykler eller goodwill.
En kontaktväg in till er Sabre-uppsättning och godkännande att agera. Det tekniska kring åtkomsten driver vi, det enda vi behöver är rätt kontaktperson och klartecken.
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. |
| Catchs API:er förändras | Låg | API:erna driver Catchs egen admin och sajten, de kan inte stängas utan att bryta Catchs eget system. Accessen går via ert 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. |
Vi har gått igenom systemen och arbetssätten runt Safariresor för att förstå var värdet skapas och var tiden tar vägen. Det här är vad vi ser, vilka vägar framåt som finns, och vad vi behöver förstå bättre tillsammans innan något bestäms.
Genomgången av säljprocessen och kontrolldokumentet pekar åt samma håll. Själva CRM:et fungerar, det som tar tid och är svårt att överblicka ligger utanför det, i Excel, Gmail, Dropbox och PDF:er.
Frågan dokumentet vill öppna är hur Safariresor bäst kommer åt det som tar tid. Det finns i grunden två vägar, och de utesluter inte varandra över tid. Här är vad de innebär.
Ersätt nuvarande system med en ny plattform och bygg om det som fungerar idag, offert, kundportal, chatt och fakturor, på ny grund.
Fördel: en enhetlig stack och full kontroll på datamodellen.
Avvägning: månader av paritetsarbete innan något blir bättre, cutover-risk på levande bokningar, och säljarna byter hela sin vardag.
Lägg lager för kontroll, lager och leads ovanpå nuvarande CRM via dess API:er. Ingen migrering, det som fungerar rörs inte.
Fördel: de mest tidskrävande momenten kan tas först, med resultat på veckor.
Avvägning: vissa inmatningsmoment sker kvar i CRM:et tills skriv-spegling byggs, och vi blir beroende av Catchs API:er.
En skiss på hur väg B skulle kunna se ut, inte en låst plan. Arbetet samlas i en arbetsyta med en inloggning, och varje lager läser CRM:ets egen data, äger sin struktur hos oss och ersätter ett specifikt Excel- eller Gmail-moment.
Speglar bokningsdatan, strukturerar fritext och flaggar avvikelser. Ersätter det manuella Excel-kontrollarbetet.
Gruppbiljetter och allotments som strukturerad, säljbar data med deadlines och synlighet i säljögonblicket.
Fördelning, prioritering och svarstidsklocka, byggt på attributionsdata vi redan samlar.
Oavsett väg finns det frågor som avgör hur långt vi når och hur snabbt. De flesta har lite längre ledtid och är bra att börja nysta i tidigt.
Hur långt räcker Catchs API för att skriva tillbaka, inte bara läsa? Avgör hur mycket som kan samlas helt i arbetsytan.
Boende och program per dag ligger hos webbyrån, inte i CRM:ets öppna API. Vi behöver förstå vägen dit.
Flyginfon finns strukturerad i Sabre. Åtkomst skulle autofylla mycket, vi driver den frågan, den har viss ledtid.
Hur mycket vill admin och sälj samla på ett ställe, och var går gränsen mot CRM:et? Det styr ambitionsnivån.
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. Kräver token från 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 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. Beror på Catch.
Alternativ väg till resource/dagsprogram om RPC-token dröjer. Beror på webbyrån.
PCC, Dev Studio, egen IATA vs konsolidator. Ej kritiska linjen, autofyller flyg när den landar. Vi driver, kräver konto och ingång.
Leverantör + finns inspelningsexport? Avgör vägen för samtalstranskribering. Fas 2.