CUSTOMER COMMUNICATIONS TECKNALIA SL

Customer Communications Tecknalia SL és una societat mercantil espanyola amb domicili a Madrid, classificada al corpus com a startup del sector de software i SaaS. D'acord amb el registre, la societat es va constituir el 2017 i consta activa a data de 2025. El corpus no aporta informació sobre l'objecte social detallat ni sobre els productes o serveis concrets que ofereix.

La societat es va constituir el 2017. El primer acte que consta al registre és del 7 de desembre de 2017: el nomenament d'un apoderat, Félix Yerro Yerro, segons el BORME recollit per OpenMercantil. El corpus no identifica els socis fundadors ni el capital inicial; només consten nomenaments d'apoderats i, més endavant, el nomenament d'auditor.

El corpus classifica l'empresa dins del sector de software i SaaS, però no detalla quins productes o serveis ofereix ni a quin tipus de clients s'adreça. Aquesta informació no consta a les dades disponibles.

El corpus no conté dades financeres, de facturació, de nombre de clients ni d'evolució del negoci. Els únics elements que consten són registrals: nomenaments successius d'apoderats entre 2017 i 2019 (Félix Yerro Yerro, Rafael Pastor Zuazaga i Iker Ruiz Abad, segons el BORME) i, el febrer de 2025, el nomenament d'Afianza Auditores SLP com a auditor. El corpus no permet afirmar res sobre l'evolució econòmica de la societat.

La societat no consta com a tancada. D'acord amb el registre, a data de 2025 continua activa. El corpus no recull cap acte de dissolució, liquidació o concurs.

Atès que la societat consta activa, no es pot parlar d'herència en el sentit de llegat d'una empresa desapareguda. El corpus no aporta informació sobre cap impacte o llegat rellevant.

El corpus no identifica els fundadors de la societat. Les persones que hi consten són apoderats i l'auditor: Félix Yerro Yerro (apoderat el 2017), Rafael Pastor Zuazaga (apoderat el 2018 i novament el 2025), Iker Ruiz Abad (apoderat el 2018 i el 2019) i Afianza Auditores SLP (auditor nomenat el 2025), segons el BORME. No consta quina és la seva situació actual més enllà d'aquests nomenaments registrals. Per ampliar-ho es podria consultar la fitxa completa d'OpenMercantil, el Registre Mercantil de Madrid (tom 29801, foli 99, secció 8, full M-536210) i les comptes anuals dipositades.

• En el sector SaaS, la informació registral (nomenaments d'apoderats, auditoria) no permet inferir l'estat del negoci; calen les comptes anuals dipositades per valorar facturació i solvència.
• El nomenament d'un auditor el 2025 en una societat constituïda el 2017 pot indicar un canvi de règim de verificació comptable, però el corpus no en concreta la causa; caldria consultar les comptes dipositades per confirmar-ho.
• La successió de nomenaments d'apoderats en els primers anys (2017-2019) és un senyal de creixement organitzatiu, però no equival a resultats econòmics; cal contrastar-ho amb dades financeres.

Nota de verificació: de l'empresa original només sabem, per fonts registrals, la raó social, la ubicació (Madrid), l'any de constitució (2017), l'estat actiu al registre i la cronologia d'apoderats i auditor [BORME/OpenMercantil, 2025-04-04]. No hi ha dades públiques verificades sobre el producte, els clients ni els ingressos. Tot el que segueix és proposta, no reconstrucció de fets.

La proposta és construir una plataforma de comunicacions de client com a servei (CPaaS) verticalitzada: una capa de programari que permet a empreses enviar i rebre missatges (WhatsApp Business, SMS, correu, veu) i gestionar converses de suport i vendes des d'un sol lloc, amb automatitzacions i integracions amb CRM.

La diferència respecte de l'original (que desconeixem en detall) i respecte del mercat actual és el nínxol: en lloc de vendre "comunicacions per a tothom", vendre a 2-3 sectors concrets on la conversa és el negoci — per exemple, clíniques i salut privada, serveis financers de proximitat, o retail amb atenció postvenda intensiva. El producte és el mateix motor; el que canvia és el paquet de plantilles, fluxos i compliment normatiu per sector.

El mercat de CPaaS i de plataformes de conversa és gran i està consolidat: hi ha actors globals (Twilio, Vonage, Infobip, Meta via WhatsApp Business Platform) i una capa d'agregadors i revendes locals a Espanya. Això vol dir que el mercat existeix i està educat — no cal explicar què és un WhatsApp Business API — però també que el marge per ser "un Twilio més" és nul.

L'oportunitat real és a la cua llarga: PIMEs i mitjanes empreses que necessiten converses integrades però no tenen equip tècnic per muntar-ho. Aquest segment està mal atès perquè els grans proveïdors venen API i no solució, i les agències ho resolen amb projectes a mida cars i difícils de mantenir.

Estimació (a validar): el mercat adreçable a Espanya per a una solució vertical de conversa per a PIME podria situar-se en un rang de 50-150M€ anuals de despesa en eines de comunicació i automatització, segons càlculs propis sobre nombre d'empreses del segment i despesa mitjana per empresa. Aquesta xifra és una estimació de treball, no una dada de mercat contrastada.

Model SaaS amb consum, que és l'estàndard del sector:

• Subscripció base per compte i nombre d'usuaris (plataforma, bandeja unificada, automatitzacions).
• Consum de missatgeria amb marge sobre el cost del proveïdor (WhatsApp, SMS). El marge típic del sector és baix en missatgeria i alt en programari; estimació: 15-30% de marge en missatgeria, 70-85% en subscripció (rang a validar amb els proveïdors reals).
• Setup i integració per als primers clients (ingrés no recurrent que finança el llançament).
• Verticalització com a palanca de preu: el paquet sectorial justifica un preu superior al d'una eina genèrica.

Mètriques a vigilar des del dia u: cost d'adquisició (CAC), valor de vida del client (LTV), i especialment el consum mitjà per client, perquè és el que fa créixer el negoci sense vendre més comptes.

Fase 0 — Validació (mesos 1-3). Triar un sol vertical. Entrevistar 20-30 empreses del sector i confirmar que pagarien per resoldre el problema de conversa. Tancar 3-5 clients de disseny que paguin poc però comprometin feedback.

Fase 1 — Producte mínim (mesos 3-6). Bandeja unificada (WhatsApp + correu + SMS), plantilles sectorials, integració amb un CRM majoritari i un sistema de cites o de tickets segons el vertical. Res més. Tot el que no sigui imprescindible per al primer vertical, fora.

Fase 2 — Primers deu clients de pagament (mesos 6-12). Venda directa, no màrqueting. L'objectiu no és escalar sinó aprendre quin flux es repeteix i quina part es pot productitzar.

Fase 3 — Repetició i segon vertical (mesos 12-24). Un cop el primer vertical té un patró de vendes repetible, replicar el paquet al segon. Només llavors invertir en màrqueting de captació.

Totes les xifres són estimacions de treball, a validar amb pressupostos reals:

• Equip fundador (3-4 persones, 12 mesos): 180-280k€ en sous i càrregues, si es paga sou de mercat. Si els fundadors s'autofinancen parcialment, baixa.
• Desenvolupament i infraestructura (12 mesos): 40-80k€ (cloud, eines, llicències, proveïdors de missatgeria en fase de proves).
• Compliment i legal: 15-30k€ (RGPD, contractes amb proveïdors de missatgeria, alta de societat, auditories si calen).
• Venda i màrqueting inicial: 30-60k€ (venda directa, esdeveniments sectorials, contingut).
• Cost de missatgeria avançat pels primers clients: 10-25k€ de capital circulant, perquè els proveïdors cobren abans que els clients paguin.

Total estimat per als primers 12 mesos: 275-475k€, amb un escenari central al voltant de 350k€. És un negoci que es pot començar amb menys (150-200k€) si l'equip és més petit i el vertical és molt estret, però aleshores el creixement és més lent.

• Risc de commoditització: la missatgeria és un producte indiferenciat i el marge es comprimeix. Si el negoci depèn del consum i no del programari, el preu cau any rere any.
• Dependència de Meta i dels operadors: canvis de preus, de polítiques o de condicions de WhatsApp Business poden alterar el model d'un dia per l'altre. Cal diversificar canals i no dependre d'un sol proveïdor.
• Risc regulatori: RGPD, conservació de comunicacions i normativa sectorial (salut, finances) són exigents; un error de compliment pot costar més que el negoci.
• Risc de vendes llargues: les PIME compren poc i lent; el CAC pot menjar-se el marge si no es productitza la venda.
• Risc de memòria del sector: si l'empresa original va tancar en un mercat competitiu, la lliçó és que la tecnologia no n'hi ha prou; cal un canal de distribució propi o una vertical on ningú més estigui còmode.

(Aquesta secció resumeix les lliçons de l'informe original, no és un currículum.)

Les lliçons que es poden extreure de la trajectòria registral de CUSTOMER COMMUNICATIONS TECKNALIA SL són tres, i totes són sobre govern i estructura, no sobre tecnologia:

1. Una SL de 2017 amb apoderats nomenats repetidament (2017, 2018, 2019, 2025) i auditor des del 2025 indica una estructura que va créixer i es va formalitzar, però que va mantenir el control en poques mans. La lliçó: la reconstrucció ha de començar amb un equip fundador clar i un repartiment de rols explícit, no amb un consell ornamental.

1. El nomenament d'un auditor el 2025 és el senyal més informatiu de tota la fitxa: suggereix que l'empresa va arribar a un volum o a una forma que obligava a auditar. La lliçó per a la reconstrucció: pensar des del dia u en l'escala i en la comptabilitat ordenada, perquè el moment en què cal formalitzar arriba abans del que sembla.

1. La cronologia no mostra canvis de soci ni de denominació, sinó només nomenaments d'apoderats. La lliçó: els negocis de comunicacions moren sovint per falta de relleu en la distribució, no per falta de producte. Qui ho torni a fer ha de tenir des del principi una persona dedicada a vendre i a mantenir el canal, no només a construir.

En resum: la reconstrucció no ha de replicar el que l'empresa era (que no coneixem), sinó corregir el que la fitxa suggereix que li va faltar: focus de mercat, canal de distribució i disciplina d'escala.

Les empreses que envien notificacions crítiques (codis OTP, avisos de comanda, alertes de frau) acaben integrant-se amb tres o quatre proveïdors diferents: un per SMS, un per correu, un per push. Cada proveïdor té la seva API, el seu format d'estat d'entrega i la seva facturació. El resultat és que l'equip de producte no sap, en un sol lloc, si un missatge concret ha arribat al destinatari, i l'equip de finances no pot atribuir costos per producte o per client.

El producte és una capa d'orquestració per sobre dels proveïdors: una sola API per enviar, un sol model de plantilles, i un registre unificat d'esdeveniments d'entrega. El client defineix rutes (per exemple, "si l'SMS falla en 30 segons, reintenta per veu"), i la plataforma ho executa i ho factura.

Aquesta descripció és una hipòtesi de producte inspirada en el nom i el sector registral de l'empresa [BORME / BOE (via OpenMercantil), 2025-04-04]; no afirma què feia realment la companyia.

Tres plans separats, desplegats com a serveis independents en un sol clúster Kubernetes:

• Pla de control (API REST + panell): autenticació per clau d'API, gestió de plantilles, rutes i remitents. És stateless i escala horitzontalment. Base de dades PostgreSQL per a configuració i catàleg.
• Pla d'ingesta: un servei que rep l'ordre d'enviament, la valida contra la plantilla i la ruta, i publica un esdeveniment `send.requested` a Kafka. Respon `202 Accepted` amb un `message_id` immediatament; no bloqueja el client esperant el proveïdor.
• Pla d'execució: consumidors de Kafka per canal (`worker-sms`, `worker-email`, `worker-push`, `worker-voice`). Cada worker tradueix l'esdeveniment al format del proveïdor, crida l'API externa i escriu l'estat a la base de dades d'esdeveniments.

``` Client --HTTPS--> API ingesta --> Kafka(topic: send.requested) | +----------------+----------------+ | | | worker-sms worker-email worker-push | | | proveïdor SMS proveïdor mail proveïdor push | | | +-------> Kafka(topic: delivery.events) | projector --> PostgreSQL (events) + webhooks al client ```

Motiu de Kafka i no una cua simple: els esdeveniments d'entrega s'han de poder reproduir per recalcular facturació o reconstruir l'estat d'un missatge. Una cua que es buida no ho permet.

Motiu de separar ingesta i execució: si un proveïdor cau, la ingesta continua acceptant enviaments i els workers reintenten amb backoff. El client no veu errors 5xx per culpa d'un tercer.

PostgreSQL per a configuració i estat; les taules d'esdeveniments són particionades per mes i es poden arxivar a object storage.

```sql -- Catàleg CREATE TABLE accounts ( id uuid PRIMARY KEY, name text NOT NULL, api_key_hash text NOT NULL UNIQUE, -- mai la clau en clar created_at timestamptz NOT NULL DEFAULT now() );

CREATE TABLE templates ( id uuid PRIMARY KEY, account_id uuid NOT NULL REFERENCES accounts(id), channel text NOT NULL CHECK (channel IN ('sms','email','push','voice')), body text NOT NULL, -- amb placeholders {{var}} locale text NOT NULL DEFAULT 'ca', version int NOT NULL DEFAULT 1, UNIQUE (account_id, channel, locale, version) );

CREATE TABLE routes ( id uuid PRIMARY KEY, account_id uuid NOT NULL REFERENCES accounts(id), name text NOT NULL, steps jsonb NOT NULL -- [{channel, timeout_s, fallback_on:[...]}] );

-- Missatges i esdeveniments CREATE TABLE messages ( id uuid PRIMARY KEY, account_id uuid NOT NULL, route_id uuid, recipient text NOT NULL, -- hash per a consultes, xifrat per a enviament status text NOT NULL, -- queued|sent|delivered|failed|expired created_at timestamptz NOT NULL DEFAULT now() ) PARTITION BY RANGE (created_at);

CREATE TABLE delivery_events ( message_id uuid NOT NULL, channel text NOT NULL, provider text NOT NULL, provider_ref text, event text NOT NULL, -- accepted|delivered|bounced|rejected occurred_at timestamptz NOT NULL, raw jsonb NOT NULL, -- còpia del payload del proveïdor PRIMARY KEY (message_id, channel, occurred_at) ) PARTITION BY RANGE (occurred_at); ```

Motiu de `raw jsonb`: quan un client discuteix una factura o un estat d'entrega, cal poder mostrar exactament què va respondre el proveïdor. Sense això, la disputa no es pot resoldre.

Motiu de particionar per temps: el volum d'esdeveniments creix molt més ràpid que el catàleg; les particions permeten esborrar o arxivar sense `DELETE` massiu.

API REST versionada (`/v1`), autenticada amb `Authorization: Bearer <api_key>`.

• `POST /v1/messages` — cos: `{route, recipient, template_id, variables}`. Retorna `202` amb `{message_id}`.
• `GET /v1/messages/{id}` — estat actual i darrer esdeveniment.
• `GET /v1/messages/{id}/events` — llista completa d'esdeveniments per canal.
• `POST /v1/templates`, `PUT /v1/templates/{id}` — gestió de plantilles.
• `POST /v1/webhooks` — el client registra una URL; la plataforma hi envia els esdeveniments d'entrega signats amb HMAC-SHA256 sobre el cos i un timestamp.

Integracions de sortida (proveïdors): un adaptador per proveïdor darrere d'una interfície comuna `ChannelProvider.send(payload) -> provider_ref` i `ChannelProvider.parseWebhook(body) -> Event`. Els webhooks entrants dels proveïdors passen per un endpoint `/v1/providers/{provider}/callback` que valida signatura, normalitza i publica a `delivery.events`.

Motiu de webhooks signats cap al client: el client ha de poder verificar que l'esdeveniment ve de nosaltres; sense signatura, qualsevol pot injectar estats falsos.

Motiu d'un adaptador per proveïdor: permet canviar de proveïdor SMS sense tocar els workers ni el model de dades; només s'afegeix una implementació.

1. Ingesta + worker SMS + webhook d'estat del proveïdor SMS. És el camí més curt per demostrar el valor: enviar i saber si ha arribat.
2. Model de plantilles i rutes amb un sol pas. Permet validar la API amb clients reals abans d'afegir fallbacks.
3. Projector d'esdeveniments i `GET /v1/messages/{id}`. Sense consulta d'estat, el producte no és usable.
4. Worker de correu. Segon canal, reutilitza tota la infraestructura anterior.

Els canals push i veu, els fallbacks encadenats i la facturació per esdeveniment queden per a la segona fase: afegeixen superfície (SDKs mòbils, integració de veu) sense canviar el nucli.

• Volum: un client mitjà pot generar 50k–500k missatges/dia. Amb particions mensuals i índexs per `(account_id, created_at)`, PostgreSQL aguanta; per sobre de ~5M esdeveniments/dia caldrà passar les consultes d'estat a una base orientada a esdeveniments (ClickHouse o similar).
• Latència d'entrega: el coll d'ampolla és el proveïdor extern, no la plataforma. Objectiu: `p95` de `send.requested` a crida al proveïdor < 2 s en condicions normals.
• Risc: límits de rate dels proveïdors. Cal un limitador per compte i per proveïdor als workers; si no, un pic d'un client bloqueja els altres.
• Risc: duplicats. Kafka garanteix almenys un cop; els workers han de ser idempotents usant `message_id` com a clau d'idempotència davant del proveïdor quan ho permeti, i deduplicant esdeveniments pel `provider_ref`.
• Risc: dades personals. Els destinataris són dades personals; cal xifratge en repòs de la columna `recipient`, retenció definida (per exemple 90 dies per a esdeveniments crus) i registre d'accés.
• Risc: dependència d'un sol proveïdor per canal. Mitigar amb dos adaptadors per canal des del disseny, encara que el segon no s'activi fins a la fase 2.

• Test d'integració del camí feliç: enviar un missatge SMS contra un proveïdor simulat (mock amb webhook), comprovar que `GET /v1/messages/{id}` passa de `queued` a `delivered` i que el client rep el webhook signat.
• Test de fallada del proveïdor: el mock retorna `500`; el worker ha de reintentar amb backoff i, passat el timeout de la ruta, marcar `failed` o saltar al següent pas.
• Test d'idempotència: reenviar el mateix esdeveniment de Kafka i verificar que no es duplica l'esdeveniment ni la crida al proveïdor.
• Prova de càrrega: 100 missatges/s sostinguts durant 10 minuts; mesurar latència d'ingesta i backlog de Kafka.
• Validació de signatura: un webhook amb HMAC incorrecte ha de ser rebutjat amb `401` i no ha de generar cap esdeveniment.
• Criteri d'acceptació de la fase 1: un client extern pot enviar un SMS, rebre el webhook d'entrega i consultar l'estat, tot amb la documentació pública de l'API, sense intervenció de l'equip.