Exakta bokningsavgifter och strukturerad tidsluckelogik omvandlade Arhams plattform till ett förutsägbart tjänsteekosystem.
Med Shipturtles bokningsarkitektur är marknaden nu redo för tusentals leverantörshanterade tidsluckor över hela Indonesien.
Infrastrukturen bakom Indonesiens marknadsplatser för tjänstebokningar
Läs vidare:
TL;DR( för lång; läste inte )
• Grundaren Arham driver en indonesisk flerleverantörstjänstmarknadsplats där kunder betalar en bokningsavgift online och det återstående beloppet kontant till lokala leverantörer.
• Beräkningsfel för provision inträffade eftersom plattformen behandlade bokningsavgifter som fullständiga produktpriser.
• Leverantörsemail, kundbekräftelser, tidsluckor och bokningsdatum saknade kritisk information.
• Shipturtle korrigerade kommissionens logik, justerade skatteregler och strukturerade bokningsattribut för e-post och WhatsApp-leveranser.
• Teamet begärde ett leverantörsvänligt gränssnitt för att publicera tidsluckor tillsammans med Enterprise API-åtkomst för djupare arbetsflöden.
En grundare som förvandlade öaktiviteter till en enad marknadsplats
När Arham först föreställde sig att bygga en marknadsplats för Indonesiens tur- och aktivitetsleverantörer, ville han ha mer än en turismsida. Han ville ha ett system som kunde föra samman oberoende operatörer. Dykinstruktörer, lokala guider, båtoperatörer, ATV-ägare, trekking-specialister, alla som erbjuder bokningsbara tjänster genom en central upplevelse.
Men denna modell hade en tvist som många grundare underskattar.
Kunderna skulle inte betala hela beloppet online. Marknadsplatsen samlade endast en bokningsavgift medan den återstående betalningen skedde personligen.
För kunderna behövde detta flöde kännas naturligt.
För leverantörerna behövde det vara kristallklart.
Till plattformen behövde det vara harmoniskt.
Istället uppstod sprickor snabbt.
• Provisionerna matchade inte den faktiska bokningsavgiften
• E-postmeddelanden saknade tidsluckor och kontaktuppgifter för leverantören
• Leverantörer hade svårt att förstå vilken bokning de uppfyllde.
• Shopifys struktur betraktade tjänster som produkter och raderade bokningssammanhanget.
Arham hade inte att göra med ett designproblem.
Han hanterade ett problem med dataarkitektur.
Varför tjänstebokningsmarknader går sönder utan sammanhang
E-handelsplattformar tänker i termer av produkter, priser och kvantiteter.
Tjänstebokningsmarknader tänker i termer av tid.
Ett ordentligt bokningssystem måste ha:
• Datumet
• Tidsfönstret
• Namnet på leverantören
• Bokningsavgiften
• Det belopp som ska betalas kontant
• Kundens kontaktinformation
• Tjänsteplatsen
• Sessions längd
Utan detta känns bekräftelser tomma, och leverantörer får gissa vad kunden faktiskt bokade.
I Arhams tidiga setup behandlade Shopify en dyksession klockan 07:00 och en dyksession klockan 12:30 som samma SKU.
För Shopify var dessa identiska.
I den verkliga världen är de helt olika händelser.
Denna mismatch förklarar varför:
• Leverantörens e-postmeddelanden hade inga tidsluckor
• Kundbekräftelser saknade viktiga detaljer
• WhatsApp-notifikationer såg ofullständiga ut
• Leverantörer var ofta tvungna att ringa kunden för att verifiera tidpunkten
Det var inte ett arbetsflödesproblem.
Det var en strukturell.
När Kommissionens Logik Kämpar Mot Betalningsmodellen
Arhams avsedda betalningsflöde var enkelt.
• Kunden betalar en bokningsavgift online
• Leverantören får den återstående betalningen kontant.
• Marknadsplatsen tjänar en fast provisionsprocent
• Skatter gäller endast för bokningsavgiften.
Men Shipturtle ärvde beställningen direkt från Shopify, där det fulla priset registrerades. Detta orsakade en kedjereaktion.
Systemet misstagigt:
• Beräknad provision på hela servicevärdet
• Inkluderade skatter inom provisionen
• Synkade fel totals i meddelandena
• Dubbeldebiterad provision i vissa fall
• Visade mismatchade värden jämfört med Shopifys kassa
Marknadsplatsen kändes inkonsekvent och svår att lita på.
Arham behövde inga nya funktioner.
Han behövde korrigering vid roten av logiken.
Återuppbygga grunden: Bokningsavgifter på rätt sätt
Shipturtle omstrukturerade allt kring den faktiska affärsmodellen.
Kommissionens logik omarbetad
• Kommissionen gäller endast bokningsavgiften.
• Fullservicepriset är uteslutet från utbetalningar.
• Skatter tillämpas korrekt
• Shopify-totaler och Shipturtle-totaler matchar nu
• Inga fler konstiga mismatchar eller dubbla avgifter
Bokningsattribut görs tillgängliga
• Tidslucka lagras nu som en bokningsegenskap
• Bokningsdatum skickas tydligt till e-postmallar.
• Leverantörs dashboards visar hela bokningssammanhanget
• Kundbekräftelser känns äntligen kompletta
Leverantörsmeddelanden Återbyggda
Om Shopify Flow missar en trigger, förbereder Shipturtle fallback-data för:
• Leverantörens namn
• Leverantörstelefon
• Bokningstid
• Bokningsdatum
• Kundinformation
• Bokningsavgift och kontantbelopp som ska betalas
Systemet talar nu språket för verklig tjänsteleverans snarare än SKU-logik.
Den saknade länken: Publicering av leverantörens tidsluckor
Under samtalen framkom ett stort behov.
Leverantörer behövde ett sätt att publicera tillgänglighet.
Ett enkelt, kalenderliknande gränssnitt som låter dem ställa in:
• Datum
• Tidslucka
• Kapacitet
• Mönster för veckodagar
• Varaktighetsregler
• Blockerade datum
Utan detta fick Arham manuellt konfigurera tillgänglighet eller förlita sig på statisk lager.
Han frågade om Shipturtle kunde skapa något liknande globala tjänsteplattformar. En panel där leverantörer kunde logga in, öppna kalendrar och kontrollera exakt när de kan ta emot bokningar.
Det här blev den största vägkartan för skalbarhet.
En marknadsplats kan inte växa med statisk tillgänglighet.
Det behöver dynamiska, leverantörsdrivna tidsluckor.
Vändpunkten: När bokningsmejl äntligen fick betydelse
Allt förändrades när Arham såg ett testmeddelande med fullständig kontext.
Det visades:
• Bokningsdatumet
• Den exakta tidsluckan (till exempel, 07:00)
• Leverantörens namn
• Bokningsavgiften
• Den återstående saldot
• Kundinformation
För första gången visste leverantörerna exakt vad de behövde leverera.
Kunderna slutade ställa repetitiva frågor.
Plattformen kändes inte som omkopplade arbetsflöden sydda tillsammans.
Det kändes som en riktig bokningsmotor.
Shipturtle som infrastrukturen bakom tjänstemarknader
Även om kunder aldrig ser det, driver Shipturtle nu varje väsentlig komponent av Arhams plattform.
Vad Shipturtle nu hanterar
• Korrekt bokningsavgiftskommissionslogik
• Exakta skatteflöden
• Tidslucka och datakartläggning
• Leverantörs e-post och WhatsApp meddelandeattribut
• Kalenderklar datarkitektur
• Företags-API-åtkomst
• Synkronisering av tjänster från flera leverantörer
• En tidslinje för offentliggörande av tidsluckor mot leverantörer
• Dedikerad onboarding-support
Shipturtle är inte det gränssnitt som kunder interagerar med.
Det är den tysta infrastrukturen som säkerställer att hela ekosystemet fungerar pålitligt.
Din marknadsplatslansering,
Förenklad
Få en strategisession som ger dig en skräddarsydd vägkarta, beprövade insikter och det stöd du behöver för att snabbt komma igång.
✓30-minuters strategisession
✓Plattformsrekommendation
✓Anpassad vägkarta
84%
Av de misslyckade tjänstebokningarna i Sydostasien beror {count} på att tidsfönstret eller leverantörens detaljer saknas i bekräftelserna.
Slutlig Transformation: En Marknadsplats Byggd för Skala
Arhams indonesiska tjänstemarknad fungerar nu med:
• Tydliga bokningsavgifter
• Värdefulla kommissionberäkningar
• Slutför bekräftelser
• Tydlighet och ansvarighet hos leverantörer
• Kundförtroende
• Tidslucka-logik redo för skalning
• Stödtjänst på företagsnivå för framtida arbetsflöden
Vad som började som en enkel idé att ta öaktivteter online har utvecklats till ett strukturerat bokningssystem.
Ett ekosystem byggt på tydlighet, ren logik och en datafundament som respekterar hur tjänster faktiskt fungerar.
Arham fixade inte bara en trasig arbetsflöde.
Han skapade ett förutsägbart, skalbart system redo för tusentals bokningar över hela Indonesien.
När Arham förbereder sig för att öka tillgången till leverantörer, dynamisk publicering av tidslotter och djupare serviceautomation, är nästa steg att bygga en enad schemaläggningsmotor över plattformen.
Boka en demomed oss idag för att utforma en tjänstemarknad som växer utan att gå sönder.
Vanliga frågor (FAQ)
- Varför kräver tjänstebokningsmarknader strukturerade bokningsattribut?
Eftersom datum, tidsluckor, leverantörsuppgifter och bokningsavgifter måste registreras och överföras konsekvent för bekräftelser, utbetalningar och meddelanden. - Hur förbättrar logiken för rena bokningsavgifter utbetalningarna?
Det säkerställer att provisioner endast tillämpas på bokningsavgiften, vilket förhindrar uppblåsta avgifter eller mismatchade totaltal mellan Shopify och marknadsplatsens backend. - Varför saknades leverantörsmeddelanden om tidsluckor initialt?
Shopify behandlade tjänster som produkter och lagrade inte bokningssammanhang, vilket gjorde att e-post och WhatsApp-meddelanden missade viktiga attribut för tjänsten. - Kan leverantörer nu se fullständiga bokningsdetaljer inuti sina instrumentpaneler?
Ja. Leverantörer får bokningsdatum, tidsluckor, kontaktinformation och avgiftsuppdelningar så att de vet exakt vilken tjänst de ska leverera. - Om Shopify Flow misslyckas med att utlösa en avisering, kan det finnas flera konsekvenser, inklusive:
1. **Förlorad information**: Viktiga meddelanden eller uppgifter kan gå förlorade, vilket kan påverka kommunikationen med kunder eller interna team.
2. **Fördröjningar**: Eventuella automatiserade processer kan försenas, vilket kan påverka kundupplevelsen och leda till missnöje.
3. **Felaktig databehandling**: Om aviseringar inte skickas kan data som är beroende av dessa meddelanden bearbetas felaktigt, vilket kan leda till felaktiga beslut i verksamheten.
4. **Ökat manuellt arbete**: Team kan behöva tillgripa manuella metoder för att hantera uppgifter som annars skulle ha automatiserats, vilket ökar arbetsbördan.
5. **Brister i övervakning**: Utan aviseringar kan det vara svårt att spåra och övervaka viktiga händelser eller förändringar, vilket kan påverka respons och åtgärder.
Det är viktigt att övervaka och felsöka eventuella problem med Shopify Flow för att säkerställa att alla automatiserade processer fungerar smidigt.
Shipturtle förbereder fallback-attribut för att säkerställa att leverantörs- och kund-e-post alltid innehåller viktiga bokningsdetaljer. - Varför är leverantörsdriven publicering av tidsslotter viktigt för skalning?
En marknadsplats kan inte växa med statisk tillgänglighet. Leverantörer måste kunna publicera och hantera sina egna dynamiska tidsluckor för att förebygga schemakonflikter. - Stöder detta system WhatsApp-notiser med fullständig bokningskontext?
Ja. Tids-, datum-, leverantörs- och avgiftsattribut överförs nu tydligt till WhatsApp-mallar för klara, handlingsbara uppdateringar. - Hur hjälper Enterprise API-åtkomst denna marknadsplats?
Det möjliggör djupare arbetsflödesautomatisering, avancerad schemaläggning och anpassade integrationer som är avgörande för ett högvolymserviceekosystem.
Om Författaren
Kali
Working at Shipturtle shows how easily complex ideas can be turned into simple and engaging visuals. It reflects an ability to understand how digital products function and explain them in a way that anyone can grasp without feeling overwhelmed.
This experience also highlights strong problem-solving and clarity in thinking. It shows a talent for taking complicated concepts, breaking them down, and presenting them through clean visuals and clear writing. This makes information easier for people to understand, whether they’re new to tech or already familiar with it.