Att bygga Inboxer för både Gmail och Outlook tog längre tid än enleverantörsversionen vi lanserade först. Inte för att Outlook är sämre - Microsoft Graph är ett respektabelt API - utan för att de två plattformarna exponerar grundläggande olika mentala modeller. Alla som utvärderar en AI-e-postassistent 2026 bör veta var de skillnaderna läcker in i produkten, eftersom de påverkar vad din AI kan och inte kan göra.

Etiketter kontra kategorier kontra mappar

Gmails organisatoriska byggsten är etiketten: en textsträng du fäster på en tråd. En tråd kan bära många etiketter. Att ta bort en etikett flyttar inte tråden någonstans - det tar bara bort taggen. Arkivering är frånvaron av INBOX-etiketten.

Outlooks byggsten är mappen: en tråd finns i exakt en mapp i taget. Arkivering innebär att flytta till Arkiv-mappen. Utöver det har Outlook även kategorier, som är färgade taggar som beter sig mer som Gmail-etiketter - men de flesta användare vet inte att de finns, och filtervyerna fungerar annorlunda.

För AI-klassificering spelar det roll: ett verktyg byggt på Gmail-etiketter kan tillämpa ”1 - To Respond” som etikett utan att rubba användarens mappstruktur. Samma verktyg på Outlook måste välja: använder vi kategorier (som användaren måste lära sig om) eller mappar (som flyttar bort tråden ur sikte)? Vi landade i kategorier med exakt samma namngivning som våra Gmail-etiketter, så att UX känns identisk mellan leverantörerna.

Trådning och konversationsgruppering

Gmail grupperar meddelanden i trådar aggressivt - ibland för aggressivt. Fem mejl med samma ämnesrad från olika personer hamnar i samma tråd även om de saknar samband. Outlooks konversationsgruppering är strängare (den följer In-Reply-To-huvudet mer troget) men den kan stängas av av användaren. När den är avstängd visas varje meddelande som sin egen rad.

Konsekvensen för AI: klassificeringens träffsäkerhet beror på att ha hela trådens kontext. Ett svar på ”Bekräftar vårt möte tisdag 15:00?” betyder ingenting utan originalet. Gmails aggressiva trådning hjälper modellen. Outlook med konversationsvyn avstängd tvingar AI:n att återskapa trådar från huvuden, vilket är möjligt men lägger till latens.

Snooza, skjuta upp, följa upp

Gmail har en inbyggd Snooza-funktion: ta bort från inkorgen tills X. Modellen kan upptäcka en SNOOZED-etikett och hoppa över tråden tills den återkommer.

Outlook har ingen motsvarande etikett. Det närmaste är flaggan ”Follow up” med ett startdatum och ett förfallodatum. Vi använder flag.flagStatus === "flagged" med ett framtida datum som snooze-proxy, och hoppar över klassificering på flaggade trådar. Det fungerar för normalfallet men täcker inte användare som använder Outlooks faktiska ”Snooze”-menyval - vilket flyttar meddelandet till ett dolt tillstånd som Graph v1.0-API:et inte exponerar rent.

Webhooks och push-notiser

Gmails push-notiser går via Google Pub/Sub. Du registrerar en watch, Gmail pushar till ditt topic, din tjänst konsumerar. Watches går ut efter 7 dagar och måste förnyas.

Microsoft Graph använder en prenumerationsmodell: du POST:ar till /subscriptions med en resurssökväg och en notifieringsURL, sedan träffar Microsoft din URL. Prenumerationer går ut efter ~3 dagar för e-post. Förnyelselogiken är symmetrisk.

Den dolda kostnaden hos Microsoft: webhooks levereras via Svix, som använder ett specifikt signaturformat (svix-id.svix-timestamp.body, HMAC-SHA256 med den base64-avkodade hemligheten, ±5 minuters replay-fönster). Implementerar du webhook-verifiering utifrån antagandet om Stripe-stil eller Gmail-stil signering avvisas varje webhook med en 401, och du lägger en felsökningssession på att förstå varför. (Vi vet.)

Skapa och skicka utkast

Båda leverantörerna exponerar skapa utkast och skicka. Gmails utkast har en egen resurs (/drafts) och kräver messages.modify för etikettuppdateringar, eftersom threads.modify inte sprids till utkast. Microsofts utkast ÄR meddelanden - de finns i /Drafts-mappen och kan PATCH:as som vilket meddelande som helst.

Slutsatsen för AI: att skriva ett utkast till svar är API-ekvivalent mellan de två leverantörerna. Inboxers kod abstraherar båda bakom ett enda EmailConnector.createDraft()-gränssnitt; konsumenten behöver inte veta vilken leverantör som ligger under.

Data för röstprofil: skickade objekt

För att lära sig hur en användare skriver behöver AI:n åtkomst till dennes skickade historik. Båda leverantörerna exponerar det:

Gmail: users.messages.list?q=in:sent
Microsoft Graph: /me/mailFolders/SentItems/messages

Samma nyttolaststorlek, samma parsning. Uppbyggnaden av röstprofilen körs identiskt på båda. Ansluter du Inboxer till både Gmail och samma persons Outlook skulle du få samma röstprofil.

Problemet med dubblerade etiketter

Här är en udda en. Gmails inställning ”Konversationsvy” ändrar hur etiketter renderas i filtrerade vyer. Med den AVSTÄNGD (ett val ~30 % av power users gör) visar filtrering på etikett en rad per meddelande istället för en per konversation. Så om en tråd har 5 meddelanden alla märkta ”5 - FYI”, ser användaren samma konversation 5 gånger. Inboxer kör en daglig cron som rensar bort dubblerade etiketter ner till bara det senaste meddelandet i varje tråd, specifikt för att fixa det här.

Outlooks kategorifilter har inte det här beteendet. En tråd = en rad, alltid. Så avdubbleringsjobbet gäller bara Gmail. Bra att veta om du någonsin migrerar.

Bör du välja e-postleverantör utifrån AI-stöd?

Ärligt talat, nej. Både Gmail och Outlook kan hysa samma AI-assistent 2026 med i praktiken identisk funktionalitet, eftersom skillnaderna på leverantörsnivå abstraheras bort av verktyg som Inboxer. Välj den e-postklient du faktiskt gillar att använda. AI-lagret ligger ovanpå oavsett.

Det enda undantaget: om du är på en företagstenant i Microsoft 365 där IT har stängt av tredjeparts Graph-prenumerationer, kan du inte få push-notiser i realtid utan faller tillbaka på polling. Det gör att AI:n känns ~30 sekunder långsammare per inkommande mejl. Det är en verklig skillnad men sällan avgörande.