The Clients page is the screen a Scalegram workspace lives on. Everything else in the product exists to put something on a row here, and everything a person does with the product starts by finding the right row.
The list is a query, not an array
A lot of dashboards load your whole list into the page and filter it with JavaScript. It is fast to build and it looks fine in a demo with forty contacts. At four thousand it takes several seconds to open, and at fifteen thousand the tab stops responding. Worse, the search only finds what happened to be loaded, so a client who exists returns nothing and the operator concludes the record was lost.
Scalegram searches and paginates on the server. You type three letters, the database answers, and the page shows the answer. Sorting and filtering behave the same way. The result is that the page opens at the same speed whether you have two hundred contacts or twenty thousand, and a search result means what it says: the person is not in your list rather than not on this page.
Filters that survive you leaving the page
The filter row carries stage, tags, owner, source campaign, purchase state and a date range, and combinations of those can be saved as a view you reopen every morning. The page also remembers where you were. Open a contact, deal with them, come back, and you are on the same page of the same filtered list at the same scroll position rather than back at the top of everything.
That sounds like a small thing. It is the difference between working a list of sixty follow-ups and working the first eight of them repeatedly. The method for choosing which views to build is in Telegram lead management.
What a row tells you
Name and username, current stage, tags, the owner if your team assigns them, when the contact was last active, and whether there is a purchase or a verified deposit on the record. That last one changes behaviour more than any other field, because a paying client and a lead who is still thinking about it should never receive the same message.
Every row also carries the button that opens the real Telegram chat. There is no reply box on this page and there is not going to be one, for the reasons in why Scalegram never mass-sends. The page finds the person. Telegram is where you talk to them.
The detail panel
Open a contact and you get the structured record: stage and its history, tags, notes, custom fields, tasks with due dates, the campaign and tracking link that produced them, purchases synced from a connected checkout, and where a broker integration is connected, the trading accounts and deposits matched to them by identifier. Anything the assistant established during a conversation, an account number, an experience level, a chosen product, is here as a field rather than as a paragraph of chat.
What is not here is the conversation. The record holds outcomes and identifiers, never message text, which is set out in never storing conversations. Purchases and deposits arrive through the account level connections described in purchase sync, claimed once each however often a sync runs.
Stages are yours, and worth arguing about
The default pipeline fits a fairly typical funnel, and it is renameable, reorderable and extendable because a coach's stages are not an affiliate's. The argument worth having with your team is where a stage ends. If nobody can say precisely what has to be true for a contact to move from Interested to Account Opened, then the board will fill with contacts sitting in whichever column the last person felt like.
Write the exit condition for each stage down somewhere. Two sentences each. It is the cheapest thing you will ever do to a CRM and it is the reason one workspace's board means something six months in while another's is decoration.
Who can see and do what
Team members get permissions per area, split into read, add, write and delete. A support person who should answer questions and update tags does not need the right to delete a contact or to see the payment integrations. A media buyer probably wants read on clients and write on links and nothing else. Set this on the way in rather than after the first accident.
The honest limits
The Clients page will not tell you who to message. It sorts, filters and remembers, and the judgment stays yours. It also cannot show you a conversation, so a team that wants to audit exactly what a colleague said to a client has to do that in Telegram on the account that sent it. And a list that nobody stages or tags degrades into a directory of names within a month, which is a discipline problem rather than a software one.
Used properly it answers the only question that matters on a Monday morning: who is one message away from paying you, and has anybody sent it.
"If your CRM loads the whole client list into the browser, it was built for a demo. Every list we ship is a database query with search on it, because that is the only version that still works in year two."
— Alex Onta, Executive Director, SINGUARD
Key Takeaways
- Search, filters and pagination are answered by the server, so the page opens at the same speed at twenty thousand contacts as at two hundred.
- Filter combinations save as views, and the page returns you to the same position in the same filtered list after you handle a contact.
- A row carries stage, tags, owner, recency, purchase state and a button into the real Telegram chat, and there is no reply box by design.
- The detail panel holds stages, notes, fields, tasks, campaigns, purchases and matched deposits, and never message text.
Frequently Asked Questions
Can I reply to a client from the Clients page?
No, and that is deliberate. The row deep-links into the real conversation in your Telegram app. Scalegram has no send queue at all, which is what keeps the account risk low.
Does the list slow down as it grows?
It should not. Search and pagination run as database queries rather than filtering a preloaded copy in the browser, so the page size stays constant as the list grows.
Can I stop a teammate from deleting contacts?
Yes. Permissions are set per area as read, add, write and delete, so you can give someone the right to update a record without the right to remove one.
About the Author
Alex Onta is an Executive Director at SINGUARD. He built eTrader, the terminal, the mobile apps, eTrader Broker, Copytrading, Business and Community, along with the worldwide clustered-server infrastructure it all runs on, with his brother Roman Onta helping on the design, and he leads that division today. Together with Roman he builds the Prop Firm CRM, the Broker CRM, Scalegram and CopySignals, and the two of them carry worldwide compliance, payment processing and international business structuring side by side. He lives and works in Dubai for most of the year. Meet the executive duo leading Singuard's five divisions.