there was an issue with your last subscription change, contact Customer Support.
Tickets dark~200,000
48h
Friday
Unified Ticket
Inside TradeCore CRM
Ticket #4521 open
Broker: ACME FX
WorkItem: TEST-1284
TestIQ: auto-verify
Cutover Complete
Zero new tickets on old surface · shipped Friday 17:00
live
~200K
migrated
48h
Wed → Fri
7d
overlap
On a Wednesday, our 9.5-year support vendor quietly moved us onto a pricing model that was roughly four times more expensive, with a forced annual commitment. By Friday, we had replaced them. Here is how, and why it matters for every SaaS customer.
Wednesday
I was not planning to write this article. I was planning to add seats to our Zendesk account.
That is the boring sentence I want you to remember when you read the rest of this. Wednesday morning, our support team was growing. We went to add agent seats. The order page errored out: the button to manage our subscription was dead, and the page returned “there was an issue with your last subscription change, contact Customer Support.” Our team wrote to Zendesk Support. Zendesk Support wrote back, confirmed the bug was on their side, and told us that because of it the seats could not be added the normal way. They would process the order manually instead, as a new contract term. They sent over documents and a payment link. We paid.
A few hours later, every one of our broker customers lost access to their TradeCore support portal. The portal that Zendesk hosts. The portal that holds nearly a decade of support history: close to two hundred thousand customer interactions across tickets, replies, and attachments, the lived record of dozens of brokers and hundreds of their internal users. Dark.
We wrote back to Zendesk Support. The explanation, once it was fully assembled, amounted to this. The new contract term we had just signed to add six seats could not carry forward the legacy product that ran our customers’ help centre. That product was gone, and the portal with it. The new terms were also roughly four times more expensive per seat than what we had been paying, on a forced annual commitment. To restore what we had lost, we were told, we would need to move up to a higher-tier plan.
there was an issue with your last subscription change, contact Customer Support.
Tickets dark~200,000
48h
Friday
Unified Ticket
Inside TradeCore CRM
Ticket #4521 open
Broker: ACME FX
WorkItem: TEST-1284
TestIQ: auto-verify
Cutover Complete
Zero new tickets on old surface · shipped Friday 17:00
live
~200K
migrated
I want to be fair to the people on the other end of that thread. They were not unkind, and their own words make the point better than mine can. In the exchange that followed, Zendesk’s account team told us, in writing: “we definitely should have had a clearer conversation about the legacy SKU and the fact that, with the new contract terms, it couldn’t be carried forward.” And, plainly: “I understand that your customers haven’t been able to raise requests, which I know has been highly disruptive.” That is the vendor describing, accurately, what had just happened to our customers.
I read that email twice. Then a third time. We had been a Zendesk customer for nine and a half years. Our first ticket on their platform is dated 27 October 2016. Our usage was not declining. Quite the opposite: as our business grew and more brokers and their users came on board, the support operation we ran on the platform grew with it, up roughly 83% over the year before. We were, by any honest measure, exactly the kind of customer a support-software vendor is supposed to want.
9 years, 7 months, 1 vendor
First ticket
Oct 2016
+83%
YoY growth
Portal dark
May 2026
~200K live
0 lost
I went into our team Slack. The sensible argument was already being made there: pay it, restore the portal, deal with the migration calmly over the next year. It is the right answer ninety-five times out of a hundred.
I typed: fuck zendesk, we are going to build our solution in a day.
The decision
The rational case for paying was real. Replacing a support system that has been running for a decade is not a weekend project. Our team was already mid-sprint on other things. Our broker customers needed their portal back the same day. The cost of distraction across the company, measured properly, was almost certainly higher than the cost of swallowing the new pricing for a year and migrating off in a planned way.
I knew all of this when I typed the message.
I also knew three other things.
First, every dollar we sent to Zendesk after Wednesday would feel like rent on a hostage. That is not a healthy way to do business with a vendor, and it is contagious. Pay it once, and the next time the bill arrives, the position is the same. The structural cost compounds. The whole move only made sense on the assumption that we could not leave, and a vendor that believes you cannot leave behaves very differently from one that knows you can.
Second, our customers’ support surface belonged inside the same platform we already run for them, not bolted on through a third party with its own pricing whims. TradeCore is a CRM and workflow platform for FX and CFD brokers. The support tickets our brokers’ customers were opening sat in a different system from the broker CRM the support agents were operating inside. The integration we had built on top of Zendesk over the years was the closest we could get to making that one system. It was never going to be the actual one system.
Third, we already had everything we needed to build it. Not in some future-quarter sense. Right then. We had a CRM platform with the bones already in production, a Slack-and-Jira reactive triage workflow our agents were already using, and ten years of intimate knowledge of how broker support actually works. We were not staring at a blank page. We were staring at a parts bin.
What Zendesk’s move on Wednesday changed was not what was true. It was what was urgent.
The 48 hours
I am going to tell you what we built, and I am going to keep this section short, because the point of the article is not the build itself. The point is what becomes possible when a SaaS vendor forgets that their customers can leave.
We built a new customer-facing support portal as its own deployable, with its own authentication boundary, sharing nothing with the agent-facing CRM except the parts that genuinely belong shared. The architectural reason for the separation is dull and important: a routine deploy of our internal CRM should never again take down our brokers’ support portal. We had inherited that coupling from the Zendesk era. We did not want to keep it.
Inherited coupling
Internal CRM
↓ same deploy
Customer portal
CRM deploy → portal down
Separation
New: own auth boundary
Internal CRM
Customer portal
Independent deploys
We added a first-class Customer entity to the CRM itself, so that support tickets, work items, product items, test scenarios, and client profiles now all hang off the same broker identity. The agents who work the queue now see, on the same screen, the support ticket they are reading, the broker it belongs to, the work items that broker has open, and the recent product changes that touch that broker. Zendesk could give us a place to put tickets. It could not give us that.
We wired the new system into the reactive operations pipeline we had already built on top of Zendesk over the previous six months. On the morning the new system went live, the support agents working from Slack and Jira did not even notice the source had changed. That is, I think, the highest compliment an internal cutover can earn.
We imported the historical Zendesk tickets as read-only history and re-homed the still-open ones as live, editable tickets inside the new system. Original ticket reference IDs preserved, so internal links into the old system still resolve. We left the Zendesk webhook running in parallel for a seven-day overlap window, so that we could prove zero new tickets were landing on the old surface before we decommissioned it.
That last part, the seven-day overlap, is worth a moment. It is the basic operational courtesy you owe a customer when you are changing how the system works. It is the courtesy Zendesk did not extend to us on Wednesday.
How we actually pulled it off
The honest answer is the boring one. We pulled an ultrahackathon. The team who built this did not sleep much for two days. They worked through Wednesday night, through Thursday, through Thursday night, through Friday. They ate at their desks. They wrote the spec late Wednesday evening and they wrote the cutover commit on Friday afternoon, and in between they did the work that the time between those two moments required.
The thing I am most proud of is what they did not do. They did not let anything else slip. Other deploys went out on time. Other tickets got worked. Our brokers’ onboarding and reactive operations queues did not pile up. Part of the team carried the hackathon while the rest of the team kept the lights on, and the rest covered for the ones who could not. That is the team I get to work with.
Two structural things made the speed possible on top of the effort.
The first is nine and a half years of domain context. We did not write the specification on Wednesday night by sitting down and asking ourselves what a ticketing system should do. We wrote it by sitting down and asking ourselves what was on the other side of nearly two hundred thousand customer interactions. The spec, frankly, wrote itself, because the writer had spent a decade as a customer of the system being replaced. That is not a thing you can compress or skip.
The second is a platform that was waiting for this. TradeCore is a CRM and workflow platform for FX and CFD brokers. The bones we needed were already in place because they exist for other reasons. We were not building a ticketing system from zero. We were assembling one out of parts we already owned and trusted in production.
AI is one of the tools our team uses, and like any team building anything serious in 2026 we used it across this work. It was not the headline. The headline was the team, and the platform, and the decade of context.
The bonus we did not plan for
We did this to get our customers’ portal back, and to stop paying rent on a system that had us cornered. That was the entire goal on Wednesday. What we did not expect was how much more our customers would get from the other side of the move.
On Zendesk, support was a sealed room. A customer could open a ticket, and that ticket lived in the ticketing tool, and that was the whole of what it could ever be. It could not connect to anything else about that customer, because there was nothing else in the room.
Inside our own platform, a support ticket is not a sealed room. It sits beside everything else we already run for that broker. The clearest example is TestIQ, our automated testing system. When a broker reports that something in their setup is misbehaving, that report does not have to stay a description of a problem. We can turn it into a repeatable, automated test that runs against that broker’s own configuration, verifies the fix the same way every time, and then stands guard so the same problem cannot quietly come back. A standalone ticketing tool can record the complaint. It cannot do that with it.
Customer report
"X is misbehaving on our setup"
TestIQ
Repeatable test against broker's own config
Standing guard
Prevents regression silently
The same holds in the other direction. A customer’s report now connects to the actual work item an engineer is carrying and the specific product change that resolves it. The thread from “here is what is wrong” to “here is the fix that shipped” runs as one continuous line, on one platform, instead of a complaint filed in one tool and a fix tracked in another that never speak to each other.
None of this was the plan. The plan was to get the portal back by Friday. But the moment support stopped being something we rented and became something we owned, it stopped being only support. That is the part I could never have justified in a budget meeting, and the part I am most glad we backed into.
The bigger point
This is not a story about Zendesk. Zendesk is a fine product that has earned a lot of customers over a long time. What I described above is the behaviour of a particular commercial team, on a particular Wednesday, making a particular call about a particular customer. I would not turn that into a general accusation about how the company operates.
But there is a wider pattern worth naming, and it is about pricing transparency. A vendor that ships a price change through a support reply, hours after a bug forced a manual order, is signalling something specific about how it sees the relationship. Customers should know what they pay, and why, and they should know about changes before the changes take effect. This is not a radical principle. It is the baseline of healthy commerce.
We are a SaaS vendor ourselves. We sell software to brokers, and we hold our customers’ data on their behalf, which is the core of the trust they place in us. So I will not pretend that vendors holding customer data is the problem. The commitment I will make publicly, on behalf of TradeCore, is narrower and concrete:
We will never silently move a TradeCore customer to a different pricing tier. Any change to what a customer pays will be communicated before it takes effect, with the reasons, and never in the body of a support reply. 2. Every TradeCore customer always has a clear, up-to-date overview of exactly what they pay and why. Current prices, included usage, and any change before it takes effect. If you are our customer and that overview is ever unclear to you, that is our failure, and we will fix it.
Those are the two commitments. They are deliberately narrow. They are also the two I am confident we can keep.
Igor Jovic, CEO, TradeCore
Tags
Ready to Get Started?
Discover how TradeCore can help you build and scale your forex brokerage with our comprehensive CRM.
Schedule a Demo
We value your privacy
We use cookies to enhance your experience. Read our Cookie Policy.
Customize
Reject Accept All
48h
Wed → Fri
7d
overlap
On a Wednesday, our 9.5-year support vendor quietly moved us onto a pricing model that was roughly four times more expensive, with a forced annual commitment. By Friday, we had replaced them. Here is how, and why it matters for every SaaS customer.
Wednesday
I was not planning to write this article. I was planning to add seats to our Zendesk account.
That is the boring sentence I want you to remember when you read the rest of this. Wednesday morning, our support team was growing. We went to add agent seats. The order page errored out: the button to manage our subscription was dead, and the page returned “there was an issue with your last subscription change, contact Customer Support.” Our team wrote to Zendesk Support. Zendesk Support wrote back, confirmed the bug was on their side, and told us that because of it the seats could not be added the normal way. They would process the order manually instead, as a new contract term. They sent over documents and a payment link. We paid.
A few hours later, every one of our broker customers lost access to their TradeCore support portal. The portal that Zendesk hosts. The portal that holds nearly a decade of support history: close to two hundred thousand customer interactions across tickets, replies, and attachments, the lived record of dozens of brokers and hundreds of their internal users. Dark.
We wrote back to Zendesk Support. The explanation, once it was fully assembled, amounted to this. The new contract term we had just signed to add six seats could not carry forward the legacy product that ran our customers’ help centre. That product was gone, and the portal with it. The new terms were also roughly four times more expensive per seat than what we had been paying, on a forced annual commitment. To restore what we had lost, we were told, we would need to move up to a higher-tier plan.
I want to be fair to the people on the other end of that thread. They were not unkind, and their own words make the point better than mine can. In the exchange that followed, Zendesk’s account team told us, in writing: “we definitely should have had a clearer conversation about the legacy SKU and the fact that, with the new contract terms, it couldn’t be carried forward.” And, plainly: “I understand that your customers haven’t been able to raise requests, which I know has been highly disruptive.” That is the vendor describing, accurately, what had just happened to our customers.
I read that email twice. Then a third time. We had been a Zendesk customer for nine and a half years. Our first ticket on their platform is dated 27 October 2016. Our usage was not declining. Quite the opposite: as our business grew and more brokers and their users came on board, the support operation we ran on the platform grew with it, up roughly 83% over the year before. We were, by any honest measure, exactly the kind of customer a support-software vendor is supposed to want.
9 years, 7 months, 1 vendor
First ticket
Oct 2016
+83%
YoY growth
Portal dark
May 2026
~200K live
0 lost
I went into our team Slack. The sensible argument was already being made there: pay it, restore the portal, deal with the migration calmly over the next year. It is the right answer ninety-five times out of a hundred.
I typed: fuck zendesk, we are going to build our solution in a day.
The decision
The rational case for paying was real. Replacing a support system that has been running for a decade is not a weekend project. Our team was already mid-sprint on other things. Our broker customers needed their portal back the same day. The cost of distraction across the company, measured properly, was almost certainly higher than the cost of swallowing the new pricing for a year and migrating off in a planned way.
I knew all of this when I typed the message.
I also knew three other things.
First, every dollar we sent to Zendesk after Wednesday would feel like rent on a hostage. That is not a healthy way to do business with a vendor, and it is contagious. Pay it once, and the next time the bill arrives, the position is the same. The structural cost compounds. The whole move only made sense on the assumption that we could not leave, and a vendor that believes you cannot leave behaves very differently from one that knows you can.
Second, our customers’ support surface belonged inside the same platform we already run for them, not bolted on through a third party with its own pricing whims. TradeCore is a CRM and workflow platform for FX and CFD brokers. The support tickets our brokers’ customers were opening sat in a different system from the broker CRM the support agents were operating inside. The integration we had built on top of Zendesk over the years was the closest we could get to making that one system. It was never going to be the actual one system.
Third, we already had everything we needed to build it. Not in some future-quarter sense. Right then. We had a CRM platform with the bones already in production, a Slack-and-Jira reactive triage workflow our agents were already using, and ten years of intimate knowledge of how broker support actually works. We were not staring at a blank page. We were staring at a parts bin.
What Zendesk’s move on Wednesday changed was not what was true. It was what was urgent.
The 48 hours
I am going to tell you what we built, and I am going to keep this section short, because the point of the article is not the build itself. The point is what becomes possible when a SaaS vendor forgets that their customers can leave.
We built a new customer-facing support portal as its own deployable, with its own authentication boundary, sharing nothing with the agent-facing CRM except the parts that genuinely belong shared. The architectural reason for the separation is dull and important: a routine deploy of our internal CRM should never again take down our brokers’ support portal. We had inherited that coupling from the Zendesk era. We did not want to keep it.
Inherited coupling
Internal CRM
↓ same deploy
Customer portal
CRM deploy → portal down
Separation
New: own auth boundary
Internal CRM
Customer portal
Independent deploys
We added a first-class Customer entity to the CRM itself, so that support tickets, work items, product items, test scenarios, and client profiles now all hang off the same broker identity. The agents who work the queue now see, on the same screen, the support ticket they are reading, the broker it belongs to, the work items that broker has open, and the recent product changes that touch that broker. Zendesk could give us a place to put tickets. It could not give us that.
We wired the new system into the reactive operations pipeline we had already built on top of Zendesk over the previous six months. On the morning the new system went live, the support agents working from Slack and Jira did not even notice the source had changed. That is, I think, the highest compliment an internal cutover can earn.
We imported the historical Zendesk tickets as read-only history and re-homed the still-open ones as live, editable tickets inside the new system. Original ticket reference IDs preserved, so internal links into the old system still resolve. We left the Zendesk webhook running in parallel for a seven-day overlap window, so that we could prove zero new tickets were landing on the old surface before we decommissioned it.
That last part, the seven-day overlap, is worth a moment. It is the basic operational courtesy you owe a customer when you are changing how the system works. It is the courtesy Zendesk did not extend to us on Wednesday.
How we actually pulled it off
The honest answer is the boring one. We pulled an ultrahackathon. The team who built this did not sleep much for two days. They worked through Wednesday night, through Thursday, through Thursday night, through Friday. They ate at their desks. They wrote the spec late Wednesday evening and they wrote the cutover commit on Friday afternoon, and in between they did the work that the time between those two moments required.
The thing I am most proud of is what they did not do. They did not let anything else slip. Other deploys went out on time. Other tickets got worked. Our brokers’ onboarding and reactive operations queues did not pile up. Part of the team carried the hackathon while the rest of the team kept the lights on, and the rest covered for the ones who could not. That is the team I get to work with.
Two structural things made the speed possible on top of the effort.
The first is nine and a half years of domain context. We did not write the specification on Wednesday night by sitting down and asking ourselves what a ticketing system should do. We wrote it by sitting down and asking ourselves what was on the other side of nearly two hundred thousand customer interactions. The spec, frankly, wrote itself, because the writer had spent a decade as a customer of the system being replaced. That is not a thing you can compress or skip.
The second is a platform that was waiting for this. TradeCore is a CRM and workflow platform for FX and CFD brokers. The bones we needed were already in place because they exist for other reasons. We were not building a ticketing system from zero. We were assembling one out of parts we already owned and trusted in production.
AI is one of the tools our team uses, and like any team building anything serious in 2026 we used it across this work. It was not the headline. The headline was the team, and the platform, and the decade of context.
The bonus we did not plan for
We did this to get our customers’ portal back, and to stop paying rent on a system that had us cornered. That was the entire goal on Wednesday. What we did not expect was how much more our customers would get from the other side of the move.
On Zendesk, support was a sealed room. A customer could open a ticket, and that ticket lived in the ticketing tool, and that was the whole of what it could ever be. It could not connect to anything else about that customer, because there was nothing else in the room.
Inside our own platform, a support ticket is not a sealed room. It sits beside everything else we already run for that broker. The clearest example is TestIQ, our automated testing system. When a broker reports that something in their setup is misbehaving, that report does not have to stay a description of a problem. We can turn it into a repeatable, automated test that runs against that broker’s own configuration, verifies the fix the same way every time, and then stands guard so the same problem cannot quietly come back. A standalone ticketing tool can record the complaint. It cannot do that with it.
Customer report
"X is misbehaving on our setup"
TestIQ
Repeatable test against broker's own config
Standing guard
Prevents regression silently
The same holds in the other direction. A customer’s report now connects to the actual work item an engineer is carrying and the specific product change that resolves it. The thread from “here is what is wrong” to “here is the fix that shipped” runs as one continuous line, on one platform, instead of a complaint filed in one tool and a fix tracked in another that never speak to each other.
None of this was the plan. The plan was to get the portal back by Friday. But the moment support stopped being something we rented and became something we owned, it stopped being only support. That is the part I could never have justified in a budget meeting, and the part I am most glad we backed into.
The bigger point
This is not a story about Zendesk. Zendesk is a fine product that has earned a lot of customers over a long time. What I described above is the behaviour of a particular commercial team, on a particular Wednesday, making a particular call about a particular customer. I would not turn that into a general accusation about how the company operates.
But there is a wider pattern worth naming, and it is about pricing transparency. A vendor that ships a price change through a support reply, hours after a bug forced a manual order, is signalling something specific about how it sees the relationship. Customers should know what they pay, and why, and they should know about changes before the changes take effect. This is not a radical principle. It is the baseline of healthy commerce.
We are a SaaS vendor ourselves. We sell software to brokers, and we hold our customers’ data on their behalf, which is the core of the trust they place in us. So I will not pretend that vendors holding customer data is the problem. The commitment I will make publicly, on behalf of TradeCore, is narrower and concrete:
We will never silently move a TradeCore customer to a different pricing tier. Any change to what a customer pays will be communicated before it takes effect, with the reasons, and never in the body of a support reply. 2. Every TradeCore customer always has a clear, up-to-date overview of exactly what they pay and why. Current prices, included usage, and any change before it takes effect. If you are our customer and that overview is ever unclear to you, that is our failure, and we will fix it.
Those are the two commitments. They are deliberately narrow. They are also the two I am confident we can keep.
Igor Jovic, CEO, TradeCore
Tags
Ready to Get Started?
Discover how TradeCore can help you build and scale your forex brokerage with our comprehensive CRM.
Schedule a Demo
We value your privacy
We use cookies to enhance your experience. Read our Cookie Policy.