The Empty Box in the Responsibility Matrix: Who Owns a SysMap Transformation?

Summary

• SysMap Solutions Software e Consultoria Ltda. is a legally verifiable Brazilian company with multiple establishments under the same root CNPJ, but its website, group careers page and associated brands create boundaries that a buyer should resolve in the contract rather than infer from a shared brand.
• The strongest third-party capacity evidence is the Salesforce AppExchange directory, which listed 129 verified projects and 92 certified experts at time of access; SysMap's wider cloud, automation, data and development catalogue remains primarily supported by first-party descriptions and selected cases.
• SysMap sells materially different engagement models: fixed-scope projects, managed teams, individual specialists, consulting and ongoing support. A buyer cannot evaluate them with a single generic 'digital transformation' dashboard because control, acceptance, pricing and ownership of failure change by model.
• The decisive procurement test is not the number of partner logos. It is whether the client retains administrative control, repositories, deployment definitions, data and metadata exports, test assets, runbooks, service records and a repeatable transition path when people, contracts or platforms change.

The Failure That Belongs to Everyone

Start with a hypothetical failure at 2:07 a.m. on a Monday morning. A command enters a customer channel but does not complete in the existing billing system. The public cloud status page is green. The CRM platform is available. An API gateway accepted the request. A custom transformation produced a syntactically valid message, but a modified business rule rendered it unusable downstream. Support can see an error but cannot safely replay it. The client owns the rule, a software platform owns the execution, an integrator wrote the mapping, and a different team now operates the legacy system.

This is not an incident narrative at SysMap. It is the procurement thought experiment through which SysMap should be judged. The company markets almost every discipline that could touch this failed transaction: web and mobile development, cloud, API management, microservices, CRM, robotic process automation, DevOps, analytics, systems integration, automated testing and application support. Itscurrent main sitepresents these capacities as a broad transformation continuum; its structure chart moves from design and architecture through agile delivery, professional services and support. Breadth can be useful because fewer handoffs can mean faster diagnosis. It can also make responsibility harder to locate if the specification treats all these disciplines as a single promise.

The empty box is the space between a platform provider's service commitment, the client's retained duties and SysMap's actual deliverables. Filling it requires more than a RACI table copied into a launch deck. The buyer needs an operational allocation for every important workflow: who owns the tenant, identity policy, source repository, infrastructure definitions, integration mappings, business rules, test data, release approval, oversight, incident command, supplier escalation, recovery decision and regulatory notice. It needs an acceptance test for these duties and proof that the named team can execute them.

This distinction matters in Brazil because outsourced technology is normal rather than exceptional. The nationally-orientedTIC Empresas 2025table from Cetic.br reports that 59% of surveyed companies used external providers for IT functions in the previous 12 months. Among companies that outsourced IT functions, the associated service types tableF4reports that 85% used externals for internal systems support, 37% for application development, 48% for hosting and 55% for infrastructure. These figures describe the Brazilian market, not SysMap's share or performance. They nevertheless explain why the central question is no longer whether to outsource. It is how to maintain responsibility and institutional memory when multiple externals participate.

SysMap is interesting precisely because it sits across these categories. Its proposition is not a single software product with a standard licence and observable feature set. It is a changing combination of people, project methods, custom code and third-party platforms. The contract, control model and exit package are therefore part of the product.

The Ltda Behind the Brand

The assigned subject is SysMap Solutions Software e Consultoria Ltda., not every company or initiative that uses SysMap, Triggo or a related brand. The legal bridge is unusually clear in one respect. SysMap's officialsalary transparency 2026page names SysMap Solutions Software e Consultoria Ltda. and publishes reports for CNPJ 67.379.149/0001-02 and 67.379.149/0005-28. The page states that the Ministry of Labour and Employment produced the reports from 2025 eSocial information, that the data was anonymised and that the company had not verified the reports. This caveat concerns labour statistics; the page itself remains strong first-party evidence linking the current SysMap brand, the exact company name and these records.

The two numbers should not be interpreted as two unrelated companies. The Receita Federal'sopen CNPJ metadatadefines the first eight positions as the root CNPJ, positions nine to twelve as the establishment order and the last two as check digits. Both published records share root 67.379.149. A current business data page based on public records identifies67.379.149/0001-02as the active matrix in São Paulo and /0005-28 as an active branch in São Paulo. The same aggregation lists /0003-66 as an active branch in Belo Horizonte. Aggregators do not replace a Receita certificate, but the structure is consistent with a single legal company operating through multiple establishments.

This distinction has practical consequences. A branch CNPJ may appear on employment, billing or local operation records without creating a separate parent company. Similarly, a shared root does not tell a buyer which establishment will sign, employ assigned staff, issue invoices or hold a particular certificate. The inclusion of /0001 and /0005 on the salary page is not proof that these are the only active establishments; its purpose and reporting threshold may determine which reports appear.

A procurement file should contain a recent registration certificate for the contracting establishment, the signatory's authority and an explanation of any different CNPJ used for staff or billing.

There are also discrepancies that deserve preservation rather than smoothing. SysMap'sabout pageand Salesforce directory indicate the company has operated since 1999. The public registry aggregator gives an opening date of 1991 for the matrix. Both can coexist if an older legal vehicle was renamed, acquired or reused, but the public evidence examined here does not establish that history. The corporate website currently shows '25 years' even as it also says 'since 1999', another reason not to convert a marketing counter into a legal timeline. A buyer for whom corporate continuity matters should ask for current consolidated articles and relevant amendments, not ask a brand timeline to do that work.

The official website publishes contact offices in Paraíso and Berrini in São Paulo and on Rua Antônio de Albuquerque in Belo Horizonte. The matrix address on the third-party corporate page matches the Paraíso contact, and the /0003 record matches the Belo Horizonte street. The /0005 record available through the same data provider does not simply mirror the current Berrini website address. This may reflect an office move, a registration lag or a distinction between contact and registered premises; there is not enough evidence to choose between them.

It is a small due diligence test but useful: ask which location and which establishment actually support the proposed service.

Finally, theGrupo SysMap careers pagestates that the group is formed by the brands SysMap Solutions, TriggoLabs and triggo.ai. The main site also calls TriggoLabs a spin-off and triggo.ai a startup in its ecosystem. A shared presentation does not establish that the assigned Ltda owns all related products, employs all group workers or will be responsible for every affiliate act. Similarly named special-purpose entities with different CNPJ roots appear in public corporate aggregations; they are outside this article's boundaries. If a proposal relies on intellectual property, staff or data service from a related company, that relationship belongs in the contract and subcontractor schedule.

A Catalogue Is Not an Architecture

SysMap's service catalogue is broad enough to resemble an architecture diagram. The main site advertises cloud work on Amazon Web Services, Microsoft Azure and Google Cloud; API gateway and management; microservices; chatbot and machine learning; RPA; e-commerce; CRM; blockchain; DevOps; analytics and business intelligence; Internet of Things and big data; systems integration; automated testing; service-oriented architecture and business process management; Docker and Kubernetes; custom web and mobile applications; and specialised IT services. Thespecialised services siteadds named competencies including Salesforce, ServiceNow, UiPath, Informatica, QlikView, Tableau, MicroStrategy, SAP, REST, ETL, ODI, Angular, React Native, Java,.NET, Node, Python, iOS and Android.

This establishes what SysMap is willing to sell. It does not establish a single SysMap platform, a proprietary reference architecture or current production depth in every named technology. The pages disclose no common control plane, supported version matrix, standard deployment topology, public API specification, service catalogue with response times or independently tested compatibility matrix. Some names describe cloud products, others programming languages, delivery practices, integration patterns or staff profiles. A partner logo can mean anything from formal tier to workforce familiarity unless the platform owner verifies it.

The right way to read the catalogue is as a menu of possible responsibility chains. Consider a Salesforce implementation connected via MuleSoft to a Java service, deployed alongside workloads in Azure and observed with a client's monitoring stack. Salesforce owns the core SaaS infrastructure. Microsoft owns specified cloud layers. SysMap can design and implement the configuration, custom Apex or Lightning code, integration flows, middleware, testing and deployment automation. The client may own identities, data classification, business rules, release approval and risk acceptance. Another vendor may operate the legacy endpoint.

Calling the whole 'managed transformation' does not make any party responsible for the complete business transaction.

Platform documentation makes this limit explicit. Salesforce's January 2026 explanation of itsshared responsibility modelstates that Salesforce secures the infrastructure while customers protect their data, configurations and access rights. Microsoft'sAzure responsibility tablesimilarly states that customers always retain responsibility for data, endpoints, accounts and access management, with application and network duties varying by IaaS, PaaS or SaaS. Google'scloud architecture guidancestates that the provider retains the underlying network and infrastructure while customers retain access policies and data; it also warns that incident duties can be hard to split between services.

An integrator can perform many of the customer's operational tasks, but a services engagement does not erase the customer's legal or platform-level position. If SysMap configures access, its specification should identify whether it designs controls, administers them, monitors them or merely advises. If it writes a microservice, acceptance should cover source, dependencies, deployment and recovery—not just a demo. If it operates an API, the agreement should define ownership, version policy, replay and idempotence, rate limits, log retention and liability for downstream failures.

If it builds an RPA bot, the buyer needs an exception queue, credential owner, manual fallback and a test showing what happens when the target screen changes.

Architecture evidence should therefore be delivered as a set of inspectable artefacts: system context and data flow diagrams, component inventory, platform and licence map, environment topology, identity and secrets model, dependencies and software bill of materials, repository map, build and release definitions, test strategy, observability design, recovery plan and decommissioning path. SysMap's breadth becomes valuable when a single team can maintain consistency across these artefacts. Without them, breadth is just a wider set of places where tacit knowledge can accumulate.

Five Contracts Under a Single Promise

SysMap's Salesforce page is unusually useful because it reveals that 'a SysMap engagement' can mean at least five different business and governance arrangements. It describes consulting that maps a current state to a future state; fixed-scope projects, often using an MVP; dedicated teams working remotely or in the client's environment using agile or waterfall methods; individual professional services; and specialised services or a centre of excellence covering support, testing, DevSecOps, architecture and data.

The wider recruitment site states that clients can choose an individual professional or a complete team and that SysMap selects for technical ability, behaviour and fit with the client's culture.

These models should not share a single undifferentiated dashboard.

In a consulting engagement, the deliverable is a decision asset. The buyer should define whether it receives process maps, architecture options, cost and risk assumptions, a sequenced backlog and an executable transition plan. SysMap may be responsible for the quality and traceability of the recommendation, but not for business outcomes that depend on subsequent implementation it does not control. To avoid an engagement becoming a funnel to a proprietary solution, the client should demand platform-neutral options and assumptions that another vendor can test.

In a fixed-scope project, responsibility should centre around functional increments and objective acceptance. 'MVP' is not in itself an acceptance criterion. The contract should identify business scenarios, non-functional requirements, data migration, integrations, security testing, rollback and documentation. Change control is necessary, but an overly narrow scope can turn ordinary discovery into a stream of paid change orders. The buyer should separate genuinely new requirements from omissions that competent discovery should have found.

In a team model, the client often owns the product backlog while SysMap provides capacity and some management. The careers page's promise of professionals who can work on-site or remotely, and the Salesforce page's reference to teams managed by SysMap, leave room for multiple control models. Who chooses the architecture? Who accepts the code? Can the client remove an individual? How quickly must SysMap replace a leaver with equivalent skills? Is onboarding billable? Are velocity and utilisation conflated with business outcomes? A team can be productive while the client accumulates unowned code and weak documentation.

Individual professional services move even more control to the client. They can solve a rare skill problem but also create questions of co-employment, continuity and knowledge concentration that require local legal advice and careful operating rules. The relevant deliverable may be accepted work rather than a named person's presence. A buyer should know whether SysMap or the client performs daily direction, performance management, training, access review and holiday cover.

Managed support reverses the emphasis. Here, availability of named systems, incident response, request fulfilment, change success, backlog age and recovery evidence matter more than story points. SysMap's portfolio describes an anonymised education client receiving 24/7 application support, incident and environment monitoring, task automation and reporting. It claims that ETL time dropped from 22 to 14 hours and incidents by 40%. These are selected first-party results with no disclosed denominator, measurement window, severity definition or current client confirmation.

They show what SysMap considers support work; they do not provide a reusable service level.

The proposal should name the model for each workflow. A significant programme may legitimately combine all five, but each needs its own owner, unit of measure, acceptance method, risk allocation and exit obligation. When a project moves from implementation to support, or a managed team becomes client-led staff augmentation, the responsibility matrix and pricing basis should change explicitly rather than by habit.

What Client Evidence Proves

SysMap's public client evidence has three layers, and they carry different weights.

The first is theclient logo page. It names companies in telecoms, media, education, industry, finance, retail, healthcare and insurance, including Telefônica/Vivo, Claro, TIM, Globo, Natura, Microsoft, Latam, Carrefour, Unimed and Fleury. This is first-party evidence that SysMap claims relationships. It is not a list of active contracts. The page gives no engagement dates, client legal entities, scope, business model or client approval statement. Legacy brands such as Nextel, NET and Fnac also appear, which strongly suggests the page mixes historical and potentially current work. A buyer should treat a logo as a lead for reference verification, not a certificate of recurring operations.

The second layer is SysMap'sportfolio. It describes a mobile sales activation system, 24/7 support for an education group, usability and commerce changes for a cosmetics company, automated testing for a loyalty programme, a new insurance front-end and integrations, and a microservices-based process platform. These cases contain more technical texture: Java, Oracle SOA, Informatica PowerCenter, SoapUI, Docker, Jenkins, Angular, Spring Boot and React appear in specific contexts. Multiple revenue figures are expressly anchored to 2016 or 2017, and most clients are anonymised. The cases can establish that the company has told a coherent story about certain types of work. They cannot safely establish current architecture, current scale or an ongoing client relationship.

The third and strongest layer combines named SysMap claims with external corroboration. The Salesforce landing page states that SysMap worked on Claro's omnichannel CRM, evaluated an American Tower integration between Salesforce and TIM's ServiceNow environment, used MuleSoft for Natura's e-commerce platform, implemented Salesforce workflows for Raízen and supported clients including Bridgestone and the Instituto Socioambiental. An independent project account from a former designer onClarostates that, while at SysMap, she worked on research and redesign of Claro's sales system, and that Claro approached Triggo Labs for a design thinking workshop. It corroborates a genuine delivery context while illustrating why brand boundaries matter: the design activity is described both through SysMap employment and Triggo Labs involvement.

Natura provides more consequential verification. A Natura/Avonsupplier announcementhosted by the client lists SysMap in the IT & Digital LATAM category of Natura's supplier recognition. The independent trade publicationTI Insidealso reported SysMap's role in combining Natura and Avon Brasil's direct sales technologies. SysMap's own account states that the work involved around 100 people across product, experience, engineering, commercial, testing, infrastructure and DevOps and includes a positive statement attributed to Natura &Co's Latin America CIO. External sources make the relationship and large project credible; the detailed team size, causal benefits and delivery mechanisms still come substantially from SysMap and should be verified by reference.

This evidence supports a narrow conclusion: SysMap has participated in complex enterprise deliveries involving client workflows, legacy integration and platform work. It does not prove that every logo represents a comparable engagement, that every project was delivered by the assigned Ltda rather than another group arrangement, or that SysMap continues to operate the resulting systems. For procurement, the most useful references would match the proposed model and failure surface: a fixed-price integration reference is weak evidence for 24/7 managed support; a client that received a staffed team is weak evidence for outcome-based delivery.

Reference calls should go beyond satisfaction. Ask who owned the backlog and architecture; what production privileges SysMap held; whether key people changed; how estimates and change orders behaved; what defects escaped; how incidents crossed the platform/integrator/client boundary; whether documentation matched the running system; and whether the client could replace the team. A reference that can answer these questions is worth more than ten logos.

Salesforce Is Evidence, Not a Proxy

The most independently verifiable part of SysMap's technology proposition is Salesforce. At time of access for this research, Salesforce'sAppExchange consulting directoryidentified 'SysMap Solutions Software e Consultoria Ltda', placed it at Crest partner level and displayed 129 Salesforce-verified projects and 92 certified experts. The listing described consulting and support; Apex and Lightning development; data processing and integrations with MuleSoft, Vlocity and Tableau; and delivery via individuals, teams or full projects. It also linked customer testimonials for Natura, Claro and Leroy Merlin.

This is stronger than a logo copied on SysMap's own site because the platform owner hosts the identity and defines the project and certification counters. It also clarifies the legal entity. But it is not a general quality seal. A verified project count does not disclose size, recency, budget, outcome, production longevity or incident history. A certified expert count is a signal of current capability, not a guarantee that those people are available for a buyer's team. The directory displayed 23 reviews but did not expose a usable aggregate rating in the page view examined here.

There is a revealing measurement difference. SysMap's own Salesforce page claims more than 400 specialised Salesforce professionals and more than 100 projects delivered, while AppExchange displayed 92 certified experts and 129 verified projects. These numbers are not necessarily in conflict. 'Specialised' is broader than 'holds a qualifying certification'; the company's threshold for a project may differ from Salesforce's verified project counter; and both can change over time. The due diligence response is not to pick the larger number.

It is to ask for a proposed team matrix showing for each person their employer, location, role, current relevant credentials, availability, language, client experience and replacement plan.

Nor should the Salesforce evidence be used as a proxy for cloud, data, UiPath, Informatica, AWS, Azure or Google Cloud. SysMap's main site displays these partner names, but the frozen evidence pack did not locate equivalent current platform directory entries for every logo. Individual employee credentials, when publicly visible, are not organisational accreditations. A buyer should verify each partnership in the platform owner's current directory and obtain the tier, legal member, competency, expiration date, relevant specialisations and whether the relationship confers support escalation or merely training and resale rights.

The Salesforce specialisation also creates a useful responsibility test. If the client chooses Salesforce because SysMap recommends it, platform lock-in and integrator lock-in must be separated. Salesforce controls the core service, release cycle and native export mechanisms. SysMap may control or influence custom entities, flows, Apex, Lightning components, MuleSoft integrations, CI/CD and operational procedures. The client should control the org, super-administrator recovery, data classification, business acceptance and the contractual relationship with Salesforce unless there is a documented reason not to.

A partner can facilitate platform adoption; it should not become the only path through which the client can understand or administer its own tenant.

People Are the Operating System

In outsourced transformation, labour is not an input hidden behind product. It is the operating system. SysMap's staff proposition explicitly sells the identification, selection, placement and performance management of specialists, individually or in teams. Its ability to deliver therefore depends on recruiting, retaining, replacing and supervising people across technologies and client contexts.

TheGrupo SysMap Gupy boardprovides a live but volatile signal. At time of access, it showed 66 open positions, including cloud, data and infrastructure roles as well as account management posts in São Paulo and Belo Horizonte. Openings may represent growth, replacement, future project, client demand or a perpetually open talent funnel; it is not an employee count. They show that the announced catalogue matches active skill demand rather than just a static brochure.

Aninfrastructure analyst listingis particularly instructive. It describes physical and logical data centre operations, monitoring with Zabbix, Grafana and Dynatrace, backup and restore across more than 2,000 servers, Windows, Linux, VMware and ITIL, and an uptime objective of 99.96%. The recruitment steps include a client interview. The assignment and client are not identified, so these server counts and uptime figures should not be presented as SysMap's own domain or enterprise-wide SLA. The role rather reveals the practical shape outsourcing can take: a worker recruited by SysMap may operate in a client-controlled environment and be evaluated by that client.

This arrangement creates three layers of management. The client may set day-to-day priorities and grant access. SysMap may employ or contract the professional, manage performance and replacement, and provide some technical direction. The worker holds much of the operational knowledge. If one layer assumes another documents decisions, reviews privileged access or prepares a successor, the service becomes person-dependent.

Anonymous employment reviews can add only weak context. Glassdoor hostsmixed employee testimonials, including comments on remote work, management and the experience of being close to a client. The sample, identities and representativeness cannot be verified, and different local pages displayed inconsistent review totals. This material should not support a conclusion about SysMap's culture or delivery quality. It may suggest questions: who mentors embedded staff, how often does an engagement manager review them, and what support exists when client and employer priorities diverge?

A serious proposal should make the labour control system measurable. For each key role, the buyer needs minimum skills, a named replacement, expected allocation, notice period, replacement time, knowledge transfer overlap and approval rights. It should track unplanned turnover, time to productive replacement, concentration of critical knowledge, training versus actual platform roadmap and recertification of privileged accounts. 'Equivalent replacement' should mean demonstrated skill in the client's system, not the same job title on a CV.

Local support can be a genuine advantage. A Brazilian team can work in Portuguese, understand local business practices and LGPD expectations, operate in compatible time zones and travel on-site if needed. These advantages are not automatic. They depend on where the named team is located, which entity contracts it, coverage schedules, employment model and escalation authority. Local labour becomes a sustainable capability when the client buys a managed system for knowledge preservation—not just access to whoever is available this month.

Governance at the Joints

SysMap says on its about page that it applies measures, productivity indicators and service level management, and uses a proprietary software production method that defines the documents generated, tools, references and developer activities. These are relevant claims because governance is the mechanism that could tie its service breadth together. The public pages do not disclose the method, standard documents, baseline metrics or an audit of their use. A buyer should ask to see anonymised samples then put the required artefacts in the specification.

The first governance layer is a business service map. It starts with client outcomes—such as completing an order, onboarding a seller or resolving a service request—and traces each through channels, CRM, integration, custom services, data stores and legacy systems. Every component should have a technical owner, business owner, support queue, monitoring source, change authority and recovery action. This prevents platform availability from being confused with workflow availability.

The second layer is an executable responsibility matrix. 'Responsible' is too broad unless paired with control. A party cannot be responsible for database restoration if it cannot access backups, nor for API performance if another vendor controls capacity. Each row should identify the decision right, production privilege, evidence produced, time obligation and escalation. Shared rows need a named incident commander. The matrix should cover design, build, test, deploy, operate and retire—not stop at go-live.

The third layer is outcome-based acceptance. Brazil's Federal Court of Accounts provides a useful reference even for private buyers. InAcórdão 1752/2025, the TCU criticised software development payments that were not proven by delivered results and discussed models that combine managed capacity and service levels. The decision concerns public procurement and a different vendor; it is not a rule that automatically governs a private SysMap contract. Its economic lesson is portable: paying for activity without an independently verifiable definition of accepted deliverable transfers delivery risk to the buyer.

For fixed-scope work, acceptance can be attached to business scenarios, data reconciliation, security and performance thresholds, recovery, documentation and deployment. For a team, the buyer may buy capacity, but payment or renewal can still reflect quality, timeliness, escaped defects, rework, knowledge health and agreed service levels—not gross utilisation. For support, severity definitions, response, restoration, communication, root cause analysis and problem elimination should be measured separately. A fast acknowledgement is not a restored service; a closed ticket is not an eliminated cause.

The fourth layer is the economics of change. Architecture decisions, backlog changes and platform releases should leave a trace of who decided, alternatives considered, impact on security and data, recurring cost, reversibility and required documentation. The client should be able to distinguish changes driven by its business from correction of a deficient deliverable and from mandatory platform evolution. Otherwise, a seemingly flexible engagement can monetise ambiguity.

Governance should be proportionate, but it must be real. A two-week discovery does not need bureaucracy designed for a banking migration. It still needs named decisions, accepted artefacts and ownership. SysMap's promise of a broad, managed path is only credible if the client can inspect that path without depending on the same people who built it.

Price Is Spread Across Three Ledgers

SysMap does not publish a standard price card, contract template, rate sheet or support tariff in the pages examined. This is normal for enterprise services, but it prevents an outside observer from calculating value or comparing offerings. The relevant business model has at least three ledgers: SysMap services, platform and cloud fees, and retained client work.

The services ledger changes by engagement. A fixed-scope project may bundle discovery, build and acceptance into milestones, with SysMap bearing some estimation risk. A team or individual placement is more likely priced around capacity and role, though the public material does not disclose SysMap's actual billing units or rules. Managed support may use a recurring base plus volumes, coverage and projects. Consulting may be time-capped or deliverable-based. The buyer should not accept a blended total that hides which risk it is buying.

The platform ledger can be larger and more persistent than implementation fees. Salesforce editions, additional clouds, MuleSoft, analytics, security, backup, sandbox and support products can create recurring commitments. Public cloud adds consumption, network data transfer, observability and support. SysMap's page mentions platform licence management in some support work, but does not disclose whether SysMap resells, administers or merely advises on licences in a typical contract.

The buyer needs direct visibility on quantities, discounts, renewal dates, minimum terms, price adjustment mechanisms, unused capacity and any partner margin or discount that might affect advice.

The retained work ledger is often omitted. Business experts must define rules and validate outcomes. Client security teams approve access and risk. Legacy owners support interfaces. Procurement manages platforms. Data owners resolve quality. Operations staff participate in handover. If a low service quote assumes substantial client work, it may cost more than a higher, truly managed proposal. Conversely, paying SysMap to perform a task the platform already includes can duplicate costs.

Scenario pricing exposes these interactions. Buyers should ask for three-year cost in a baseline scenario, faster growth, delayed migration, higher transaction volume, after-hours support, major platform release, acquired company, team turnover event and exit at each contract anniversary. The model should show licences, consumption, roles, overtime, travel, environments, test data, data transfer, training, change budget and transition assistance. Assumptions should be editable and prices linked to a public index or defined tariff rather than unilateral review.

Unit economics should follow the workflow. For automated testing, cost per reliable release and escaped defect reduction matter more than scripts run. For RPA, use cost per successfully completed case after exceptions and supervision, not bots deployed. For an API programme, measure stable consumer integration, change failure and recovery. For a support service, track business minutes restored and recurring causes eliminated. These are buyer-designed metrics, not SysMap claims already contracted on.

The absence of public pricing is therefore not the main evidence gap. The larger question is whether SysMap will make cost drivers and responsibility transfers readable before signature. Pricing transparency is a governance control: it discourages architecture that is cheap to launch but expensive to change.

Exit Starts Before Implementation

Enterprise lock-in has at least four sources in a SysMap engagement. Platform lock-in comes from the chosen SaaS or cloud. Customisation lock-in comes from data models, code, flows and integration conventions. Operational lock-in comes from runbooks, monitoring and incident knowledge. Labour lock-in comes from the people who remember why the system behaves as it does. A client may own its data and still be unable to operate or modify the service.

Salesforce illustrates the difference between theoretical and usable portability. Itsdata export FAQstates that a org can generate export files weekly or monthly depending on edition, that large exports may take time, that files are available for 48 hours, that recycled data is excluded and that formula and summary fields are not included in exports. Attachments and files require the corresponding options. This does not make Salesforce particularly difficult; it shows why 'data is exportable' is not an exit plan. A CSV dump is not equivalent to metadata, configuration, code, relationships, attachments, audit history, integration state and a tested import into a replacement.

The client should own or have independent administrative recovery for every tenant and relevant cloud account. Source code and infrastructure definitions should reside in client-controlled repositories or be continuously mirrored with full history. The client needs build scripts, deployment pipelines, dependency manifests, environment variables without exposed secrets, interface specifications, data dictionaries, test suites and results, architecture decisions, product backlog, incident and problem records, capacity baselines, licence inventory and support contacts. Rights on custom code and third-party component licences must be explicit.

Knowledge transfer cannot be a last-week presentation. The TCU's currentcontract termination guidelinescatalogue public-sector cases in which limited public evidence transfer created risk of discontinuity, loss of essential information and difficulty in recovering client resources. Again, this is not a finding about SysMap and does not automatically govern a private transaction. It captures the universal operational risk: if the outgoing team is the only party able to explain the system, the client does not own a usable service.

A better model transfers knowledge continuously. Client staff or a second independent vendor should be able to deploy a non-production environment, restore data, rotate credentials, trace a failed transaction and execute a release from the documented process. Runbooks should be tested by someone who did not write them. Key person maps should identify where no substitute exists. Transition deliverables should be reviewed quarterly, not created after notice.

The exit clause should define a transition period, capped fees, cooperation with a replacement, continuing service levels, access preservation, data and artefact formats, deletion certification, subcontractor exit, licence assignment where possible and resolution of work in progress. It should distinguish termination for convenience, for vendor default, for platform abandonment and for insolvency. It should also require an early exit rehearsal: export a representative data and file set, recreate a selected configuration, build the code from a clean environment and have a different team operate the service for one day.

A client ready to exit may never leave SysMap. That is not wasted cost. Portability improves daily resilience, makes replacement safer and forces both parties to know what the service consists of. The best evidence of low integrator lock-in is not a promise of cooperation; it is a recent successful rehearsal.

Security Needs a Three-Party Clock

SysMap's public security evidence is thinner than its technology catalogue. Its main privacy policy page states it was updated on 26 June 2025, but much substantive text did not render as readable content in the page examined. A separateSSG app privacy noticeis more specific. It describes an internal support management system used by professionals and potential clients, collection of employment, identification, financial, device and interaction data, login with credentials and a two-factor token, optional device biometric validation via a token, access logging, restricted access and encryption or equivalent protections. These are company statements about one application, not an independent security assessment of client delivery.

No current public ISO 27001 certificate, SOC report, organisation-wide penetration test attestation, vulnerability disclosure programme, service status history or incident post-mortem for SysMap was identified in the frozen public evidence. Salesforce partner status and individual platform credentials do not fill this gap: they test platform experience, not the operational effectiveness of SysMap's corporate security controls. The absence from the public pack is not proof that the artefacts do not exist or that no incident has occurred. It means a buyer must obtain and validate them under confidentiality.

The chain of responsibility matters under Brazilian data protection law. TheLGPDdistinguishes controller and processor duties, requires technical and administrative security measures, and requires the controller to communicate incidents that are likely to pose a relevant risk or harm. The ANPD's currentincident guidelinesstate that confirmed qualifying incidents must be reported by the controller to the authority and affected persons within three business days, subject to specific rules and risk criteria.

These roles depend on facts and contracts. A client may be controller for customer and employee data; SysMap may be a processor for part of the processing; Salesforce or a cloud provider may be another processor or sub-processor. SysMap may also be a controller for its own HR system. A single event may cross all these relationships. The agreement therefore needs a clock that starts before the legal deadline: who detects, who preserves evidence, who notifies whom, in how many hours, who decides materiality, who communicates externally and who pays for investigation and remediation.

The client cannot meet a three-business-day deadline if an integrator is allowed to wait three days before informing it.

Cloud and SaaS certifications must also be allocated, not inherited. A platform's certification applies to its service and defined controls. It does not certify SysMap's custom code, configuration, administrator practices, laptop security or integration endpoints, nor does it certify the client's processes. The buyer should map every required control to evidence from the platform, from SysMap or from itself. Where SysMap relies on a cloud provider's control, it should provide the current report and the client responsibility matrix for the actual service.

Practical diligence includes an inventory of data flows and sub-processors; background checks and access controls for embedded staff; secure development and dependency management evidence; secrets management; code and configuration review; development and production duty separation; client-accessible logging; backup ownership and restoration tests; vulnerability remediation targets; endpoint management; business continuity; cyber assurance; breach history; and a recent tabletop exercise involving the platform provider. Claims should be tested on the proposed architecture, not accepted at group level.

Security is where the empty responsibility box becomes dangerous. Each party may sincerely say it secures its layer while the combined workflow remains exposed. The buyer needs an end-to-end control map and an incident commander for every scenario.

Availability Is Not a Single Number

SysMap markets support and cloud services in the language of security, performance and availability. Its anonymised education case describes 24/7 support and incident monitoring. The infrastructure role mentions an uptime objective of 99.96%. Neither is a SysMap public service level schedule. The case lacks definitions and current verification; the role may describe a client environment and expressly includes a client interview in recruitment.

Availability for an integrated enterprise workflow cannot be reduced to cloud provider availability. A CRM page may load while an order integration fails. An API may return 200 while downstream data is rejected. A bot may be online while its credentials are expired. A data pipeline may finish after the business deadline and still be 'successful'. The contract should define indicators at the user or business transaction level, then decompose them into components.

Incident records should distinguish detection, acknowledgement, diagnosis, workaround, restoration and permanent fix. Severity should reflect business impact, affected users, data risk and regulatory consequence, not the vendor's estimate of technical complexity. Monitoring data should be shared in a client-owned dashboard or exportable format. The client should have the right to open and track platform vendor cases that affect its service, even if SysMap leads the escalation.

Recovery claims require drills. Ask for the last restoration test, what was restored, from which point of failure, by whom, against what recovery time and recovery point objectives, and whether application consistency was verified. For microservices and APIs, test partial failure, duplicate messages, backlog replay and incompatible change. For CRM, test loss or corruption of configuration as well as data. For staff-dependent support, test absence of a key person.

There is no credible public base in this evidence pack to calculate SysMap's failure frequency or mean time to restore. Nor is there credible public disclosure of a material security incident at SysMap. These statements describe the boundaries of the evidence, not a clean bill of health. A buyer should ask for a multi-year incident and service level history for comparable work, with client-confidential details anonymised, and reconcile it to credits, root cause analysis reports and renewal references.

The most important availability metric may be transferability: how long would a qualified replacement take to understand and restore the service? If the answer depends on an architect's memory, nominal availability has a hidden fragility.

The Alternative Is a Different Boundary

SysMap competes with global systems integrators, Brazilian consulting firms, platform specialists, staff augmentation firms, managed service providers and clients' internal teams. It also competes with a more modular procurement strategy in which one vendor implements the CRM, another manages cloud infrastructure, a specialist handles data, and the client retains architecture and service integration in-house. The relevant substitute is not always another company with the same catalogue. It is a different division of responsibilities.

Brazilian market data shows why multiple models can be viable. Cetic.br reported that 31% of all surveyed companies used a CRM in 2025, rising to 56% among companies with at least 250 people in itsCRM table. Itscloud services tablereported that among companies with internet access, 26% paid for a hosted development, test or deployment platform; the share was 45% in the largest size band. These are not forecasts or SysMap customer statistics. They show substantial addressable need and also a population of clients mature enough to compare platform, integrator and internal options.

SysMap's potential advantage is the combination: a single business relationship can provide premises, custom development, Salesforce depth, integration and support. This can reduce coordination costs if SysMap accepts end-to-end service integration and has authority over the necessary components. If the contract excludes platform failures, client configurations, legacy behaviour, third-party APIs and business data while charging for a managed outcome, the combination is cosmetic.

A global integrator may offer broader geographic coverage, industry assets and balance sheet scale, but may be expensive and layered. A boutique may offer deeper platform expertise and senior attention but less capacity or 24/7 coverage. Direct contractors may be cheaper and transparent but leave management and continuity to the client. An internal team preserves knowledge and control but bears recruiting and training costs. Platform-native services may reduce interpretation risk but may not own legacy integration or ongoing operations.

The buyer should compare operating models using the same workflows and failure scenarios. Give each bidder an anonymised architecture, representative integration, change request, incident scenario and exit requirement. Ask who decides, who acts, what evidence is produced, how long it takes and how much it costs. Compare the proposed named team and subcontractors, not brand scale. Note the amount of client coordination required as a cost.

SysMap should win where its interdisciplinary delivery actually closes the joints: a named service owner, consistent artefacts, platform escalation, local operational coverage and low-friction handover. It should not win simply because its logo wall contains all the technologies in the diagram.

A Procurement Test Built Around Handover

A defensible SysMap procurement can be organised as a sequence of evidence rather than a request for generic references.

First, fix identity and authority. Obtain recent CNPJ certificates for the signing and billing establishments, consolidated corporate documents, signatory powers, financial and litigation checks appropriate to risk, and a list of affiliates or special-purpose entities involved. Map every proposed worker, platform contract, subcontractor and processing sub-processor to a legal party. Confirm that current partner references belong to the contracting entity or document the group arrangement.

Second, choose the engagement model before pricing. Label each workflow: consulting, fixed scope, managed team, individual professional service or managed support. State who owns product direction, architecture, delivery acceptance, production operation and business outcome. Reject proposals that use 'agile' or 'co-creation' to leave these decisions undefined.

Third, require comparable evidence. Ask for two references using the same platform, scale, industry constraints and business model. Get client permission to verify scope, team continuity, service history, change behaviour and exit readiness. Inspect anonymised deliverables from SysMap's claimed methodology. Verify each platform reference in the owner's directory and link named certified staff to the proposal.

Fourth, run a paid, limited proof. Use a non-productive slice containing a legacy interface, representative data rules, automated tests, logging and a controlled failure. Measure how the team discovers requirements, documents decisions, secures access, estimates work, exposes uncertainty, deploys, diagnoses failure, restores and hands the result to someone else. The proof should end with another engineer rebuilding from artefacts.

Fifth, contract the control plane. Tenants, repositories, domains, keys and monitoring belonging to or independently recoverable by the client should be the default. The specification should list deliverables and acceptance, service levels, coverage, escalation, platform support, security controls, data roles, sub-processors, audit rights, incident notice, vulnerability remediation, backup and recovery, intellectual property, licence obligations, open source components and continuous knowledge transfer. Attach the responsibility matrix and business service map.

Sixth, price change and exit. Obtain rate cards and scenario costs, cap or define transition fees, and prevent a notice period from disabling access to essential artefacts. Require periodic exports and restoration tests, a clean build test, up-to-date documentation and cooperation with a replacement. Tie part of final acceptance or recurring review to transition readiness.

Seventh, govern with evidence. A joint forum should review business service levels, defect escape, recurring incidents, change failure, cost forecast, platform consumption, security actions, staff changes, knowledge concentration and exit health. Minutes should record decisions and owners. Executive satisfaction should not override failing controls, and a green dashboard should not hide missing data.

This test does not assume SysMap will fail. It gives a competent integrator a way to prove its breadth is controlled. It also protects SysMap from being blamed for duties the client or platform retained. Responsibility works in both directions.

The Unanswered Diligence File

Several important questions remain unanswered in public evidence.

The legal history between the reported matrix opening in 1991 and the brand operating claim in 1999 is not documented in the sources examined. The role of the /0005 establishment, the correspondence between current offices and registrations, and the legal relationships between SysMap Solutions, TriggoLabs and triggo.ai require current corporate documents. The public client page does not separate recurring active clients from completed historical projects.

Beyond Salesforce, current partner tiers, certified staff totals and formal competencies were not independently verified for every logo. The public evidence does not disclose SysMap's revenue, profitability, client concentration, insurance, employee and contractor totals, turnover, bench capacity, delivery utilisation or financial exposure to a major platform. These affect continuity and pricing but cannot be inferred from vacancies or marketing counters.

There is no public standard architecture, supported version policy, product roadmap, API specification, SLA, service credit schedule, price card, DPA, sub-processor list, software security assurance pack, disaster recovery result, organisational security certificate, incident history or client exit specification in the examined pack. Some may be available in confidential procurement. Until they are inspected, they remain unknowns rather than negative findings.

The named cases also leave attribution questions. Which SysMap legal entity signed? Which parts were designed by TriggoLabs or another group team? What third-party platforms and client teams contributed? What outcomes were measured independently, over what period and against what baseline? Does SysMap still operate the service? A good reference process can answer these without disclosing client secrets.

Post-signature monitoring points should include changes in Salesforce partner metrics; substitutions of named team; vacancy patterns in critical roles; new establishments or closures; changes in group structure; material platform concentration; repeated change orders around the same requirement; ageing incidents; delayed documentation; failed restoration or clean build tests; client access to repositories and tenants; unresolved security actions; and any divergence between billed capacity and accepted outcomes.

The evidence base should also be refreshed. Partner directories and job boards are live. Corporate addresses and CNPJ status can change. Salesforce export capabilities and platform responsibilities evolve. Security and privacy rules may be amended. A diligence pack that was accurate at selection may be stale by renewal.

Uncertainty is not a reason to reject SysMap. It is a reason to place unanswered items on an evidence schedule with owners and deadlines. The dangerous state is not 'unknown'; it is an unknown that silently becomes the client's liability after go-live.

The Contract Is the Integration Layer

SysMap has credible evidence of a genuine Brazilian software and consulting operation, a legally connected set of establishments, a broad delivery catalogue, active technical recruiting, named enterprise work and a substantial, platform-verified Salesforce practice. This is enough to warrant serious consideration. It is not enough to treat 'digital transformation' as a single managed outcome.

The company's strategic opportunity is to make responsibility itself a service. Its combination of local labour, custom engineering, platform expertise, integration and support can be more valuable than any single capability if a client receives a coherent operating model. The same combination becomes a liability when every layer is described as someone else's dependency.

The decisive artefacts are mundane: a current legal certificate, a named team, an end-to-end service map, accepted code, client-controlled tenants, a tested data export, a clean build, a usable runbook, an incident clock and a transition rehearsal. They determine whether the buyer owns a functional capability or merely rents access to people who understand it.

At 2:07 a.m. on that hypothetical Monday morning, there should be no empty box. The platform provider should know its layer, the client should retain its decisions, and SysMap should have the authority, evidence and obligation to do exactly what the contract says. If procurement can prove this before go-live—and prove the client can still operate when the team changes—SysMap's breadth is an asset. If not, partner logos are decoration around an unresolved risk.