Vælg routertilstand, før du skriver funktionslisten

Til en routerforespørgsel ville jeg sætte en lille netværksskitse over produktsammenligningen. Er den nye enhed beregnet til at være hovedrouteren eller til at levere Wi-Fi bag en eksisterende router? Svaret hører til ved siden af ​​den ønskede driftstilstand. To kasser, der ligner hinanden, kan tilbydes til forskellige roller, og en forhandler skal vide, hvilken rolle den foreslåede beskrivelse lover, før han vælger varen.

På demonstrationsposten ville jeg efterlade tre felter til leverandøren: model, hardwarerevision og installeret firmware. Jeg vil holde dets svar på samme side som den foreslåede tilstand. En funktion vist for en anden hardwareversion ville forblive et åbent spørgsmål. En manuel sidehenvisning ville hjælpe, eller en returneret indstillingsvisning fra prøven. Jeg vil bede om, at private netværksoplysninger fjernes fra den visning. Uden versionsposten ville jeg stadig sammenligne en produktfamiliebeskrivelse med en prøve, hvis konfiguration var uspecificeret.

Funktionskolonnerne ville følge denne konfiguration. For en køber, der er interesseret i gæsteadgang, trafikkontrol eller en VPN-funktion, vil jeg spørge, hvilke efterspurgte funktioner der virker i den valgte tilstand på den tilbudte version. TP-Links router-versus-access-point FAQ beskriver tilstandsafhængige begrænsninger i dets produkter. Jeg ville bruge det som en grund til at stille spørgsmålet i stedet for at kopiere svaret til en anden leverandørs router. En funktion nævnt andetsteds i et katalog afgør ikke dens tilgængelighed i dette særlige tilbud.

For den kablede side vil jeg bede om et bagpanel og et portbord returneret af leverandøren. Hver fysisk port vil blive identificeret med dens angivne forbindelseshastighed og dens rolle i den foreslåede tilstand. Hvis en port ændrer rolle med tilstanden, vil forskellen gå i svaret. En overskriftsbeskrivelse for trådløs hastighed ville forblive adskilt fra portspecifikationerne. Jeg ville ikke gøre nogen af ​​figurerne til et løfte om kundens internethastighed; der ville efterlade den faktiske forbindelse og brugsforhold uforklarlige.

Detailpakken ville have en separat linje til strømforsyning, kabel og instruktioner, der faktisk er inkluderet. Til forhandlerens ønskede sprog vil jeg efterlade separate svarrum under grænseflade og trykt vejledning. Leverandøren kunne identificere skærm- og dokumentversionerne i disse rum. En engelsk demonstrationsskærm ville ikke svare på det for et andet sprog. For en app-afhængig funktion vil jeg bede leverandøren om at nævne den påkrævede konto eller tjeneste i sit svar. Den lokale grænseflade vil have brug for et svar ved siden af. Hvis der pålægges et tilbagevendende gebyr, vil det indgå i sammenligningen, før forhandleren prissætter tilbuddet.

Jeg ville lægge udkastet til salgssiden ved siden af prøveposten og kontrollere den navngivne tilstand i hver. Enhver ubekræftet funktion ville holde sig uden for salgsløftet, mens spørgsmålet blev returneret til leverandøren. En prøvevurdering kunne derefter bruge den aftalte netværksrolle og de ønskede funktioner, med betingelser og resultater dokumenteret separat. En senere versionsændring ville sende mig tilbage til de accepterede funktionssvar. Jeg vil spørge leverandøren, hvilke svar der stadig gjaldt, og som krævede en ny vurdering. Supportpersonalet kunne derefter hente versionen og tilstanden bag salgsbeskrivelsen i stedet for at starte en opsætningsforespørgsel med kun navnet trykt på æsken.