Skip to main content
Header
  • PT

Bom dia,

 

Venho aqui partilhar e por este meio expressar a minha insatisfação com a vergonhosa situação ocorrida na semana passada com a NOS. (Mais uma, em tantas).

No decorrer da semana passada fui contactado por uma funcionária da NOS, que fez a oferta - sem alteração contratual ou de fidelização - de um novo equipamento Gigarouter 5.0 v2 para auto-instalação.

Tendo acedido a esta oferta, foi-me enviado o equipamento pelo correio e entregue na sexta-feira. Procedi então à sua instalação e activei o modo Bridge, conforme configuração existente no Hub 3.0.


Logo após a instalação do mesmo, o serviço de internet fixa demonstrou-se por demais instável, apresentando quedas e interrupções constantes, sem qualquer qualidade de serviço. Entrei em contacto com o serviço de suporte técnico de internet da NOS, através do 16990, que ao verificar que o equipamento se encontrava em modo Bridge, recusa qualquer despiste e remete a situação para uma empresa terceira, PCMedic.

Desde já clarifico aqui que é totalmente inadmissível esta solicitação de contacto para uma empresa terceira, com a qual não tenho qualquer contrato, que não me diz rigorosamente nada, para abordar problemas com o serviço da NOS. Essa tal empresa PCMedic é parceira da NOS, mas a mim enquanto cliente - nada me diz. Caso haja a necessidade de contacto para despiste de qualquer situação, deverá a NOS enviar uma solicitação ao seu parceiro, para a verificação do que achem necessário, o que, de qualquer forma, é absolutamente vergonhoso chamar sequer a esta linha uma “linha técnica”, onde assistentes treinados como macacos são ensinados a ver uns valores no computador, e a seguir um script, sem qualquer real conhecimento técnico, sem formação, sem qualquer mínima competência do que é necessário para constituir um serviço técnico. Uma situação absolutamente vergonhosa, que me surpreende até como é possível que existam clientes que acedam a esta máfia de contactos com essa empresa que nada diz respeito ao contrato entre o cliente e o seu operador NOS.

Uma vez que a situação atingiu um impasse, dado que nunca iria contactar para essa empresa PCMedic, solicitei que voltasse a ser aprovisionado o anterior equipamento - HUB 3.0 - que funcionava correctamente. Nesta altura estava já em contacto com um “supervisor” da linha de apoio técnico, que me diz necessário passar a chamada para a linha de facturação para verificar se o equipamento anterior estava ainda activo. (o que mais uma vez me leva a questionar, como é que uma linha de suporte técnico não tem capacidade de validar se um equipamento está ou não activo?! Imagino que suporte técnico tenha um significado totalmente diferente para o resto do mundo, que o que tem para a NOS).

Sou então transferido para esta tal linha de facturação, que me informa que o equipamento está activo e será meramente uma questão de desligar o equipamento novo, e ligar o equipamento anterior, e ficaria tudo a funcionar de imediato.

Naturalmente que, mais uma vez, nada do que é comunicado ocorre em conformidade. Após ligar o HUB 3.0, o router fica com a luz laranja, e eu sem serviço de Internet, obrigando a novo contacto com a linha da NOS, a partir de outra rede, uma vez que estava também sem serviço de telefone fixo.

Passado cerca de uma hora, sou contactado novamente, com a informação de que faltava o aprovisionamento para o HUB 3.0, situação que ficou então resolvida.

Esta empresa NOS tem procedimentos absolutamente vergonhosos, inqualificáveis, pejada de uma mediocridade gritante. Mediocridade que reflecte não os assistentes, mas sim as camadas superiores que criam os procedimentos e processos. Fazem ofertas de equipamentos que não funcionam, e quando o cliente contacta a reportar a anomalia, devido à gritante incompetência das suas linhas de suporte “técnico”, tenta forçar os clientes a contactar com agentes terceiros, que nada dizem respeito ao contrato entre cliente e operador. Oferecem equipamentos “novos” com problemas, e não demonstram qualquer interesse na identificação real destes problemas, para a sua resolução e melhoria de serviço.

Finalmente, deixo o registo do log do meu router, ligado em modo de Bridge ao Gigarouter 5.0 v2:

Jul 10 15:56:25    check_reload_status    374    Reloading filter
Jul 10 15:56:25    check_reload_status    374    Restarting OpenVPN tunnels/interfaces
Jul 10 15:56:25    check_reload_status    374    Restarting ipsec tunnels
Jul 10 15:56:25    check_reload_status    374    updating dyndns WAN_DHCP
Jul 10 15:56:25    rc.gateway_alarm    58726    >>> Gateway alarm: WAN_DHCP (Addr:95.92.191.254 Alarm:1 RTT:6.536ms RTTsd:1.383ms Loss:21%)
Jul 10 15:18:59    rc.gateway_alarm    91261    >>> Gateway alarm: WAN_DHCP (Addr:95.92.191.254 Alarm:0 RTT:6.360ms RTTsd:1.187ms Loss:6%)
Jul 10 15:16:35    rc.gateway_alarm    46858    >>> Gateway alarm: WAN_DHCP (Addr:95.92.191.254 Alarm:1 RTT:6.149ms RTTsd:.943ms Loss:21%)
Jul 10 15:09:01    rc.gateway_alarm    10417    >>> Gateway alarm: WAN_DHCP (Addr:95.92.191.254 Alarm:0 RTT:6.316ms RTTsd:1.225ms Loss:5%)
Jul 10 15:06:41    rc.gateway_alarm    81640    >>> Gateway alarm: WAN_DHCP (Addr:95.92.191.254 Alarm:1 RTT:6.357ms RTTsd:1.362ms Loss:22%)
Jul 10 14:57:59    rc.gateway_alarm    54121    >>> Gateway alarm: WAN_DHCP (Addr:95.92.191.254 Alarm:0 RTT:6.718ms RTTsd:1.333ms Loss:5%)
Jul 10 14:56:11    rc.gateway_alarm    8128    >>> Gateway alarm: WAN_DHCP (Addr:95.92.191.254 Alarm:1 RTT:6.314ms RTTsd:1.290ms Loss:22%)
Jul 10 13:51:40    rc.gateway_alarm    27019    >>> Gateway alarm: WAN_DHCP (Addr:95.92.191.254 Alarm:0 RTT:6.809ms RTTsd:1.639ms Loss:5%)
Jul 10 13:49:13    rc.gateway_alarm    69386    >>> Gateway alarm: WAN_DHCP (Addr:95.92.191.254 Alarm:1 RTT:5.948ms RTTsd:1.099ms Loss:21%)
Jul 10 13:48:56    rc.gateway_alarm    3807    >>> Gateway alarm: WAN_DHCP (Addr:95.92.191.254 Alarm:0 RTT:6.648ms RTTsd:7.963ms Loss:5%)
Jul 10 13:47:40    rc.gateway_alarm    26197    >>> Gateway alarm: WAN_DHCP (Addr:95.92.191.254 Alarm:1 RTT:6.320ms RTTsd:1.248ms Loss:21%)
Jul 10 13:44:34    rc.gateway_alarm    36589    >>> Gateway alarm: WAN_DHCP (Addr:95.92.191.254 Alarm:0 RTT:6.212ms RTTsd:1.057ms Loss:5%)
Jul 10 13:42:14    rc.gateway_alarm    5283    >>> Gateway alarm: WAN_DHCP (Addr:95.92.191.254 Alarm:1 RTT:6.515ms RTTsd:1.242ms Loss:21%)
Jul 10 13:01:21    rc.gateway_alarm    62232    >>> Gateway alarm: WAN_DHCP (Addr:95.92.191.254 Alarm:0 RTT:6.277ms RTTsd:1.702ms Loss:5%)
Jul 10 12:59:01    rc.gateway_alarm    95118    >>> Gateway alarm: WAN_DHCP (Addr:95.92.191.254 Alarm:1 RTT:6.646ms RTTsd:2.107ms Loss:21%)
Jul 10 12:26:27    rc.gateway_alarm    29339    >>> Gateway alarm: WAN_DHCP (Addr:95.92.191.254 Alarm:0 RTT:6.178ms RTTsd:1.322ms Loss:5%)
Jul 10 12:23:59    rc.gateway_alarm    71119    >>> Gateway alarm: WAN_DHCP (Addr:95.92.191.254 Alarm:1 RTT:6.420ms RTTsd:2.216ms Loss:21%)
Jul 10 12:23:41    rc.gateway_alarm    93187    >>> Gateway alarm: WAN_DHCP (Addr:95.92.191.254 Alarm:0 RTT:6.437ms RTTsd:2.137ms Loss:6%)
Jul 10 12:22:28    rc.gateway_alarm    13806    >>> Gateway alarm: WAN_DHCP (Addr:95.92.191.254 Alarm:1 RTT:5.916ms RTTsd:.827ms Loss:22%)
Jul 10 11:56:07    rc.gateway_alarm    56913    >>> Gateway alarm: WAN_DHCP (Addr:95.92.191.254 Alarm:0 RTT:5.997ms RTTsd:1.345ms Loss:6%)
Jul 10 11:53:46    rc.gateway_alarm    36703    >>> Gateway alarm: WAN_DHCP (Addr:95.92.191.254 Alarm:1 RTT:6.066ms RTTsd:1.342ms Loss:21%)
Jul 10 10:58:16    rc.gateway_alarm    58804    >>> Gateway alarm: WAN_DHCP (Addr:95.92.191.254 Alarm:0 RTT:6.268ms RTTsd:1.273ms Loss:5%)
Jul 10 10:55:43    rc.gateway_alarm    9618    >>> Gateway alarm: WAN_DHCP (Addr:95.92.191.254 Alarm:1 RTT:6.333ms RTTsd:1.245ms Loss:21%)
Jul 10 10:55:26    rc.gateway_alarm    26365    >>> Gateway alarm: WAN_DHCP (Addr:95.92.191.254 Alarm:0 RTT:6.241ms RTTsd:1.226ms Loss:5%)
Jul 10 10:53:08    rc.gateway_alarm    76293    >>> Gateway alarm: WAN_DHCP (Addr:95.92.191.254 Alarm:1 RTT:6.147ms RTTsd:1.015ms Loss:22%)
Jul 10 10:39:23    rc.gateway_alarm    50656    >>> Gateway alarm: WAN_DHCP (Addr:95.92.191.254 Alarm:0 RTT:5.962ms RTTsd:1.089ms Loss:5%)
Jul 10 10:37:06    rc.gateway_alarm    33419    >>> Gateway alarm: WAN_DHCP (Addr:95.92.191.254 Alarm:1 RTT:5.989ms RTTsd:.932ms Loss:22%)
Jul 10 09:17:42    rc.gateway_alarm    29144    >>> Gateway alarm: WAN_DHCP (Addr:95.92.191.254 Alarm:0 RTT:5.890ms RTTsd:.836ms Loss:5%)
Jul 10 09:15:10    rc.gateway_alarm    43836    >>> Gateway alarm: WAN_DHCP (Addr:95.92.191.254 Alarm:1 RTT:5.943ms RTTsd:.868ms Loss:21%)
Jul 10 09:14:53    rc.gateway_alarm    4582    >>> Gateway alarm: WAN_DHCP (Addr:95.92.191.254 Alarm:0 RTT:5.972ms RTTsd:.888ms Loss:5%)
Jul 10 09:12:29    rc.gateway_alarm    60869    >>> Gateway alarm: WAN_DHCP (Addr:95.92.191.254 Alarm:1 RTT:6.007ms RTTsd:.985ms Loss:22%)
Jul 10 07:15:09    rc.gateway_alarm    38103    >>> Gateway alarm: WAN_DHCP (Addr:95.92.191.254 Alarm:0 RTT:5.961ms RTTsd:1.948ms Loss:5%)
Jul 10 07:12:50    rc.gateway_alarm    98099    >>> Gateway alarm: WAN_DHCP (Addr:95.92.191.254 Alarm:1 RTT:6.707ms RTTsd:4.693ms Loss:21%)
Jul 10 07:01:05    rc.gateway_alarm    47414    >>> Gateway alarm: WAN_DHCP (Addr:95.92.191.254 Alarm:0 RTT:5.982ms RTTsd:1.478ms Loss:5%)
Jul 10 06:58:44    rc.gateway_alarm    16300    >>> Gateway alarm: WAN_DHCP (Addr:95.92.191.254 Alarm:1 RTT:5.930ms RTTsd:.858ms Loss:22%)
Jul 10 06:57:23    rc.gateway_alarm    97255    >>> Gateway alarm: WAN_DHCP (Addr:95.92.191.254 Alarm:0 RTT:6.492ms RTTsd:3.275ms Loss:5%)
Jul 10 06:54:55    rc.gateway_alarm    65454    >>> Gateway alarm: WAN_DHCP (Addr:95.92.191.254 Alarm:1 RTT:6.625ms RTTsd:5.517ms Loss:21%)
Jul 10 06:24:44    rc.gateway_alarm    8754    >>> Gateway alarm: WAN_DHCP (Addr:95.92.191.254 Alarm:0 RTT:5.909ms RTTsd:.956ms Loss:5%)
Jul 10 06:22:21    rc.gateway_alarm    14915    >>> Gateway alarm: WAN_DHCP (Addr:95.92.191.254 Alarm:1 RTT:5.900ms RTTsd:.569ms Loss:21%)
Jul 10 06:09:34    rc.gateway_alarm    42814    >>> Gateway alarm: WAN_DHCP (Addr:95.92.191.254 Alarm:0 RTT:5.974ms RTTsd:1.029ms Loss:6%)
Jul 10 06:06:58    rc.gateway_alarm    85090    >>> Gateway alarm: WAN_DHCP (Addr:95.92.191.254 Alarm:1 RTT:6.329ms RTTsd:2.337ms Loss:22%)
Jul 10 06:06:40    rc.gateway_alarm    26992    >>> Gateway alarm: WAN_DHCP (Addr:95.92.191.254 Alarm:0 RTT:6.160ms RTTsd:1.090ms Loss:6%)
Jul 10 06:02:25    rc.gateway_alarm    82452    >>> Gateway alarm: WAN_DHCP (Addr:95.92.191.254 Alarm:1 RTT:6.022ms RTTsd:.999ms Loss:21%)
Jul 10 06:02:06    rc.gateway_alarm    15184    >>> Gateway alarm: WAN_DHCP (Addr:95.92.191.254 Alarm:0 RTT:5.983ms RTTsd:.968ms Loss:5%)

Depois de ligar o HUB 3.0 e o mesmo ser novamente aprovisionado, deixou de existir qualquer erro, qualquer interrupção de serviço.

Ficou apenas (mais) uma péssima experiência com o serviço da NOS, entre tantas outras.

Tudo o que disse é normal.

Apoio técnico não verifica configurações mais “ informáticas “, e aqui está incluido modo bridge. Para isso tem a pcmedic para melhor ajuda ao cliente.

Callcenters é mesmo assim, scripts e alguns valores. Mesmo equipas técnicas superiores não verificam e encaminham para pcmedic ( tambem trabalham com outras operadoras)

O facto de passar para a linha de faturação é normal também,  porque o processo não pode ser tratado pela linha técnica.

Bem, eu trabalho na área e digo-lhe que o que você considera “normal” é tudo menos normal, é uma verdadeira anormalidade.

É inconcebível que indivíduos em linhas técnicas não tenham quaisquer conhecimentos técnicos, pouco me interessa o call-center que seja. Como disse, a PCMedic é parceira da NOS, a mim não diz rigorosamente nada. Portanto, nunca enquanto cliente irei contactar para uma empresa terceira, com a qual não tenho qualquer relação contratual.

Repare que o problema em nada diz respeito ao meu equipamento, mas única e exclusivamente ao novo equipamento fornecido pela NOS, que apresenta um comportamento deficiente numa simples configuração Bridge, sem outros parâmetros que modo DHCP automático (na ligação WAN → upstream).

O facto de passar para a facturação também não passa de outra anormalidade, pois a assistente da facturação verificou que o equipamento estava activo na ficha de cliente, no entanto o HUB 3.0 não estava aprovisionado tecnicamente, motivo pelo qual ao liga-lo não funcionou, sendo necessário mais um sem número de contactos para a NOS até que a situação ficasse efectivamente resolvida, portanto, incompetência transversal a todos os departamentos com os quais se esteve em contacto.

E é tão má a actuação da NOS, como indivíduos como você que consideram “normal” e que normalizam estes comportamentos e procedimentos de ligar eu. cliente, para empresas terceiras, para fazer despistes que o próprio operador se demonstra incompetente para realizar. Uma vergonha abismal, mas neste país, infelizmente, a mediocridade é a nova norma, portanto aqui estamos.

Olá @Visigodo,

Lamentamos a situação.

Neste momento já está normalizada?

Obrigada

Estimada @Inês B. 

A situação está normalizada depois de remover o novo equipamento que enviaram e instalar o anterior HUB 3.0. O que mais uma vez considero absolutamente vergonhoso, fazerem a oferta de um equipamento avariado ou com problemas, e não apresentarem qualquer solução para que o equipamento novo fique a funcionar.

Boa tarde @Visigodo,

Envie-nos, por favor, uma mensagem privada para o perfil @Fórum  acompanhada do seu número de cliente.

Obrigado

Enviado.

Olá @Visigodo, 

Vamos responder à sua mensagem o mais breve possível. 

Obrigada 

No seguimento desta situação, fui contactado por uma assistente para “despiste de problemas de Internet”, sem fazer a mínima ideia da situação abordada, que depois de informada sobre o sucedido (e aqui descrito) diz que não pode fazer nada, porque o router 5.0 já não está activo.

Mais ainda, quando o equipamento anterior, como descrito, estava com problemas óbvios, diz que vai pedir a re-activação do equipamento Gigarouter 5.0 - O MESMO, que estava com falhas, e não qualquer sugestão para, no mínimo, enviarem alguém com outro equipamento que possa não ter problemas técnicos.

A incompetência da NOS e dos seus serviços é gritante e surreal, numa dimensão totalmente inconcebível.

No seguimento desta situação, fui contactado por uma assistente para “despiste de problemas de Internet”, sem fazer a mínima ideia da situação abordada, que depois de informada sobre o sucedido (e aqui descrito) diz que não pode fazer nada, porque o router 5.0 já não está activo.

Mais ainda, quando o equipamento anterior, como descrito, estava com problemas óbvios, diz que vai pedir a re-activação do equipamento Gigarouter 5.0 - O MESMO, que estava com falhas, e não qualquer sugestão para, no mínimo, enviarem alguém com outro equipamento que possa não ter problemas técnicos.

A incompetência da NOS e dos seus serviços é gritante e surreal, numa dimensão totalmente inconcebível.


Realmente a moderadora encaminhar a situação para o apoio técnico quando o router já não está ativo não faz sentido nenhum.

A articulação de departamentos e serviços da NOS funciona tão bem quanto uma marioneta à qual cortaram os cordéis.

Boa tarde @Visigodo,

Agradecemos o seu testemunho e lamentamos o transtorno.

Caso surja alguma outra questão, estamos sempre disponíveis para ajudar.

Obrigado

Comentário


Chatbox 7.0
Assistente Virtual do Fórum NOS
my NOS indice

Conheça todas as funcionalidades da my NOS

Vídeos de ajuda

Video iframe com botão
Condições do Fórum NOS