CUSTOMER CARE TECHNOLOGIES SL

Customer Care Technologies SL es una sociedad mercantil constituida en Barcelona en 2016, clasificada en el corpus como startup del sector de software y SaaS. De acuerdo con la ficha registral, su razón social es CUSTOMER CARE TECHNOLOGIES SL y su estado registral es activo. El capital social actual consta en 409.069 EUR.

La sociedad se constituyó en 2016. El primer acto que consta en la cronología registral es una ampliación de capital del 7 de diciembre de 2016, por 74.000 EUR, que situó el capital suscrito en 77.133 EUR (de acuerdo con el BORME, tomo 44875, folio 133, hoja B 470060). Esto indica que la constitución fue previa a esa fecha y con un capital inicial inferior.

El corpus clasifica la empresa dentro del sector de software y SaaS, con sede en Barcelona. No consta en el corpus disponible ninguna descripción de producto, clientes o modelo de negocio más allá de esta clasificación sectorial, por lo que no se puede detallar qué ofrecía ni a quién se dirigía.

La cronología registral muestra una secuencia de ampliaciones de capital entre 2016 y 2018:

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

Estas operaciones constan en el BORME (tomo 44875, folio 133-134, y tomo 45389, folio 196, hoja B 470060). El corpus no aporta datos de ingresos, plantilla o clientes que permitan valorar la evolución del negocio en ese periodo.

De acuerdo con el registro, la empresa no ha cerrado: la ficha registral la califica como activa. No consta en el corpus ningún acto de disolución, liquidación o concurso. Por tanto, no se puede afirmar ninguna causa de cierre.

El corpus no contiene información sobre productos, marcas, tecnología o activos que hayan podido perdurar o ser transferidos. No consta.

Los administradores que constan en el registro son Iñaki Frias Inchausti (consejero y, desde 2022, secretario no consejero), Leonardo Saroni (consejero desde el 15 de enero de 2019) y Jordi Mercader Sanjuan (apoderado solidario desde el 21 de marzo de 2018 y consejero). En 2022 consta la revocación de David Villa Sánchez como secretario no consejero. El corpus no aporta información sobre la actividad actual de estas personas fuera de la sociedad. Para ampliarlo, se podría consultar el Registro Mercantil de Barcelona y las notas registrales posteriores a 2022.

• En una sociedad SaaS, las ampliaciones de capital sucesivas en los primeros años (2016-2018) constan en el registro y son un indicador objetivo de captación de financiación, pero no permiten por sí solas inferir tracción comercial: habría que cruzarlas con datos de facturación o de clientes, que el corpus no recoge.
• La designación de apoderados y consejeros en momentos próximos a las ampliaciones (2018) sugiere, según el registro, una estructura de gobierno que se fue formalizando a medida que entraba capital; es un patrón habitual en startups que levantan rondas.
• La calificación de "activa" en el registro no equivale a éxito ni a continuidad operativa: para evaluar la salud real de una SaaS habría que disponer de las cuentas depositadas, que no constan en el corpus.

Customer Care Technologies SL es va constituir el 2016 a Barcelona com a societat de software i SaaS, segons la fitxa registral disponible a OpenMercantil [BORME / BOE (via OpenMercantil), 2025-03-10]. El registre mostra una empresa que va aixecar capital en diverses ampliacions entre 2016 i 2018 —passant d'un capital inicial de 77.133 € a 100.341 € el maig de 2018— i que va mantenir activitat registral fins a l'última anotació documentada el 2022 [BORME / BOE (via OpenMercantil), 2025-03-10]. El nom i el sector apunten a una plataforma de gestió del servei al client: helpdesk, atenció multicanal, automatització de converses i analítica de qualitat.

La proposta de reconstrucció, marcada com a proposta nova i no com a fet verificat, seria una plataforma SaaS de customer care per a PIMEs i empreses de serveis, amb tres pilars: (1) bandeja d'entrada unificada (correu, xat, WhatsApp, veu), (2) automatització assistida per IA de respostes i classificació de tickets, i (3) analítica de conversa i qualitat per a supervisors. És a dir, la mateixa essència —tecnologia per gestionar el servei al client— adaptada al cost i a les eines disponibles el 2025.

El mercat de software de customer care i helpdesk és gran, madur i molt competitiu: hi conviuen grans plataformes globals i desenes d'eines especialitzades. Això vol dir que no hi ha espai per a un "altre helpdesk genèric", però sí per a nínxols concrets: PIMEs catalanes i espanyoles amb necessitats de suport en català i castellà, sectors regulats (salut, assegurances, educació) que requereixen traçabilitat i compliment normatiu, i verticals on la integració amb programari sectorial és el factor diferencial.

La dada verificada que tenim és que una empresa d'aquest sector va operar a Barcelona durant una dècada i va captar capital en diverses rondes primerenques [BORME / BOE (via OpenMercantil), 2025-03-10]. Això confirma que hi havia mercat i inversors disposats, però no ens diu res sobre la rendibilitat ni la sortida. Estimació a validar: el segment de PIMEs de 10 a 200 treballadors a Espanya que paguen per eines de suport és un mercat d'entre 50 i 150 milions d'euros anuals, segons rangs habituals del sector; caldria validar-ho amb dades d'informes de mercat recents.

Proposta: subscripció SaaS per seient i per volum de converses, amb tres plans (bàsic, professional, enterprise) i un mòdul d'automatització amb IA venut com a complement. Ingressos recurrents mensuals (MRR) com a mètrica principal.

Estructura estimada a validar:

• Pla bàsic: 15-25 €/usuari/mes.
• Pla professional: 40-60 €/usuari/mes amb automatització inclosa.
• Pla enterprise: contracte anual de 10.000-40.000 € amb integracions i suport dedicat.

El model hauria de prioritzar l'expansió dins del compte (upsell d'automatització i analítica) perquè el cost d'adquisició de client en aquest sector és alt i la retenció és el que fa viable el negoci. A validar: mètriques de churn i de cost d'adquisició reals del segment objectiu.

Proposta, en quatre fases:

1. Mesos 0-3 — Validació: 15-20 entrevistes amb responsables de suport de PIMEs i empreses de serveis; definició del nínxol inicial (recomanació: un sol vertical, per exemple clíniques o gestories). Prototip sense codi per validar fluxos.
2. Mesos 3-9 — MVP: bandeja unificada amb correu i xat, base de coneixement, assignació de tickets i informes bàsics. Construcció sobre APIs de tercers per reduir temps. Primers 5-10 clients de pagament en beta.
3. Mesos 9-15 — Automatització i analítica: classificació automàtica de tickets, suggeriments de resposta amb IA i quadre de qualitat. Integracions amb eines sectorials.
4. Mesos 15-24 — Escalat comercial: equip de vendes, màrqueting de continguts, expansió a Catalunya i resta d'Espanya, i primers passos cap a LatAm si les mètriques ho justifiquen.

Fites de control: 10 clients de pagament al mes 9, 50 al mes 18, i MRR suficient per cobrir costos operatius al mes 24 (xifra a definir amb el model financer detallat).

Estimació a validar, per als primers 12-18 mesos:

• Equip fundador (2-3 persones, sous moderats): 90.000-180.000 €.
• Desenvolupament (1-2 enginyers addicionals o contractistes): 60.000-120.000 €.
• Infraestructura cloud, APIs d'IA i eines: 6.000-18.000 €.
• Màrqueting i vendes inicials: 15.000-40.000 €.
• Legal, constitució, comptabilitat i compliment: 8.000-15.000 €.
• Contingència (15%): 25.000-55.000 €.

Total estimat: 150.000-400.000 € per al primer any i mig, amb un escenari baix (equip fundador reduït, MVP sobre APIs) i un escenari alt (equip més gran, producte propi). El capital social verificat de l'empresa original, 409.069 € [BORME / BOE (via OpenMercantil), 2025-03-10], és coherent amb aquest ordre de magnitud, tot i que no podem assumir que es va destinar íntegrament a operacions.

• Competència: el sector està dominat per plataformes globals amb recursos molt superiors; cal un nínxol clar i defensable.
• Cost d'adquisició: vendre SaaS a PIMEs requereix esforç comercial intensiu; el payback pot superar els 12 mesos.
• Dependència d'APIs de tercers (models d'IA, canals de missatgeria): canvis de preu o de condicions poden afectar el marge.
• Regulació de dades: el servei al client tracta dades personals; cal compliment estricte del RGPD i, en verticals com salut, normativa addicional.
• Retenció: si el producte no s'integra profundament en el flux de treball del client, el churn pot ser alt.
• Lliçó del registre: l'empresa original va necessitar diverses ampliacions de capital en només dos anys [BORME / BOE (via OpenMercantil), 2025-03-10], senyal que el camí fins a la rendibilitat en aquest sector és intensiu en capital.

Aquest informe no és un currículum ni una recomanació de persones, sinó un resum de les lliçons que es poden extreure de la trajectòria registral de Customer Care Technologies SL:

1. Cal capital pacient: les ampliacions successives entre 2016 i 2018 mostren que construir una empresa SaaS d'aquest tipus requereix finançament en fases, no una sola injecció [BORME / BOE (via OpenMercantil), 2025-03-10].
2. Cal un equip fundador amb perfil tècnic i comercial combinat: el registre mostra un consell amb perfils de gestió i apoderats, senyal d'una estructura de govern formal des de bon inici.
3. Cal enfocar-se en un nínxol: la longevitat registral (2016-2022 documentada) suggereix que l'empresa va mantenir activitat, però el mercat actual exigeix especialització per competir amb els grans.
4. Cal validar abans d'escalar: el cost estimat de 150.000-400.000 € només té sentit si les primeres fases demostren tracció real amb clients de pagament.

En resum: qui vulgui reconstruir aquesta essència avui hauria de ser un equip petit, amb capacitat tècnica per construir sobre APIs modernes, amb accés a capital inicial d'entre 150.000 i 400.000 € (estimació a validar) i amb la disciplina d'escollir un nínxol concret abans de competir de front amb les plataformes globals.

Els fabricants i distribuïdors de béns duradors (electrodomèstics, maquinària lleugera, equipament professional) gestionen la postvenda amb una combinació de correu, fulls de càlcul i el telèfon del servei tècnic. Això produeix tres costos concrets: reclamacions que es perden sense traçabilitat, recanvis enviats sense validar la garantia i, per tant, costos no imputables, i una incapacitat estructural de respondre "quantes unitats del lot X han fallat i quant ens ha costat" en menys d'un dia.

La inspiració és el negoci de CUSTOMER CARE TECHNOLOGIES SL, una startup SaaS constituïda el 2016 a Barcelona que va arribar a un capital social de 409.069 EUR després de tres ampliacions (2016, 2018 i 2018) segons els actes registrals [BORME / BOE (via OpenMercantil), 2025-03-10]. El producte que es descriu aquí no pretén reconstruir el seu codi, sinó resoldre el mateix nínxol amb una especificació implementable avui.

El client objectiu és el cap de postvenda d'un fabricant amb 5.000–200.000 unitats venudes anuals i una xarxa de 20–500 tècnics autoritzats. Aquest perfil ja paga per un ERP i un CRM, però cap dels dos modela el cas de postvenda com a objecte de primera classe.

Es proposa un monòlit modular desplegat en un sol contenidor, amb mòduls separats per fronteres de codi (no per xarxa) i comunicació interna per esdeveniments de domini. El motiu és la mida esperada de l'equip: una startup amb 3–10 enginyers no pot sostenir microserveis sense un cost d'operació que ofegaria el producte. La separació per mòduls permet extreure un servei més endavant si una peça ho justifica (per exemple, el motor de SLA).

``` +-----------------------------+ HTTPS -----> | API Gateway (Nginx) | +--------------+--------------+ | +--------------v--------------+ | App (Node/TypeScript) | | +-----------------------+ | | | mòdul cases | | | | mòdul sla | | | | mòdul recanvis | | | | mòdul garanties | | | | mòdul facturació | | | +-----------+-----------+ | +--------------+--------------+ | +-----------------------+-----------------------+ | | | +-----v------+ +-------v------+ +-------v------+ | PostgreSQL | | Redis | | S3 (adjunts) | | (OLTP) | | (cues/cache) | | | +------------+ +--------------+ +--------------+ | +--------------v--------------+ | Worker de cues (mateix codi)| +-----------------------------+ ```

Tres decisions amb motiu:

1. PostgreSQL com a única font de veritat, amb una taula d'esdeveniments (`case_event`) en mode append-only. Motiu: les auditories de garantia exigeixen reconstruir qui va decidir què i quan; un event log dins la mateixa base evita introduir Kafka per a un volum que no ho justifica.
2. Redis per a cues i cache de SLA, no com a base de dades. Motiu: els temporitzadors de SLA són efímers i reconstruïbles; si Redis es perd, es reconstrueixen des de `case_event` sense pèrdua de dades.
3. Adjunts a S3 amb URL signades, mai al disc local. Motiu: les fotos de danys i els PDF de garantia són el volum dominant i no han de competir amb les consultes transaccionals.

Esquema relacional mínim, amb claus i restriccions explícites. Els noms són els que farà servir la implementació.

```sql -- Catàleg product(id, sku, name, category, warranty_months) product_lot(id, product_id, lot_code, manufactured_at)

-- Actors account(id, name, type) -- type: manufacturer | distributor | service_center user(id, account_id, email, role) -- role: admin | agent | technician | viewer

-- Nucli de postvenda case(id, account_id, product_id, lot_id, serial_number, status, priority, opened_at, closed_at, channel) case_event(id, case_id, actor_id, type, payload_jsonb, created_at) sla_policy(id, account_id, priority, first_response_min, resolution_min) sla_clock(id, case_id, policy_id, due_at, breached_at, paused_min)

-- Recanvis i garanties part(id, sku, name, unit_cost) part_order(id, case_id, part_id, qty, status, shipped_at) warranty(id, case_id, product_id, serial_number, status, valid_from, valid_to, coverage_jsonb) ```

Restriccions que no són negociables:

• `case.serial_number` únic per `(account_id, product_id)` mentre `status != 'closed'`: evita casos duplicats pel mateix aparell.
• `case_event` només admet `INSERT`; un trigger bloqueja `UPDATE` i `DELETE`. Motiu: és el registre d'auditoria.
• `sla_clock.due_at` es calcula a l'aplicació, no a la base, perquè la política pot canviar i el càlcul ha de quedar versionat a `case_event`.

API REST versionada (`/v1`), autenticació per token OAuth2 de client (client credentials per a integracions, authorization code per a usuaris). Format JSON; errors amb codi estable (`CASE_DUPLICATE_SERIAL`, `SLA_POLICY_MISSING`).

Endpoints principals:

``` POST /v1/cases -- obrir cas GET /v1/cases?status=&sla=breached POST /v1/cases/{id}/events -- afegir nota, canvi d'estat POST /v1/cases/{id}/parts -- sol·licitar recanvi POST /v1/cases/{id}/warranty/check -- validar garantia GET /v1/reports/cost-by-lot/{lot} -- cost imputat per lot POST /v1/webhooks/erp -- entrada des d'ERP del client ```

Integracions previstes, per ordre de prioritat:

1. ERP del fabricant (SAP Business One, Odoo o Dynamics): sincronització de catàleg de productes i lots, i enviament de comandes de recanvi. Motiu: sense catàleg fiable el producte no arrenca.
2. Correu electrònic entrant (IMAP + parseig): crear casos des de bústies de servei. Motiu: és el canal real dels clients petits.
3. Transportistes (API de seguiment): estat d'enviament de recanvis dins el cas.
4. Facturació (Stripe): subscripció per nombre de casos actius, no per seient. Motiu: alinea el preu amb el valor percebut i facilita l'entrada a equips petits.

Ordre d'implementació, amb criteri de "què desbloqueja què":

1. Nucli de casos + esdeveniments (`case`, `case_event`, API de creació i consulta). Sense això no hi ha producte.
2. Motor de SLA (`sla_policy`, `sla_clock`, worker de temporitzadors). És el diferenciador enfront d'un full de càlcul i el que genera confiança en la primera demo.
3. Catàleg de productes i lots amb importació CSV. Permet proves amb dades reals del client.
4. Validació de garantia bàsica (regles per mesos i número de sèrie).
5. Recanvis i cost imputat per cas.

El que no es construeix a la primera fase: portal d'autoservei per al client final, aplicació mòbil per a tècnics i analítica predictiva. Motiu: cap d'aquests elements valida la hipòtesi central (que el fabricant paga per traçabilitat de postvenda), i tots tres multipliquen la superfície de producte abans de tenir ingressos.

Mides esperades (any 1): 50 comptes, 200 usuaris, 500.000 casos, 5 milions d'esdeveniments, 200 GB d'adjunts. Aquest volum cap còmodament en una instància PostgreSQL de 8 vCPU i 32 GB amb rèpliques de lectura; no cal sharding.

Riscos tècnics i mitigació:

• Explosió d'esdeveniments: cada acció genera un event. Mitigació: partició mensual de `case_event` per `created_at` i política de retenció de 24 mesos amb exportació a S3.
• Temporitzadors de SLA poc fiables: un worker que consulta Redis pot perdre's en reinicis. Mitigació: reconstrucció periòdica des de `case_event` i idempotència per `(case_id, policy_id, window)`.
• Integració ERP fràgil: cada ERP té el seu model. Mitigació: capa d'adaptadors amb contracte intern fix i tests de contracte per adaptador.
• Duplicació de casos per correu: dos missatges del mateix client obren dos casos. Mitigació: deduplicació per `(serial_number, remitent, finestra de 24 h)` abans de crear.
• Compliment de dades personals: el cas conté dades del client final. Mitigació: camps personals xifrats a nivell de columna i esborrat lògic amb anonimització, no esborrat físic, per preservar l'auditoria.

La validació té tres nivells i cadascun té un criteri d'èxit numèric:

1. Tècnica (CI): tests d'integració contra PostgreSQL real en contenidor; test de contracte per a cada adaptador d'ERP; test que verifica que `case_event` rebutja `UPDATE`. Criteri: cobertura de les rutes crítiques (obrir cas, validar garantia, demanar recanvi) al 90%.
2. Funcional amb un client pilot: un fabricant amb 20.000 unitats venudes i 3 centres de servei. Criteri: el 100% dels casos del mes queden registrats a la plataforma i el temps mitjà de primera resposta baixa respecte del baseline mesurat abans.
3. De valor: informe mensual de cost per lot generat automàticament. Criteri: el client l'usa en una reunió de direcció sense retocar-lo a mà. Si no passa aquest criteri, el producte encara no ven.

La font de veritat per a les dades corporatives citades en aquest document és la fitxa registral de CUSTOMER CARE TECHNOLOGIES SL a OpenMercantil (BORME) i l'acte