Het belang van UX-ontwerp voor IoT-adoptie

Het belang van UX-ontwerp voor IoT-adoptie

Bronknooppunt: 2346721

[Ingesloten inhoud]

UX ontwerp kan uw IoT-product maken of breken. Rob Shudra en Dominic Peters van Velavu sluiten zich aan bij Ryan Chacon op de IoT For All Podcast om het belang van UX-ontwerp voor IoT-adoptie te bespreken. Ze praten over waar je rekening mee moet houden bij UX-ontwerp, de botsing tussen ontwerp en ontwikkeling, de uitdagingen van IoT-gebruikerservaringen, bouwen voor verschillende soorten gebruikers, UX-ontwerp en marketing, belemmeringen voor IoT-adoptie en oplossingen, en het beheren van de verwachtingen van klanten.

Wilt u uw IoT-datastrategie optimaliseren en de volledige waarde van uw data benutten? Samenwerken met DAIN-studio's, de experts in datagedreven oplossingen. Ze zijn gespecialiseerd in het bouwen van robuuste IoT-datastrategieรซn die het potentieel van uw data volledig benutten. Hun team kan u helpen bij het systematisch identificeren, prioriteren en implementeren van datamogelijkheden om uw bedrijf vooruit te helpen.

Door het opzetten van key enablers zoals data governance en architectuur, zorgen zij voor de succesvolle implementatie van uw IoT-ambities. Lees meer en bezoek ze op dainstudios.com.

Over Rob Shudra

Rob Shudra is een bekroonde industrieel ontwerper en ondernemer uit Ottawa, Canada. Bij Velavu heeft Rob een belangrijke rol gespeeld bij het vormgeven van de groei en het succes van het bedrijf. Als oprichter en creatief directeur houdt Rob toezicht op alle ontwerpaspecten binnen Velavu, van industrieel ontwerp tot branding tot UI/UX, waardoor een samenhangende en boeiende gebruikerservaring voor de producten en diensten van het bedrijf wordt gegarandeerd.

Geรฏnteresseerd om in contact te komen met Beroven? Neem contact op via LinkedIn!

Over Dominicus Peters

Dominic Peters is een ervaren ingenieur met een passie voor elektronica en technologie. Als mede-oprichter en CTO van Velavu speelt Dominic een sleutelrol in de productontwikkeling en -implementatie van Velavu, terwijl hij leiding geeft aan het engineeringteam. De expertise van Dominic strekt zich uit tot het toezicht op de ontwikkeling van hardware en platformarchitectuur, waardoor een naadloze afstemming tussen de dagelijkse activiteiten en de langetermijnambities van het bedrijf wordt gegarandeerd.

Geรฏnteresseerd om in contact te komen met Dominic? Neem contact op via LinkedIn!

Over Velavu

Velavu is een bekroond technologiebedrijf voor het volgen van activa, gevestigd in Ottawa, Canada. Het Velavu-ecosysteem is een eenvoudige maar krachtige ervaring om toezicht te houden op uw activa, inventaris en processen via op maat gemaakte oplossingen en uitzonderlijk vervaardigde software en apparaten.

Belangrijkste vragen en onderwerpen uit deze aflevering:

(00: 38) Inleiding tot Rob Shudra, Dominic Peters en Velavu

(03: 04) Het belang van UX-design

(04: 30) Waar u op moet letten bij UX-ontwerp

(06: 14) Is er sprake van een botsing tussen ontwerp en ontwikkeling?

(07: 58) Uitdagingen van IoT-gebruikerservaring

(11: 02) Bouwen voor verschillende soorten gebruikers

(13: 01) Rol van goed UX-design in marketing

(14: 40) Belemmeringen voor IoT-adoptie en oplossingen

(16: 12) Hoe manage je de verwachtingen van klanten?

(18: 22) Meer informatie en opvolgen


Transcript:

โ€“ [Ryan] Welkom Rob en Dominic bij de IoT For All Podcast. Bedankt dat je hier deze week was.

โ€“ [Rob] Bedankt dat je ons hebt. 

โ€“ [Ryan] Ja, het is geweldig om jullie allebei hier te hebben. Ik ben enthousiast over dit gesprek. Voordat we hieraan beginnen, zou ik het geweldig vinden als jullie jezelf allemaal aan ons publiek zouden voorstellen en misschien een kort overzicht zouden geven van wat het bedrijf doet.

โ€“ [Dominic] Mijn naam is Dominic Peters. Als mede-oprichter en Engineering Lead bij Velavu studeerde ik eerst af aan de Carleton University met een diploma werktuigbouwkunde en tijdens mijn studie begon ik te werken bij een klein productontwikkelingsbedrijf als een alleskunner, maar naarmate het bedrijf groeide, begon ik te werken bij een klein productontwikkelingsbedrijf. vestigde zich hier en vond mijn passie als embedded systeemingenieur. Dus werken aan PCB-ontwerp, firmware, dat soort dingen. En nu als mede-oprichter en Engineering Lead bij Velavu blijft mijn rol het bijdragen aan en toezicht houden op de technische kant van de productontwikkeling, inclusief de implementatie van de hardware, de firmware en de algehele technologiestapel.

En omdat we een beetje een startup zijn, delen Rob en ik natuurlijk allebei ook een rol in de zakelijke kant van het bedrijf, wat een fantastische leerervaring is geweest, denk ik, voor ons allebei. 

โ€“ [Rob] En mijn naam is Rob Shudra. Ik ben de mede-oprichter en creatief directeur van Velavu. Mijn achtergrond ligt in industrieel ontwerp. Werken aan de ontwikkeling van producten, waarbij rekening wordt gehouden met de gebruikerservaring, de maakbaarheid en de esthetiek van de producten zelf. Door mijn achtergrond heb ik in verschillende sectoren gewerkt, of het nu gaat om consumentenelektronica, vliegtuiginterieurs en IoT. En ja, zoals Dominic zei, mijn rol binnen Velavu neigt meer naar het hardware-ontwerp, dus het ontwerpen van de producten zelf. Samenwerken met het engineeringteam en ook de softwarekant ontwikkelen. Veel gebruikerservaring was verbonden met veel van deze gebieden. 

โ€“ [Dominic] Het bieden van enige context voor de kijkers van Velavu, ons bedrijf. Velavu is dat wel, dus we noemen het een platform dat bestaat uit hardware- en softwareonderdelen die het op interessante wijze mogelijk maken om dingen zowel binnen als buiten te volgen met behulp van een combinatie van GPS en energiezuinige mesh-technologieรซn en gebouwd op een manier met echt een focus op het toestaan โ€‹โ€‹van klanten om het snel en eenvoudig te integreren in hun eigen workflows. Dus als je denkt aan verschillende gebruiksscenario's voor asset tracking, zaken als wagenparkbeheer, pallettracking en voorraadbeheer, willen we dat Velavu die one-stop-shop is waar klanten naar ons toe kunnen komen en een systeem hebben dat gemakkelijk te gebruiken en eenvoudig te integreren is. en het allerbelangrijkste: ook snel te doen om toe te voegen aan hun bedrijf. 

โ€“ [Ryan] Fantastisch. Ja, waardeer die overzichten en intro's. Dus ik wilde een beetje dieper ingaan op de kant van de gebruikerservaring. Ik denk dat dit een heel interessant onderwerp is dat we maar een paar keer op de podcast hebben besproken. Het wordt vaak over het hoofd gezien, en vooral als mensen zo gefocust zijn op het presenteren van hun technologie.

Maar ik denk dat we ons nu steeds meer realiseren dat UX super belangrijk is om oplossingen door vooral de eindgebruikers te laten adopteren. Dus ik wilde jullie hele perspectief krijgen door ons publiek een overzicht te geven van het belang van de kant van de gebruikerservaring als het gaat om het ontwikkelen van IoT-oplossingen en het stimuleren van adoptie.

โ€“ [Rob] Ik denk eerlijk gezegd dat het een product kan maken of breken. Het is zo belangrijk om een โ€‹โ€‹soepele gebruikerservaring te hebben. En het is iets waar je gemakkelijk naar kunt kijken, denk ik, in IoT, terwijl bedrijven heel vaak kijken naar het soort technologie, hoe je de technologie aan de praat kunt krijgen en goed kunt laten werken voor de gebruikssituatie.

Maar ik denk dat je gemakkelijk over het hoofd ziet hoe de consument of klant in dat proces past, hoe ze omgaan met je apparaten en systeem, dat zorgt voor een soepel proces en vermijdt eventuele wrijvingspunten. 

โ€“ [Ryan] Ja, een van de dingen die we eerder hebben genoemd lijkt goed te resoneren met veel mensen, als het gaat om het ontwikkelen van een oplossing, waarbij we echt proberen vanuit de eindgebruiker achteruit te denken in plaats van vanuit de technologie vooruit. Ik denk dat je het zou zeggen, want als de ervaring uiteindelijk niet iets is waar de eindgebruiker waarde in vindt of gemakkelijk kan gebruiken, zal de adoptie er niet echt zijn, en dan is de ROI er niet. en het is vaak een mislukte ervaring voor alle betrokkenen. Dus als je de UX-ontwikkelingskant benadert, zowel op technisch vlak als alleen op het gebied van de algemene overwegingen die moeten worden gemaakt. Hoe moeten bedrijven daarover nadenken? Wat dingen doen, zijn, is belangrijk voor hen om te begrijpen, voor hen om te weten, voor hen om te informeren naar de UX of de informatie die u samenstelt, zodat de UX de beste kans van slagen heeft wanneer deze wordt samengesteld door het team?

โ€“ [Rob] Gewoon begrijpen hoe de ruimte eruit ziet, wie de belanghebbenden zullen zijn, wie de klanten zullen zijn. Kijken naar wat hun behoeften zullen zijn voor het proces. Ik denk dat een groot deel daarvan ook is als je dat eenmaal door hebt, door jezelf in hun schoenen te verplaatsen en te begrijpen hoe ze door het proces zullen gaan en wat hun behoeften onderweg bij elke stap zullen zijn.

โ€“ [Dominic] Iets anders om daaraan toe te voegen, zou ik zeggen, alleen vanuit de technische kant, is vaak dat we onszelf in dit kader plaatsen waar we alleen maar naar de specificaties kijken, we kijken alleen naar de functionele vereisten van een product, en dat is waar duidelijke communicatielijnen met de ontwerpers die grotendeels verantwoordelijk zijn voor het definiรซren van de gebruikerservaring, het hebben van die duidelijke communicatie met hen op alle trajecten, vanaf de eerste brainstorming tot en met de productontwikkelingscyclus, en vooral aan de feedbackkant, erg belangrijk is. . Geweldige voorbeelden waarin we iets hebben ontwikkeld en misschien werkte de functie technisch goed, maar we zagen dat gebruikers, mensen die het op kantoor testten of vroege klanten, problemen hadden met het gebruik ervan. We gaan dus terug naar de tekentafel en vragen ons af: hoe kunnen we dit verbeteren? En vaak is het een samenwerking van de technische kant die zegt: oh misschien kunnen we dit doen, misschien kunnen we dit niet doen. Je hebt vaak te maken met technische vereisten aan de technische kant en transformeert deze in hoe we goede gebruikerservaringen kunnen creรซren met behulp van wat we weten over de technische vereisten.

โ€“ [Ryan] Is er een botsing tussen ontwerp en ontwikkeling? Omdat ik ontwerp ken, gaan ze bouwen wat volgens hen de beste ervaring is, maar tegelijkertijd zijn er altijd of niet altijd, maar er zijn vaak technische beperkingen waar de ontwerpers soms niets van weten, omdat dat niet hun is. wereld, toch?

Maar de ontwikkelaar zal ernaar kijken en zeggen dat de manier waarop je wilt dat dit zich gedraagt โ€‹โ€‹of de manier waarop je wilt dat deze ervaring is, veel werk gaat vergen, en dat dit technisch niet mogelijk is. Hoe zorg je ervoor dat beide teams harmonieus samenwerken om uiteindelijk de beste resultaten te behalen?

โ€“ [Rob] Het kan zeker een uitdaging zijn, vooral als je zowel met hardware als met software werkt. Ik denk dat er veel meer flexibiliteit is met software. Als je de hardware erbij haalt, zijn er veel meer beperkingen als het gaat om wat je efficiรซnt kunt doen met de productie van de apparaten, en wat de functies van die apparaten kunnen zijn. Ja, zoals Don al eerder zei, ervoor zorgen dat er veel communicatie is tussen de teams, zodat iedereen zich bewust is van de beperkingen aan beide kanten. 

โ€“ [Dominic] Feedback en iteratie ook. En dit is niet alleen een kwestie van communicatie, maar ook een kwestie van enkele van de nieuwe technologieรซn die we gebruiken, additieve productie, we hebben drie 3D-printers op ons kantoor en elke keer dat er een productketen is, zijn we niet hoeven te wachten op nieuwe prototypes uit het buitenland. We kunnen die in een middag op gang brengen en een nieuwe functie testen, testen. Een goed voorbeeld is vanuit de kant van de technische vereisten: we hadden een minimale speling op een GPS-antenne in ons apparaat die we moesten volgen bij onze eerste prototypes. Vervolgens ontdekten we echter dat we dat konden verminderen en geen prestatieverlies van de GPS konden bereiken, maar we konden dat binnen twee, drie dagen testen in plaats van weken of maanden te wachten. Het is dus echt de feedback en snelle iteratie is echt een sleutel om dat mogelijk te maken. 

โ€“ [Ryan] Laat me je dit vragen. Wat zijn enkele van de, op het gebied van IoT, ik weet dat elke vorm van gebruikerservaring die wordt opgebouwd, vooral in verschillende sectoren, zijn eigen uitdagingen heeft. Zijn er uitdagingen die jullie allemaal zijn tegengekomen of hebben opgemerkt dat dit een trend is als het gaat om IoT-gebruikerservaringen die worden gebouwd, gebruikersinterfaces die worden gebouwd? Ik weet dat veel van wat u doet, te maken heeft met het volgen van activa. Is er iets dat, naar ik vermoed, verband houdt met het volgen van assets, waarvan u denkt dat het een veel voorkomende uitdaging is als het gaat om het bouwen van deze interfaces voor eindgebruikers, en dat belangrijk is voor mensen die hiernaar luisteren, om dit zo vroeg mogelijk te begrijpen en erover na te denken? ? 

โ€“ [Rob] Ja, ik denk dat een van de grote uitdagingen waarmee we te maken hebben gehad, is dat er zoveel bewegende delen zijn bij het ontwikkelen van deze systemen. Je hebt het webdashboard, de mobiele app, en we hebben nu ook drie, vier apparaten en hardware. En die allemaal congruent ontwikkelen, vind ik een uitdaging. 

Met traditionele softwareontwikkeling kun je de wireframes opvoeren en testen, en het is meer een geรฏsoleerd systeem. Terwijl we bij Velavu hardware hebben die samenwerkt met de software, wat het behoorlijk moeilijk maakt om deze te testen en te testen hoe ze met elkaar gaan interageren.

Dus ik denk dat dat zeker een uitdaging is. Dat is iets waar we een beetje mee hebben leren omgaan door dingen te vervalsen tijdens het maken van prototypen en testen in onze ontwerpsoftware. Maar dat is zeker een van de uitdagingen waarmee we te maken kregen. 

โ€“ [Dominic] Een ander ding is dat ook veel kleinere bedrijven, vergelijkbaar met de onze op het gebied van asset tracking, dingen afpakken, bijna alsof ze dingen uit de onderdelenbak halen.

Misschien ontwikkelen ze zelf de hardware of ontwikkelen ze zelf het dashboard, maar voor andere onderdelen van de oplossing zijn ze afhankelijk van partners. En vaak kan dat resulteren in een product dat niet volledig, ik weet het niet, in elkaar zit. Zoals bepaalde aspecten van verschillende ontwerptalen of bepaalde aspecten zich anders gedragen.

Het systeem gedraagt โ€‹โ€‹zich gewoon niet als รฉรฉn geheel. We hebben het geluk dat we een productontwikkelingsachtergrond hebben en over de middelen beschikken om alles in eigen huis te kunnen ontwikkelen, wat betekent dat we een heel nauwe verticale integratie hebben tussen alle onderdelen, tot op het kernniveau, toch?

Het geeft ons dus een heel goede controle over alle onderdelen, van de hardware tot de firmware en de mobiele app. En dat is echt wat dit niveau van continuรฏteit in de ervaring garandeert. Of je nu alleen maar het apparaat instelt, naar de hardware kijkt, naar de webapp kijkt, je zult overeenkomsten opmerken in de ontwerptaal, in het industriรซle ontwerp , visueel ontwerp van alle applicaties, maar ook overeenkomsten in het gedrag van deze apparaten in het systeem als geheel. Dus ik denk dat dit een voordeel is dat we hebben door alles te ontwikkelen als รฉรฉn verticaal geรฏntegreerde oplossing, in plaats van veel andere bedrijven waar ze zullen werken met hardware van derden of derde partij dit en derde partij dat en alles samen bundelen. Ik zeg niet dat het niet mogelijk is, maar ik zou zeggen dat het een grotere uitdaging is als je met verschillende leveranciers en verschillende stukken werkt. 

โ€“ [Ryan] Hoe zit het als het gaat om bouwen voor verschillende soorten eindgebruikers? Ik ben er dus zeker van dat er meer technische eindgebruikers zijn, er zijn minder technische eindgebruikers, er zijn veel verschillende soorten scenario's waarin je vast en zeker terechtkomt, afhankelijk van wie de klant is.

Moeten er verschillende overwegingen worden gemaakt als het gaat om de manier waarop u iets bouwt, zodat het gemakkelijker kan worden overgenomen door de technische versus mogelijk niet-technische eindgebruikers? 

โ€“ [Dominic] Ik vind dat een fantastische vraag, Ryan. En het is iets dat we eigenlijk veel tegenkomen. Niet alleen verschillende niveaus van technische kennis, maar ook verschillende industrieรซn en verschillende klanten die enigszins verschillende functies willen, wat ertoe leidt dat we het systeem op verschillende manieren moeten aanpassen voor verschillende mensen in verschillende toepassingen.

Wat we probeerden te doen, is proberen het eenvoudig genoeg te maken, zodat een beginner, iemand zonder enige achtergrond in IT, nog steeds een goede ervaring kan hebben en het systeem nog steeds kan gebruiken zonder al te veel handigheid en integratie-inspanningen van onze kant. maar biedt nog steeds krachtig genoeg mogelijkheden in de vorm van REST API's, aangepaste regels-engines waar ontwikkelaars ook hun eigen logica in de applicatie kunnen implementeren, zodat de meer geavanceerde gebruikers of zoals de zakelijke gebruikers die er gewoon een deel van willen nemen, er misschien een deel van kunnen nemen. Misschien willen ze alleen het aspect locatietracking, maar willen ze dit in hun eigen dashboard integreren en hebben ze nog steeds de mogelijkheden om dat ook te doen. Maar dat is zeker, ik ben blij dat je dat ter sprake hebt gebracht, want dat is een van de meest uitdagende stukken geweest: het eenvoudig genoeg maken en gemakkelijk genoeg om te gebruiken voor de gemiddelde Joe.

Maar door het voldoende flexibiliteit te geven, zodat de grotere klanten of de klanten die het in hun eigen platform willen integreren er ook waarde in kunnen vinden. 

โ€“ [Rob] En ik denk dat je ook veel downstream-voordelen krijgt. Gebruikers die minder ervaring hebben met IT, het gebruiksgemak van het systeem is geweldig voor hen, maar ook voor de meer gevorderde gebruikers biedt het optimalisaties voor hoe snel ze het kunnen instellen, zelfs als ze het gebruiken met de API achteraf.

โ€“ [Ryan] Hoe vaak denk je erover na hoe dit gaat spelen in de marketingruimte? Hoe zullen deze gebruikersinterfaces worden begrepen? Omdat dit stukken zijn die kunnen worden gebruikt om nieuwe klanten binnen te halen, toch? Als u een gebruikersinterface voor palettracking bouwt voor een oplossing, hoeveel of wordt er veel over nagedacht hoe, ontwerpen we dan voor iets dat ook aantrekkelijk zal zijn om marketing te helpen zaken binnen te halen, om te worden tentoongesteld op beurzen , wat het ook is. Hoe wordt daarmee rekening gehouden, of helemaal niet, tijdens de ontwikkeling van het proces? Of wat denk je, hoe denk je daar eigenlijk over? 

โ€“ [Rob] Ja, ik denk dat we eerst en vooral kijken naar ontwerpen voor de specifieke gebruikssituatie en voor de gebruiker. Maar eigenlijk denk ik dat we ook wat extra voordelen krijgen voor de marketingkant, gebaseerd op de solide gebruikersinterface die we voor het product hebben gebouwd.

Aan de marketingkant proberen we de zaken eenvoudig te houden en het product echt te presenteren op een manier die gemakkelijk te begrijpen en gemakkelijk te verteren is. In de IoT-ruimte hebben we veel bedrijven gezien die je overweldigen met informatie over wat het product doet, in plaats van te kijken naar wat het product daadwerkelijk voor jou, de klant, gaat doen.

โ€“ [Ryan] Dus ik wilde een paar vragen stellen voordat we hier afsluiten. Eรฉn ervan is er, in het algemeen gesproken, als het gaat om een โ€‹โ€‹end-to-end-oplossing. Hoe minder bedrijven erbij betrokken zijn, hoe gemakkelijker het vaak is om te bouwen, in elkaar te zetten, enzovoort. Maar ik weet ook dat de IoT-industrie altijd een partnergericht ecosysteem is genoemd, waar niet iedereen elk onderdeel van een IoT-oplossing goed zelf kan uitvoeren. Daarom zullen ze hardware inbrengen, mogelijk een connectiviteitsbedrijf, ze zullen zal mogelijk een platform- of applicatielaagbedrijf inschakelen.

Waar zit het in, wat zijn in jouw ogen de grootste sleutels geweest om de barriรจres voor adoptie te verminderen met jouw alles-aanpak en hoe je het hebt gebouwd en de oplossing die je biedt? Waar denken jullie allemaal aan? Of wat heb je gezien als de belangrijkste belemmeringen voor adoptie en hoe je deze hebt verholpen of eromheen hebt gebouwd.

โ€“ [Dominic] De belangrijkste barriรจre voor ons vanuit een productontwikkelingsachtergrond is het vinden van de juiste klanten. En dat is waar de samenwerking met integrators voor ons eigenlijk super nuttig is geweest. En vaak gaan we naar beurzen, niet echt om eindklanten te ontmoeten, maar eigenlijk om integrators te ontmoeten die hun branche kennen.

Het kan een olie- en gasintegrator zijn, het kan een integrator zijn die samenwerkt met logistieke bedrijven. Zij kunnen vaak ons โ€‹โ€‹product zien, de voordelen zien en zien hoe het kan worden toegepast op de soorten klanten, de soorten bedrijven in hun ruimte . Ik ben niet de inhoudelijke expert op het gebied van olie en gas, of ik ben niet de inhoudelijke expert op het gebied van logistiek, en dat is waar het helpt om dit soort integrators te hebben die aan de zakelijke kant kunnen helpen om onze technologische oplossing tot iets te maken. dat echt waarde toevoegt aan de eindklant. Natuurlijk willen we ook nog steeds de directe verkoop aan klanten ondersteunen en dat werkt denk ik veel beter voor het type klant dat alleen maar een basissysteem voor het volgen van activa nodig heeft dat je de locatie van dingen kan vertellen, dat je kan vertellen dat de temperatuur en vochtigheid geassocieerd zijn met die dingen. Maar als het om de meer niche- of specifieke industrieรซn gaat, helpt het echt als we samenwerken met integrators die hun vakgebied kennen en onze technologie ergens in kunnen verwerken en aan hun klanten kunnen verkopen.

โ€“ [Ryan] Het laatste wat ik je wilde vragen voordat we hier afsluiten, gaat over het managen van de verwachtingen van de klant, omdat ik denk dat dit heel interessant is om over te praten. Ik heb in het verleden verschillende meningen gehad over hoe ze dat doen, maar als het gaat om vooral de applicatielaag en de gebruikersinterface-kant van de gebruikerservaring, hebben we allemaal als consumenten, zelfs ongeacht in welke branche we werken, te maken met verschillende soorten ervaringen, of het nu de app is die we gebruiken, of het nu het besturingssysteem is dat we gebruiken op basis van de telefoon, of de computers die we hebben. Hoe gaan jullie allemaal om met het scheppen van verwachtingen van wat echt mogelijk is bij een klant? 

โ€“ [Dominic] Ik denk dat het vooral helpt om in het begin en tijdens het hele proces transparant te zijn. Vaak krijg je, zoals je al zei, enthousiaste klanten die op beurzen naar ons toe komen en denken: wauw, dit gaat de wereld veranderen. We moeten heel vroeg transparant met hen zijn over wat het product kan doen, en vooral wat het ook niet kan. Goede voorbeelden: als de klant met dit soort technologie elke postzegel probeert te traceren, is het daar niet echt geschikt voor. Het zijn iets hogere kosten. Ja, het geeft je een echt hoge resolutie en realtime tracking, maar heb je dat echt nodig voor elk poststuk? Waarschijnlijk niet. Transparant zijn tegenover de klant en begrijpen of het daadwerkelijk bij hem of haar past, is dus een heel belangrijk onderdeel van het proces.

En soms kan dat zelfs betekenen dat potentiรซle klanten worden afgewezen als het niet past. Maar ik denk dat het belangrijk is om dat al vroeg te onderkennen en dat al vroeg te communiceren, in plaats van het alleen maar met brute kracht te proberen, en voor zowel jezelf als het perspectief van de klant, door dit konijnenhol in te gaan waar je vanaf het begin kunt zien dat het niet echt goed bij je past. .

โ€“ [Ryan] Zeer goed antwoord. Het is iets waarvan ik denk dat het bedrijven soms kan bijten als ze vanaf het allereerste begin geen verwachtingen scheppen en het voeren van die gesprekken alleen maar leidt tot meningsverschillen, teleurstellingen en wrijving, in feite met de mensen met wie je zaken probeert te doen en samen slagen.

Ik waardeer het enorm dat jullie vandaag de tijd hebben genomen om met mij te praten, want dit is een onderwerp waar ik blij mee ben dat we veel licht op kunnen werpen en kunnen luisteren naar jullie ervaringen en jullie expertise. Dus waardeer de tijd echt. En ik wilde dit afsluiten door u ons publiek te laten vertellen waar ze meer kunnen leren over wat jullie allemaal doen en misschien eventuele vragen, gedachten of ideeรซn kunnen beantwoorden.

โ€“ [Rob] Ja. U kunt ons bereiken op www.velavu.com of hello@velavu.com als u ons ook een e-mail wilt sturen. We zouden graag van je horen. 

โ€“ [Ryan] Rob, Dominic, hartelijk dank. Jullie waren fantastische gasten en ik ben blij om dit aan ons publiek te kunnen vertellen. 

โ€“ [Dominic] Bedankt Ryan. Het was een genoegen. 

โ€“ [Rob] Bedankt dat je ons hebt.

Tijdstempel:

Meer van IOT voor iedereen