Platform fit and service model
The project started by challenging a poor-fit default. I used Silverware as the proof point that advanced technical support teams needed a support-first platform, not just a formal case-management system.
Case Study
Building a Zendesk service platform connected to Salesforce.
At Fullsteam, I pushed for Zendesk to be evaluated as a better fit than Salesforce Service Cloud for advanced technical support teams. I then became the main business-side point of contact for the effort, designed the Salesforce integration model, built a custom Zendesk account-flag app, and automated Silverware's Help Center migration into the new Fullsteam Zendesk instance.
Company
Fullsteam
Role
Business Systems Analyst
Tools
Zendesk, Salesforce, n8n, Python, custom Zendesk app
Business Problem
The core issue was platform fit, not just support-platform selection.
Fullsteam's default path was Salesforce Service Cloud, but that approach would have weakened high-performing technical support teams that relied on faster workflows, better knowledge access, and a more agent-focused environment.
Fullsteam's default support direction was Salesforce Service Cloud, but that model was not a strong fit for fast-moving technical support teams like Silverware.
Support-heavy business units needed better agent speed, customer context, and knowledge-base usability than Service Cloud could provide in practice.
If Fullsteam moved toward Zendesk, the platform had to integrate cleanly with Salesforce, support mixed business-unit maturity levels, and preserve a large existing Help Center.
Approach
I treated the work as a support-operations architecture problem first.
That meant proving why Zendesk fit the workflow better, shaping a model that could scale across different business-unit needs, and making sure Salesforce governance, agent usability, and migration complexity were all solved together.
Pushed for Zendesk evaluation based on Silverware's strong support performance and became the main business-side point of contact for the effort.
Worked directly with Zendesk's account executive, technical services team, and solutions engineer to shape a model that could flex from simple ticketing to advanced support operations.
Designed the Salesforce integration so Salesforce users could see support activity while Zendesk agents could see rich account, contact, opportunity, order, and status context.
Built a custom Zendesk pop-up app that surfaced Salesforce-driven account flags and required agent acknowledgement before proceeding.
Replaced a nearly $1M professional-services Help Center migration with an internal n8n, JavaScript, and Python workflow that rebuilt Silverware's Zendesk knowledge base.
System Design
The build only worked because platform choice, integration, controls, and migration were designed as one system.
The strongest part of the project was how the Zendesk evaluation, Salesforce visibility model, custom account control layer, and automated Help Center rebuild reinforced each other.
Salesforce integration
Salesforce remained the source of truth while Zendesk became the support execution layer, giving both CRM users and support agents the visibility they needed without breaking data governance.
Custom agent controls
The custom account-flag app turned Salesforce account restrictions into unavoidable Zendesk notices, helping agents understand whether they could proceed and why.
Automated Help Center migration
The migration workflow used Zendesk APIs, JavaScript, and Python to recreate categories, sections, articles, images, embedded content, and access structures in the new Fullsteam instance.
Technical Details
The implementation details mattered as much as the platform choice.
This part of the work was not abstract architecture. It included concrete decisions about source-of-truth boundaries, agent controls, API migration flow, and how legacy knowledge-base content would be rebuilt safely.
Salesforce to Zendesk data model
Salesforce stayed authoritative for customer data. Account, contact, opportunity, product, Service Cloud ticket, sales order, shipment, invoice, address, and accounting-status data was surfaced into Zendesk so agents had context without owning CRM updates.
Cross-system visibility
Salesforce-side users could see Zendesk ticket activity inside Salesforce, while internal Salesforce comments and notes could be exposed back into Zendesk so support teams could work from the same customer picture.
Custom account-flag app
I built a custom Zendesk pop-up that read Salesforce-driven account flags, displayed the reason and owning stakeholder, and required acknowledgement before the agent could continue. The notice appeared at the account level, not only after ticket creation.
API-driven Help Center migration
The migration workflow used n8n to call Zendesk Help Center APIs, JavaScript to manage reusable variables, and Python to sequence category, section, and article imports in the correct order.
Image and content rewriting
Images were downloaded from the legacy Silverware Zendesk instance, uploaded into the new Fullsteam instance, and then the article HTML was rewritten so image URLs pointed to the new hosted assets instead of the old environment.
Structure preservation
The process preserved categories, sections, articles, embedded Tangos, quick links, permissions, and access structures so the destination Help Center was a near one-to-one recreation instead of a flat content dump.
Outcomes
The result was a stronger support-platform path and a major migration cost avoidance.
The business value was not just that Zendesk was evaluated. It was that the support model, Salesforce visibility, agent controls, and knowledge migration were all made materially more practical.
Created a stronger case for Zendesk as a support-platform option for business units that needed more speed and usability than Salesforce Service Cloud could provide.
Designed a Salesforce and Zendesk model that preserved CRM governance while giving support agents much richer customer context.
Built a custom governance layer inside Zendesk so account restrictions from Sales, Accounting, and Technical Services could not be missed by support agents.
Avoided a nearly $1M professional-services migration by building an internal workflow that recreated Silverware's Help Center in the new Fullsteam Zendesk instance.
Key takeaway
I did not just help stand up Zendesk. I built the argument for it, the integration model around it, and the migration path that made it viable.
Lessons Learned
This project reinforced how much operational fit matters in systems decisions.
The work sat at the intersection of support workflow design, CRM governance, vendor coordination, and technical migration execution, which is where platform choices become real.
The right support platform depends on operational fit, not just enterprise standardization.
Cross-system visibility only works well when data ownership is explicit from the start.
Automation becomes especially valuable when it can replace expensive vendor work without sacrificing structure or control.