Key Takeaways
A ticketing system routes requests through a queue. A help desk adds knowledge, self-service, and customer experience on top of that queue. The question most support teams think they're asking — "which tool do we buy?" — is the wrong question. The real question is whether your support operation will compound with every resolved issue or scale linearly with every new customer, brand, and region.
- Ticketing systems cost $15–50 per agent per month but resolve nothing on their own — volume grows in lockstep with customer count because the system has no way to prevent future tickets
- Help desk software costs $50–150 per agent per month and adds knowledge, self-service, and customer portals — but per-agent pricing locks out the subject matter experts who have the best answers
- Companies running 3+ brands with separate ticketing instances per brand spend 2–3× more than they should on licensing while maintaining duplicate knowledge that drifts within six months
- The "internal vs external" question most teams ask is a symptom of fragmented knowledge — one unified foundation with audience filters serves both use cases from one platform
- Unified platforms with usage-based pricing reach 40–60% ticket deflection within 90 days because knowledge work and customer support share the same foundation
- Teams move from ticketing to unified support in 4–6 weeks without losing data or historical context — the old system stays connected as a reference during transition
Research Methodology: Data compiled from MatrixFlows analysis of 500+ support operations across global high-tech and SaaS companies (2023–2024), combined with Forrester Research Total Economic Impact studies (Q3 2024), Gartner Market Guide for Customer Service Solutions (2024), and Zendesk Customer Experience Trends Report 2024.
Your Agents Answered 487 Support Questions Last Week
Next week they'll answer the same 487. Different customers. Same questions. The ticketing system tracks every one — creation time, priority, assignee, resolution time, customer satisfaction score. It measures everything about how tickets move through the queue. It measures nothing about why the queue never shrinks.
That's not a process problem. It's an architecture problem. A ticketing system is built to route and resolve individual requests. It isn't built to prevent the next thousand. When you compare help desk vs ticketing system options, you're not comparing two products that solve the same problem — you're comparing two products that solve different problems, and most teams are running the wrong one.
You've already tried the obvious fixes
Hired more agents. Added SLA automation. Bought a chatbot and bolted it onto the ticketing system. Rewrote the canned responses. None of it moved the ticket volume down.
Because the fixes assume the problem is processing speed. The problem is that every resolution creates knowledge that should prevent the next ticket — and the ticketing system has nowhere to capture it, no way to surface it to the next customer asking the same question, and no way to turn it into self-service that works.
You're experiencing this if:
☑ Your team resolves the same 20 questions every week, with different customer names attached
☑ Agent ramp time is 60–90 days because tribal knowledge lives in senior agents' heads
☑ The AI chatbot you deployed in 2023 hallucinates and customers have learned to bypass it
☑ You're running separate ticketing instances for internal IT and external customer support
☑ Every new brand, product line, or region means another support tool and another backlog
☑ Support costs are up 35% year over year and self-service deflection sits below 25%
☑ Leadership asks when AI will "fix support costs" and you can't answer the question
This article is for you if
You're a Director or VP of Customer Support, Customer Experience, or Customer Enablement at a global high-tech or enterprise SaaS company. Your team serves customers, installer partners, and service technicians across multiple regions. You're evaluating help desk software against ticketing systems and wondering whether either option actually solves the compounding cost problem. If this describes your situation, the comparison you need isn't feature-by-feature — it's architectural. The tool you choose determines whether every new customer makes you busier or better.
What a Ticketing System Actually Does
A ticketing system converts unstructured support requests into structured workflow records. An email, chat, or form submission becomes a ticket with an ID, an owner, a status, a priority, and a resolution timestamp. The system tracks it through to close, measures it against SLAs, and reports on volume and velocity.
That's the full scope. Tickets come in. Tickets go out. Reports quantify the throughput.
What ticketing does well
For internal operations where the audience is known employees and the workflow is predictable, ticketing is the right tool. An IT team handling 200 laptop requests a month, a facilities team managing conference room bookings, a dev team fielding internal bug reports from product managers — all have stable, bounded processes that benefit from structured routing and tracking.
Pricing reflects the narrow scope. Jira Service Management, Freshdesk, and Linear all sit in the $15–50 per user per month range. Setup takes days, not weeks. Integration with development tools works smoothly because that's the use case the platforms were designed for.
Where ticketing breaks for external customer support
Once the audience includes external customers, the ticketing model starts failing in ways that compound. Four failure modes matter:
No self-service layer. Ticketing systems have no built-in knowledge base, no customer portal, no AI assistant. Every question from every customer becomes a manual interaction, even when 60% of them are variations of the same ten problems.
No knowledge capture. When an agent solves a complex issue, the resolution stays in the ticket record. The next customer with the same problem gets routed to a different agent who starts from zero, because the system has no architecture for turning ticket resolutions into reusable knowledge.
Unprofessional customer experience. Generic submission forms, limited branding, no status transparency. Customers submit a ticket into what looks like a black box and wait.
Linear cost scaling. Because volume never decreases, support headcount scales directly with customer count. Revenue 4×, support costs 4×. Gross margin doesn't improve with scale.
⚠️ REALITY CHECK: A ticketing system measures how fast your team moves tickets. It does not measure — and cannot improve — whether your team should be moving those tickets at all.
What Help Desk Software Actually Adds
Help desk software starts with ticketing and layers on what the ticketing model is missing for customer-facing support: a knowledge base, a customer portal, multi-channel communication, self-service capabilities, and basic AI. The category includes Zendesk, Salesforce Service Cloud, Intercom, HubSpot Service Hub, and the tier-above versions of Freshdesk and Jira Service Management.
The bet help desk software makes is that customer support is fundamentally different from internal IT workflow. Customers expect branded experiences, self-service options, and transparency. Agents need knowledge at their fingertips, not buried in historical tickets. Leadership needs deflection metrics, not just resolution time.
What help desk software does well
Self-service reduces ticket volume 30–50% when the knowledge base is well-maintained. Branded customer portals let customers track their own requests without calling. Multi-channel unification keeps conversation context intact across email, chat, and phone. AI-assisted response drafting speeds up agent work on common issues.
For a single-product company with a single audience and a single brand, a standalone help desk platform is a real step up from ticketing.
Where help desk software breaks at scale
Three failure modes show up once the operation gets complex:
Per-agent pricing punishes participation. At $50–150 per agent per month, the people with the best answers — engineers, product managers, solution architects, senior technicians — can't participate in knowledge creation or ticket resolution without triggering additional licenses. Knowledge quality drops to the ceiling of what the licensed agents can write, not what the collective organization knows.
Knowledge lives separately from work. Most help desk tools treat the knowledge base as a feature bolted onto the ticketing core. Technical teams document in Confluence, Notion, or SharePoint; support teams then copy, paraphrase, or summarize that content into the help desk KB. The two layers drift. Updates in one don't propagate to the other. Customers read help desk content that's a quarter behind reality.
Multi-brand, multi-audience operations force duplication. A help desk platform designed for one brand and one audience doesn't cleanly handle five brands serving customers, installers, service technicians, and internal agents across four regions. Teams end up spinning up separate instances per brand — and paying per-agent fees on each instance. Costs multiply before deflection improves.
🎯 KEY DIFFERENCE: Help desk software is better than ticketing for external customer support — but the architecture still assumes knowledge and support are separate problems solved by separate systems. In a multi-brand, multi-audience operation, that assumption is what makes costs climb.
Help Desk vs Ticketing System: The Comparison That Actually Matters
The feature-by-feature comparison you'll find in most guides treats this as a shopping decision. Here's the version that reflects what's actually different.
| Dimension | Ticketing System | Help Desk Software | Unified Knowledge-Driven Platform |
|---|
| Primary unit | The ticket | The ticket, with KB attached | The knowledge record |
| Scales with | Headcount (linear) | Headcount + KB content (linear with some plateau) | Knowledge foundation (compounds) |
| Typical pricing | $15–50/agent/month | $50–150/agent/month | Usage-based, unlimited users |
| Who can contribute knowledge | Licensed agents only (where KB exists) | Licensed agents only | Anyone in the organization |
| Self-service deflection ceiling | 0–15% | 30–50% | 60–80% |
| Multi-brand handling | Separate instances per brand | Separate instances per brand | One foundation, branded surfaces |
| Multi-audience handling | Separate workflows or instances | Separate KBs per audience | One foundation, audience filters |
| AI quality | Poor (no knowledge to reference) | Variable (depends on KB completeness and drift) | Strong (structured foundation grounds every response) |
| Integration complexity | Low (narrow scope) | High (needs KB, CRM, chat, AI integrations) | Built-in (one platform, one data model) |
| Where it breaks | When external customers arrive | When brands, audiences, or regions multiply | When the foundation isn't maintained |
The table lays out the trade-off the category names obscure. Ticketing wins on price until self-service becomes necessary. Help desk software wins on customer experience until multi-brand and multi-audience complexity hits. Unified platforms win on compounding economics when the operation is big enough to benefit from one foundation — and in global high-tech, that's already the operating reality.
When ticketing is genuinely the right answer
Small internal IT teams with fewer than 20 known stakeholders, handling predictable request types (password resets, laptop requests, access provisioning), with no plans to add external customer support. For this profile, a ticketing system does exactly what's needed and nothing more. Upgrading to help desk software adds cost without adding value.
When help desk software is the right answer
Single-brand, single-audience customer support operations under about 10,000 tickets per month, with a stable product portfolio and no plans for multi-brand or multi-region expansion. At this scale, the help desk model's architectural limits haven't started producing real costs yet. The benefits of a professional customer portal and self-service KB outweigh the per-agent pricing friction.
When neither is the right answer
Global high-tech operations with 3+ brands, multiple audiences (customers, partners, installers, service techs), multiple regions, and 15,000+ monthly tickets. At this scale, the help desk vs ticketing system comparison stops being relevant — both architectures fail for the same reason: they treat knowledge and support as separate systems. The operation needs one foundation, not a better queue.
Internal vs External Help Desk: Why Companies Buy Two Systems and Regret It
A question that surfaces in almost every support platform evaluation at mid-market and enterprise high-tech companies: do we need separate systems for internal IT and external customer support? The traditional answer is yes — Jira Service Management for IT, Zendesk for customers, integrate them somehow, done. The traditional answer also produces the operational pattern where every significant problem has two knowledge bases, two workflows, two sets of SLAs, and two places to look for the same answer.
What internal and external actually mean
Internal help desk serves employees. The requests are about IT access, software licenses, hardware, facilities, HR questions, internal tooling. The audience is bounded and known. The workflow is predictable. The SLAs are looser — employees wait for password resets; customers do not.
External help desk serves customers. The requests are about product usage, troubleshooting, billing, account management, technical configuration. The audience is unbounded and unknown until each ticket arrives. The workflow has to handle variance. The SLAs are tight because customer satisfaction depends on them.
Those are real differences. They've led most companies to assume two different tools are required. The assumption doesn't hold up when you look at where the work actually overlaps.
Where internal and external support share infrastructure
Four places, and in a global high-tech operation each one matters:
- Product knowledge. Internal IT supports customers who use the company's own products. External customer support answers questions about the same products. The source of truth — how the product works, what changed in the latest release, how to troubleshoot issue X — is the same. Running two knowledge bases means updating in one and watching the other drift.
- Agent escalations. External support agents escalate complex customer issues to engineering, product, or specialized internal teams. The escalation crosses the internal/external boundary. When the two systems don't share infrastructure, the handoff loses context, the resolution loses trace, and the learning never gets back to the customer-facing layer.
- Cross-functional feedback loops. The patterns in customer tickets carry signal for product, engineering, and documentation teams. When customer support sits on a system that internal teams can't access without a license, the feedback loop breaks. Product never sees what customers actually struggle with. Documentation never learns where the gaps are.
- Multi-audience workflows. Installer partners, service technicians, and distribution partners are neither strictly internal nor strictly external. They sit in between — credentialed, trained, but not employees. Two-system architectures force a choice that doesn't fit the reality. Partners end up either in the external help desk (and missing the access to internal context they need) or in the internal system (and breaking the access controls it was designed for).
The hidden cost of two systems
The sticker price of running Jira Service Management for internal IT and Zendesk for external customers is the start, not the end. The full cost stack for a 200-person mid-market company typically looks like this:
- Jira Service Management — $20/agent × 15 agents = $300/mo
- Zendesk Suite Professional — $115/agent × 20 agents = $2,300/mo
- Confluence (internal KB) — $10/user × 200 users = $2,000/mo
- External KB / help center tool — $500–1,500/mo
- AI chatbot layer — $1,000–3,000/mo
- Integration middleware (Zapier, Workato, custom) — $500–2,000/mo
- Engineering time maintaining the integrations — 10–20 hours/month at loaded cost
Total: $8,000–12,000 per month in visible spend, plus the engineering overhead. And that's before the invisible cost — the drift between the internal KB and the external help center, the handoff friction between teams, the duplicate work when a product update requires four places to be edited.
The alternative: one foundation, audience-filtered surfaces
The architecture that eliminates the internal-vs-external question separates the knowledge foundation from the delivery surface. One canonical knowledge base holds product information, troubleshooting procedures, policy documentation, and process records — tagged by audience, brand, product, and region. The internal employee hub, the customer help center, the partner portal, and the service tech workspace are each surfaces that query the same foundation with their own filter rules and branding.
When a product update ships, the knowledge record updates once. Every surface — internal and external — gets the current version automatically. When a customer support agent resolves a complex issue, the resolution becomes part of the foundation and is immediately available to the internal escalation team, the partner portal, and the customer self-service layer. When an engineer documents a new configuration in the internal system, customer support can surface it in the external help center with a single audience tag change.
Same knowledge, multiple surfaces, one maintenance burden. That's what makes knowledge-driven support compound instead of scatter.
When two systems actually make sense
Two scenarios genuinely require separation: (1) strict regulatory compliance that mandates data segregation between internal operations and customer-facing records, and (2) organizations where internal IT and external customer support are owned by entirely separate business units with no operational overlap. Outside those cases, the two-system pattern is an artifact of tool limitations, not a requirement of the work.
Why Unified Platforms Are the Direction the Category Is Moving
The help desk vs ticketing system comparison is framed as a choice between two established categories. The categories themselves are being reshaped. The companies publishing the strongest economics in customer support right now — the ones showing declining cost per resolution quarter over quarter while volume grows — aren't running better ticketing or better help desks. They're running unified platforms where knowledge, work, and AI share the same foundation.
Three forces make the shift structural, not a passing trend:
AI only works when the knowledge foundation is structured
Every vendor in the support category ships an AI agent now. The gap between the demo and the production result is almost entirely explained by the state of the underlying knowledge. On a clean, structured foundation, AI resolves 40–60% of incoming questions with accurate, current answers. On a fragmented foundation — help desk KB drifted from Confluence, different brands with different taxonomies, knowledge scattered across Slack — the same AI hallucinates, contradicts itself, or fails to answer at all.
Teams that deployed AI chatbots on standalone help desk platforms in 2023 learned this the expensive way. The AI wasn't the problem. The foundation under it was. Unified platforms that structure the foundation as a first-class layer solve the root cause that bolt-on AI can't reach.
Unit economics only improve when knowledge compounds
Hiring more agents scales support linearly — every thousand customers costs the same incremental support load as the last thousand. Automation makes linear scaling cheaper but doesn't change the shape of the curve. Only enablement — customers, partners, and employees finding answers without agent involvement — breaks the linear model. Enablement requires a knowledge foundation that gets more complete and more accurate with every resolved issue. Help desk software treats knowledge as a feature; unified platforms treat it as the product.
Multi-audience operations can't be served by single-audience tools
Global high-tech operations that serve customers, partners, installers, service technicians, and internal teams need infrastructure that wasn't designed assuming one audience. The multi-audience architecture that serves all of them from one foundation is a different category of product than the single-audience help desk tools that dominated 2015–2020. That architecture is what MatrixFlows is built on: one knowledge foundation, multiple branded surfaces, audience-filtered access, and unlimited users contributing without per-seat friction.
How to Decide What Your Team Actually Needs
The answer depends less on current volume and more on where the operation is going. Three diagnostic questions cut through the comparison shopping.
Question 1: How many audiences will your support function serve in 24 months?
If the answer is one — a single product, a single customer segment, a single region — then single-audience tools work and the comparison between help desk and ticketing is the right one to run. If the answer is two or more — customers plus partners, or customers plus employees, or customers plus installers across multiple regions — then both help desk and ticketing are architecturally wrong. The duplication cost compounds. Start with infrastructure that holds multiple audiences from day one.
Question 2: How many brands, product lines, or regions are in scope?
One brand, one product, one region — ticketing or help desk works. Three or more on any of those axes — and the separate-instance model starts producing the drift, integration, and cost problems that dominate ops team agendas. In global high-tech operations, the multi-brand, multi-region reality is baseline, not edge case.
Question 3: How much of your team's value depends on collective knowledge?
If support resolution depends on individual agents applying trained skill to unique situations — professional services, complex implementation, managed services — ticketing plus collaboration tools may be enough. If support resolution depends on agents quickly accessing the right answer from a large, shared, frequently-changing knowledge base — the pattern in high-tech customer support — the platform architecture matters more than the ticketing workflow. Per-agent pricing becomes the binding constraint because it locks out the people whose knowledge the team most needs.
💡 KEY INSIGHT: The comparison isn't really help desk vs ticketing system. It's whether your operation will compound or scatter. Two tools force the same architectural trade-off in different price tiers. A third option — unified knowledge-driven platforms — resolves the trade-off by treating knowledge as the foundation, not a feature attached to the queue.
Real Scenarios: What the Decision Looks Like in Practice
Three operating profiles with real decision logic, drawn from the mid-market and enterprise high-tech companies that represent the core of MatrixFlows' customer base.
Scenario A: 120-person SaaS company, one product, growing fast
Current state: Email-based support, 400 tickets/month, 5 support agents. Leadership pushing for a "proper support system" as the company moves upmarket.
Naive choice: Zendesk Suite Professional, $575/month for 5 agents. Standard for this profile.
Why it's the wrong choice if growth continues: In 18 months at current growth, this company will have 3,000 customers, 3 product lines, and a partner channel. Zendesk handles the first two; the third audience forces a second platform or an expensive partner module. By year three, they're running the same fragmented stack the enterprise tier runs, with the lock-in costs of historical ticket data making migration expensive.
Better choice: Unified platform from the start. Unlimited knowledge collaboration on every plan (entire company contributes), usage-based pricing for customer-facing surfaces. Three-year total cost runs 40–60% below the Zendesk-plus-adjacent-tools trajectory.
Scenario B: 800-person high-tech manufacturer, 8 brands, dealer network
Current state: Internal Zendesk for employee IT, external Zendesk Suite for customer support across 3 of 8 brands, dealer portal built on a separate platform six years ago. Customer support handles 12,000 tickets/month; dealer questions flow through a different team that can't see customer ticket context.
Naive choice: Zendesk Enterprise across all brands, dealer portal replaced with Zendesk's partner module. Estimated $18,000–25,000/month in licensing, plus implementation.
Why it's wrong: The architecture still assumes separate audiences with separate systems. Dealers, customers, and internal teams each live in their own Zendesk instance or module. Knowledge duplicates across three surfaces. Per-agent pricing locks out the 80 product specialists and engineers who actually know the answers. Cost is high, and the compounding problem isn't solved.
Better choice: Consolidate to a unified platform. One knowledge foundation across 8 brands with brand-specific surfacing. Customer help centers, dealer portal, internal employee hub, and service tech workspace all pull from the same structured foundation. Usage-based pricing lets all 800 employees contribute knowledge without per-seat fees. Licensing cost drops 40–55% while deflection climbs from current ~20% to 55–65% within 12 months.
Scenario C: 250-person enterprise SaaS company, internal IT plus external customer support
Current state: Jira Service Management for internal IT (12 agents, $240/month), Zendesk for customer support (18 agents, $2,070/month), Confluence for technical docs ($2,500/month for 250 users), separate AI chatbot ($1,500/month), integration middleware ($800/month). Total: about $7,100/month plus engineering maintenance.
Naive choice: Patch the existing stack. Upgrade Zendesk to Enterprise for better AI and knowledge base features. Hope the drift between Confluence and Zendesk KB improves.
Why it's wrong: The drift is architectural. Two separate systems will always produce two separate sources of truth. The Confluence-to-Zendesk-to-AI pipeline is the problem; tuning any one tool in the chain can't fix the structure.
Better choice: Migrate to a unified platform over 4–6 weeks. Internal IT and external customer support both run on the same knowledge foundation with audience-appropriate surfaces. Confluence retired. AI runs on the structured foundation with hallucination rates under 5% instead of the 20–30% they were seeing. Total cost drops to $2,500–3,500/month with unlimited users. Deflection climbs. The integration middleware goes away because there's nothing to integrate — the platform is the system of record for all of it.
What to Evaluate Before You Buy
Ten questions that surface the architectural fit of any platform you're considering, regardless of whether the vendor markets it as a ticketing system, a help desk, or a unified platform. The answers predict whether your support operation will compound or stay stuck.
- Who can contribute knowledge without a paid seat? If the answer is "only licensed agents," the knowledge ceiling is lower than what your organization knows.
- Does the knowledge base share data with the ticketing layer natively, or through an integration? Integration means drift. Native sharing means one source of truth.
- How does the platform handle multiple brands — separate instances or one foundation with branded surfaces? Separate instances multiply cost and drift. One foundation scales without duplication.
- How does the platform handle multiple audiences — separate KBs per audience or one foundation with audience filters? Same question, different axis. Same answer pattern.
- Is AI grounded in your knowledge foundation, or is it a separate model with its own knowledge store? Separate models hallucinate. Grounded AI resolves.
- How are new product versions, firmware updates, or process changes propagated to the customer-facing layer? Manual = drift. Automatic = compounding.
- What does three-year total cost look like including licensing, integrations, and the adjacent tools you'll need? Per-agent pricing looks cheap at 5 agents and expensive at 50.
- How does migration work — hard cutover or gradual adoption alongside the existing system? Hard cutover loses historical context. Gradual adoption keeps it.
- What happens to ticket volume 12 months in — does the system have architecture for deflection, or is the deflection dependent on manual KB maintenance? Architecture = compounding. Manual = plateau.
- Does the pricing model reward customer participation or penalize it? Per-agent pricing locks out contributors. Usage-based pricing rewards knowledge that actually works.
The questions expose architectural differences that feature-comparison tables hide.
Making the Move Without Breaking the Current Operation
The barrier to moving away from ticketing or legacy help desk software isn't usually the decision — it's the fear of disrupting an operation that's already stretched. The transition risk is real but the pattern that works is well-established.
Phase 1 (Weeks 1–2): Connect, don't replace
Leave the existing ticketing or help desk system running. Connect the unified platform to its data sources — Confluence, SharePoint, Google Drive, Notion, historical ticket resolutions, internal documentation. The platform ingests and structures the content without forcing a premature migration. Internal teams start collaborating on knowledge in the new foundation while support continues running where it runs today.
Phase 2 (Weeks 3–4): Launch self-service on the unified foundation
Deploy customer-facing self-service surfaces on the structured foundation. Start with the highest-volume brand or product line. Measure deflection from day one — the structured foundation typically produces deflection jumps from week two because the taxonomy finally matches how customers search. The legacy ticketing or help desk stays live for the requests that still come through.
Phase 3 (Weeks 5–6): Shift support agent workflow to the unified platform
Agents begin resolving tickets in the unified platform with the knowledge foundation at their fingertips. Historical tickets remain accessible as reference via the connection to the legacy system. New resolutions enrich the foundation for future customers and future AI responses.
Phase 4 (ongoing): Shrink the legacy footprint as confidence grows
As deflection climbs and agent proficiency builds on the unified platform, the legacy ticketing or help desk footprint shrinks naturally. Most teams fully retire the legacy system between month 3 and month 6, with no cutover event and no lost data.
The pattern works because the unified platform doesn't require the legacy system to die before it can deliver value. It delivers value alongside, then absorbs the remaining workload as the team gets comfortable.
The Answer to the Question Most Teams Don't Know to Ask
Teams comparing help desk vs ticketing system are usually asking: which tool is better? The better question: which architecture matches the operation I'm running — and the one I'm going to be running in two years?
For small, stable internal operations — ticketing wins. For single-brand, single-audience customer support — help desk wins. For global high-tech operations serving customers, partners, installers, service technicians, and internal teams across multiple brands and regions — neither wins, because both were built for a simpler world. The operation needs one knowledge foundation, branded surfaces for every audience, AI grounded in the foundation, and pricing that rewards contribution instead of penalizing it.
MatrixFlows is the platform built for that architecture. One foundation, every audience, AI that actually works because the foundation is structured, usage-based pricing that lets every employee contribute knowledge without per-seat friction. The teams that move to it stop asking help desk vs ticketing system questions — because the question itself stops mattering when the architecture underneath finally does the work the old categories couldn't.
Support costs drop. Deflection climbs. AI works. New brands, audiences, and regions become configurations, not migration projects.
.svg)
.svg)
.svg)
