CUSTOMER CARE TECHNOLOGIES SL

Customer Care Technologies SL és una societat mercantil constituïda a Barcelona l'any 2016, classificada al corpus com a startup del sector de software i SaaS. D'acord amb la fitxa registral, la seva raó social és CUSTOMER CARE TECHNOLOGIES SL i el seu estat registral és actiu. El capital social actual consta en 409.069 EUR.

La societat es va constituir el 2016. El primer acte que consta a la cronologia registral és una ampliació de capital del 7 de desembre de 2016, per 74.000 EUR, que va situar el capital subscrit en 77.133 EUR (d'acord amb el BORME, tom 44875, foli 133, full B 470060). Això indica que la constitució va ser prèvia a aquesta data i amb un capital inicial inferior.

El corpus classifica l'empresa dins del sector de software i SaaS, amb seu a Barcelona. No consta al corpus disponible cap descripció de producte, clients o model de negoci més enllà d'aquesta classificació sectorial, per la qual cosa no es pot detallar què oferia ni a qui s'adreçava.

La cronologia registral mostra una seqüència d'ampliacions de capital entre 2016 i 2018:

• 2016-12-07: ampliació de 74.000 EUR; capital subscrit resultant de 77.133 EUR.
• 2018-03-21: ampliació de 7.190 EUR; capital subscrit resultant de 84.323 EUR.
• 2018-05-30: ampliació de 16.018 EUR; capital subscrit resultant de 100.341 EUR.

Aquestes operacions consten al BORME (tom 44875, foli 133-134, i tom 45389, foli 196, full B 470060). El corpus no aporta dades d'ingressos, plantilla o clients que permetin valorar l'evolució del negoci en aquest període.

D'acord amb el registre, l'empresa no ha tancat: la fitxa registral la qualifica com a activa. No consta al corpus cap acte de dissolució, liquidació o concurs. Per tant, no es pot afirmar cap causa de tancament.

El corpus no conté informació sobre productes, marques, tecnologia o actius que hagin pogut perdurar o ser transferits. No consta.

Els administradors que consten al registre són Iñaki Frias Inchausti (conseller i, des del 2022, secretari no conseller), Leonardo Saroni (conseller des del 15 de gener de 2019) i Jordi Mercader Sanjuan (apoderat solidari des del 21 de març de 2018 i conseller). El 2022 consta la revocació de David Villa Sánchez com a secretari no conseller. El corpus no aporta informació sobre l'activitat actual d'aquestes persones fora de la societat. Per ampliar-ho, es podria consultar el Registre Mercantil de Barcelona i les notes registrals posteriors a 2022.

• En una societat SaaS, les ampliacions de capital successives en els primers anys (2016-2018) consten al registre i són un indicador objectiu de captació de finançament, però no permeten per si soles inferir tracció comercial: caldria creuar-les amb dades de facturació o de clients, que el corpus no recull.
• La designació d'apoderats i consellers en moments propers a les ampliacions (2018) suggereix, segons el registre, una estructura de govern que s'anà formalitzant a mesura que entrava capital; és un patró habitual en startups que aixequen rondes.
• La qualificació d'"activa" al registre no equival a èxit ni a continuïtat operativa: per avaluar la salut real d'una SaaS caldria disposar dels comptes dipositats, que no consten al corpus.

Customer Care Technologies SL es va constituir el 2016 a Barcelona com a startup de software i SaaS, segons la fitxa registral [BORME / BOE (via OpenMercantil), 2025-03-10]. El nom indica l'àmbit: tecnologia per a l'atenció al client. El registre mostra un capital social de 409.069 € i diverses ampliacions entre 2016 i 2018 [BORME / BOE (via OpenMercantil), 2025-03-10], senyal d'una empresa que va aixecar capital i va créixer durant els primers anys.

La proposta de reconstrucció (a validar) és la mateixa essència portada al 2025: una plataforma SaaS d'atenció al client, però amb agents d'IA com a nucli en lloc de només programari de ticketing o helpdesk. És a dir, un producte que automatitzi respostes de primer nivell, classifiqui i encamini converses, i doni als agents humans supervisió i analítica. Això és una proposta nova, no una descripció del producte original (que no consta a les fonts disponibles).

El mercat d'atenció al client i helpdesk és gran i madur, amb competidors consolidats (Zendesk, Intercom, Freshworks) i una segona onada d'eines natives d'IA. Això vol dir que el mercat existeix i paga, però també que competir de front és car.

L'oportunitat realista (proposta, a validar) no és el helpdesk genèric sinó un nínxol vertical: per exemple, atenció al client per a e-commerce de mida mitjana, per a sector financer regulat, o per a empreses catalanes i espanyoles que volen suport en català i castellà amb compliment normatiu local. El català com a diferencial és una hipòtesi raonable però no verificada.

Model proposat (a validar): subscripció SaaS per seient i per volum de converses automatitzades, amb un nivell gratuït o de prova per captar clients i plans per a pimes i per a empreses mitjanes.

Estructura de preus orientativa (estimació, a validar amb el mercat): 49-99 €/mes per a equips petits, 300-800 €/mes per a empreses mitjanes, i contractes anuals per a comptes grans. L'ingrés recurrent és clau; el cost marginal de servir un client addicional és baix, cosa que permet marges alts si l'adquisició de clients és eficient.

Fase 0 (mesos 0-2): validació. Entrevistes amb 20-30 responsables de suport de pimes per confirmar el nínxol i el preu. Cost baix.

Fase 1 (mesos 2-6): producte mínim viable. Un agent d'IA sobre canals de correu i xat, amb un panell de supervisió humà. Objectiu: 3-5 clients pilots.

Fase 2 (mesos 6-12): primers ingressos recurrents i iteració. Objectiu orientatiu (estimació, a validar): 10-20 clients de pagament.

Fase 3 (mesos 12-18): escalar vendes i considerar finançament extern si les mètriques ho justifiquen.

Rang estimat per a 12-18 mesos (estimació, a validar; no és cap dada de l'empresa original):

• Equip fundador mínim (2-3 persones, sous continguts): 90.000-180.000 €
• Desenvolupament de producte i infraestructura (APIs d'IA, núvol): 20.000-60.000 €
• Màrqueting i vendes inicials: 15.000-50.000 €
• Legal, constitució i compliment (RGPD, contractes): 5.000-15.000 €
• Contingència (15-20%): 20.000-60.000 €

Total orientatiu: 150.000-400.000 € segons ambició i velocitat. És un rang ampli perquè depèn molt de si l'equip es paga sou de mercat o no.

• Competència: els grans incorporen IA ràpidament; cal un nínxol defensable.
• Cost de les APIs d'IA: pot erosionar marges si els preus per conversa no es calculen bé.
• Adquisició de clients: el cost de vendre a pimes pot ser alt; cal validar el canal abans d'escalar.
• Compliment normatiu: l'atenció al client amb IA toca RGPD i, en alguns sectors, regulació específica.
• Dependència de proveïdors: dependre d'un sol model d'IA és un risc operatiu.

Les lliçons de l'expedient original: l'empresa va néixer el 2016 amb capital inicial modest (77.133 € després de la primera ampliació) i va ampliar fins a 409.069 € en poc més de dos anys [BORME / BOE (via OpenMercantil), 2025-03-10], cosa que suggereix que el capital extern va ser central per créixer. També mostra una estructura de consell amb consellers i secretari no conseller, és a dir, govern corporatiu formal des de relativament aviat.

La lectura per a una reconstrucció: cal un equip fundador amb perfil comercial fort (no només tècnic), disposició a aixecar capital o autofinançar-se amb clients des del primer dia, i una estructura de govern lleugera però seriosa. El perfil ideal és un fundador amb experiència en vendes B2B SaaS i un soci tècnic amb capacitat de construir producte amb IA. Sense capacitat comercial demostrada, el producte sol no sostindrà el negoci.

Els equips de suport al client tenen converses (xat, correu, telèfon transcrit) i tickets en sistemes diferents, i la qualitat es mesura a mà sobre mostres petites. Això fa que les decisions de plantilla, formació i SLA es prenguin amb dades esbiaixades i que no hi hagi traçabilitat de per què una conversa es va marcar com a "resolta" o "incomplerta".

La solució és un servei que rep esdeveniments de conversa i de ticket, els normalitza en un model comú, i calcula mètriques reproduïbles (temps de primera resposta, resolució en un contacte, compliment de guió, sentiment bàsic per lèxic) amb regles versionades. Cada resultat queda lligat a la versió de regles i al lot d'ingesta, de manera que qualsevol número es pot reconstruir mesos després. El motiu de fer-ho determinista i no només amb models generatius és l'auditabilitat: un client B2B ha de poder explicar per què un agent va rebre una puntuació concreta.

Arquitectura en tres plans: ingesta, càlcul i consulta. Tot és stateless excepte l'emmagatzematge, cosa que permet escalar horitzontalment i desplegar en un sol proveïdor cloud amb contenidors.

``` [CRM / Contact Center] --webhook/API--> [Ingest API (HTTP)] | v [Cua d'esdeveniments] | v [Normalitzador + Validador] | +-------------+-------------+ v v [Magatzem cru] [Magatzem columnar] (object storage, (Postgres + particions WORM per auditoria) per dia i tenant) | v [Motor de regles vN] | v [Taula de resultats + snapshots] | +-------------+-------------+ v v [API de consulta] [Webhooks sortints] ```

Decisions i motius:

• Cua d'esdeveniments (Kafka o SQS segons volum): desacobla la ingesta del càlcul i permet reintents idempotents. Motiu: els contact centers fan pics de milers de converses en minuts.
• Magatzem cru immutable: cada payload original es desa amb hash i timestamp. Motiu: si una regla canvia, es pot recalcular sense dependre del sistema d'origen, que pot haver esborrat dades.
• Motor de regles versionat: les regles són fitxers de configuració amb versió semàntica, no codi desplegat. Motiu: canviar un llindar no ha de requerir un desplegament, però sí quedar registrat.
• Postgres amb particions per tenant i dia: prou per a desenes de milions de files amb consultes per finestres; evita la complexitat d'un magatzem analític dedicat en la primera fase.
• Multi-tenant per fila amb `tenant_id` i row-level security: aïllament lògic sense desplegar una instància per client.

Entitats principals, amb claus i camps mínims:

```sql tenant(id uuid pk, nom text, pla text, creat_el timestamptz)

conversa( id uuid pk, tenant_id uuid, canal text, inici timestamptz, agent_id text, client_ref text, idioma text, hash_payload text, creat_el timestamptz )

missatge( id uuid pk, conversa_id uuid, ordre int, autor text, text text, ts timestamptz )

ticket( id uuid pk, tenant_id uuid, conversa_id uuid null, estat text, prioritat text, obert timestamptz, tancat timestamptz )

regla_versio(id text pk, descripcio text, publicada timestamptz)

resultat_avaluacio( id uuid pk, conversa_id uuid, regla_versio_id text, metrica text, valor numeric, detall jsonb, calculat_el timestamptz )

lot_ingesta(id uuid pk, tenant_id uuid, inici timestamptz, fi timestamptz, estat text) ```

Motius: `hash_payload` permet idempotència i detecció de duplicats; `detall jsonb` guarda l'evidència (per exemple, quin missatge va disparar una penalització) sense esquema rígid; `regla_versio_id` a cada resultat fa possible recalcular i comparar versions. Retenció: cru 24 mesos, resultats 36 mesos, configurables per contracte.

API REST amb autenticació per clau d'API per tenant i signatura HMAC als webhooks.

• `POST /v1/converses` — crea o actualitza una conversa (idempotent per `client_ref` + `hash_payload`).
• `POST /v1/converses/{id}/missatges` — afegeix missatges en lot (màxim 500 per crida).
• `POST /v1/tickets` — sincronitza estat i dates del ticket.
• `GET /v1/converses/{id}/avaluacio` — retorna mètriques amb `regla_versio_id` i evidència.
• `GET /v1/metrices?des_de=&fins_a=&agent_id=` — agregats per finestra.
• `POST /v1/recalculs` — encua un recàlcul per tenant i rang de dates amb una versió de regles concreta.
• Webhooks sortints: `avaluacio.completada`, `llindar.superat`, signats amb HMAC i amb reintents exponencials.

Integracions previstes: Zendesk i Freshdesk (tickets), Twilio i Vonage (transcripts de veu), i un connector genèric CSV per a exportacions. Motiu de començar per aquests: són els sistemes més freqüents en equips de 20-200 agents, el segment on el producte és rendible.

1. Ingesta idempotent (`POST /v1/converses` i missatges) amb magatzem cru i cua. És el coll d'ampolla de tot; sense dades fiables res més val.
2. Motor de regles v1 amb 5 mètriques deterministes: primera resposta, resolució en un contacte, compliment de guió per paraules clau, longitud de conversa i reobertura de ticket.
3. API de consulta i webhooks perquè el client pugui veure resultats al seu CRM sense esperar el nostre frontal.
4. Recàlcul per versió de regles, que és el que demostra l'auditabilitat i diferencia el producte.
5. Només després: sentiment per model i resum automàtic, com a capa opcional sobre les mateixes dades.

Mides objectiu de la primera versió: 50 tenants, 20.000 converses/dia, 2 milions de missatges/dia, latència d'avaluació per sota de 60 segons des de la ingesta, i consultes agregades de 30 dies en menys de 2 segons.

Riscos:

• Qualitat del transcript: els errors de transcripció de veu fan caure les mètriques lèxiques. Mitigació: marcar la font i no barrejar mètriques de veu i text en el mateix informe.
• Cost d'emmagatzematge cru: créixer linealment amb el volum. Mitigació: compressió i política de retenció per pla.
• Deriva de regles: canviar llindars sense versionar trencaria la comparabilitat. Mitigació: bloqueig de publicació de regles sense versió i recàlcul obligatori per comparar.
• Privadesa: els transcripts contenen dades personals. Mitigació: xifrat en repòs, pseudonimització d'identificadors i esborrat per sol·licitud amb traça al registre d'auditoria.

• Tests de contracte sobre l'API d'ingesta: idempotència, límits de lot i errors 4xx/5xx.
• Tests daurats del motor de regles: un conjunt de converses anotades a mà on la sortida esperada és fixa per versió; qualsevol canvi de resultat falla el test.
• Prova de recàlcul: recalcular 30 dies i verificar que els resultats coincideixen bit a bit amb els originals per a la mateixa versió de regles.
• Càrrega: simulació de 2 milions de missatges/dia amb pic de 10x en 10 minuts, mesurant latència de cua i de consulta.
• Auditoria externa: un client pilot ha de poder reconstruir la puntuació d'una conversa concreta a partir del payload cru i la versió de regles, sense accés a eines internes.

Fonts: la fitxa registral i les actes citades provenen de [BORME / BOE (via OpenMercantil), 2025-03-10] i de [BOE / BORME, 2025-03-10]; les dades de producte i arquitectura són una proposta tècnica, no informació verificada de l'empresa.