The tools stopped being the problem. The seams between them started.
Somewhere between 40 and 250 people, nothing in your stack is obviously wrong and everything is slightly out of step. The same customer exists in three systems. A new joiner needs six accounts. Nobody can say, without opening six admin panels, who still has access to what. That is a control plane problem, not a software problem.
The same customer, three times
A deal in the CRM, an invoice in the accounts, a thread in a shared mailbox. Three records, three identifiers, and no agreement about which one is right. Someone reconciles them by hand at month end.
Onboarding is six tickets
A new joiner needs accounts in six products, each created by a different person, each with its own password and its own idea of what a “manager” is allowed to see. It takes a week and it is never quite complete.
Nobody can answer the access question
Ask which people who left last quarter still have a working login. The honest answer involves six admin panels and an afternoon — which is why the question tends not to get asked.
Nine renewals on somebody’s card
Several vendors, several dates, several invoices, and at least one of them auto-renewing on a personal card. Finance cannot tie any of it to a department without asking around.
Reporting stops at the tool boundary
Each product reports on itself. Pipeline here, collections there, headcount somewhere else. The monthly deck is assembled by copying numbers into a spreadsheet, and the spreadsheet is the only place they meet.
Every integration is maintained by nobody
The connector between two vendors belongs to neither of them. When a field changes it breaks quietly, and you find out when a number looks wrong three weeks later.
One layer underneath every product.
Identity, the account tree, billing, roles and the audit trail are defined once and used by every product in the suite. This is the part that is difficult to bolt on later, and it is the reason the second product costs less effort than the first.
One identity per person
A person exists once, not once per product. They sign in once and reach what they are entitled to. When they leave, revoking that identity ends their access everywhere — one action, not six, and no list to remember.
One account tree
Branches, subsidiaries and departments are nodes in a single hierarchy that every product reads. Adding a location does not mean opening a new account with each vendor and re-explaining your structure.
One wallet, one GST invoice
Usage across products draws from one balance and arrives as a single invoice carrying your GSTIN. Finance reconciles one document a month instead of chasing several.
Per-role visibility inside each product
Roles are granted per product from one place. A finance lead sees the ledger and not the pipeline. A sales manager sees their own team’s deals and not payroll. The default is that you see nothing you were not given.
One audit trail across products
Who changed what, in which product, when. Read it in one place rather than exporting from each tool and hoping the clocks agree.
One agreement, one queue
One contract covers the suite and one support queue owns a problem even when it crosses two products. Nothing gets closed because it was the other vendor’s fault.
The order most teams adopt it in.
Nobody moves multiple products at once and we do not ask anyone to. Start where the money is, then the people, then the conversations that sit on top of both. Four products are available today; the rest are not released yet, and we will say so plainly rather than sell you a date.
The customer and the money
Start with Comsky CRM and whichever accounting fits where you already are. If your books live in TallyPrime, TallyBridge reads them and puts outstanding, ageing and cash flow on a phone without moving anyone off Tally.
- ·CRM and TallyBridge are available now
- ·Books, the full accounting product, is not released yet
- ·Both attach to the same customer record
Then the employee record
Past about fifty people, attendance, leave and payroll stop fitting in a spreadsheet and statutory filing stops being a once-a-quarter job. HRMS is built on the same identity the rest of the suite uses, so a joiner is created once.
- ·HRMS is not released yet
- ·One employee record behind attendance, leave and payroll
- ·Joining and leaving become one action each
Then the conversation, on the record
Chat brings web chat, WhatsApp and email into one inbox and Telephony puts calls and recordings on the contact they belong to. Both are designed to write back to the CRM record rather than live beside it.
- ·Chat and Telephony are not released yet
- ·The thread and the call land on the same contact as the deal
- ·Nothing to reconcile afterwards
The machines underneath
Most teams add infrastructure when they hire the first person actually responsible for IT. Cloud and Backup are available now; Monitor is not released yet.
- ·GPU, virtual machines and bare metal in Indian data centres
- ·Encrypted backups the machine itself cannot delete
- ·Monitor is not released yet
The same tasks, with and without a shared plane.
None of these are exotic requests. They are the ordinary weekly work of whoever ended up owning the tools, and each one gets harder with every product you add to a stack that does not share anything.
| Nine separate vendors | Comsky | |
|---|---|---|
| Someone leaves on Friday | Six admin panels, in whatever order you remember them | One identity revoked. Access ends across every product. |
| The monthly bill | Separate invoices, separate dates, at least one personal card | One wallet, one GST invoice, split by account in the tree. |
| Who can see payroll | Whatever each tool’s defaults happened to be | A role granted per product, set and reviewed in one place. |
| A customer’s full history | Assembled by hand from three exports | One contact record the other products attach to. |
| Opening a second branch | A new account with each vendor, structure re-explained | A node added to the account tree the products already read. |
| Adding a tenth capability | A new vendor, a new contract, a new set of logins | Switched on under the same account and the same identity. |
| Proving what changed | Export from each tool and reconcile the timestamps | One audit trail across the products you use. |
| A problem crossing two tools | Two support queues pointing at each other | One queue, in IST, that owns the whole path. |
Four products are running today and five are not. The shared plane is what makes the fifth one cheap to add when it arrives — and what makes it worth starting with one now.
What teams this size ask first.
We are sixty people on four tools already. Do we have to move everything?
No, and we would advise against it. Pick the one that hurts most, run it beside what you have, and move the next when the first is settled. Each product you add joins the same account tree and the same identity, so the second migration is smaller than the first.
Which products can we actually run today?
Cloud, CRM, TallyBridge and Backup are available now. Books, HRMS, Chat, Telephony and Monitor are not released yet. Ask us where any of them currently stands and you will get the actual state rather than a launch date.
Do we need Books if we already run Tally?
No. TallyBridge is for teams that want to keep TallyPrime and still see outstanding, ageing, profit and loss and cash flow away from the machine it runs on. Books is for teams that want to leave Tally altogether, and it is not released yet.
Can a department head manage their own people without seeing everything?
Yes. That is what per-role visibility is for. Roles are granted per product against one account tree, so a branch manager can administer their own node without reading the one next to it, and without anyone handing out a shared admin login.
What actually happens when someone leaves?
You revoke the identity once and their access ends in every product they were entitled to. The work they created stays where it belongs — on the customer records, the invoices and the tickets — rather than disappearing with the account.
Will each product be a separate contract and a separate invoice?
No. One agreement covers the suite, usage draws from one wallet, and it arrives as a single GST invoice. Adding a product does not start a new contract or a new billing relationship.
Where does the data sit?
On infrastructure in India. That is the same answer for every product in the suite, which is a large part of why teams replacing a foreign vendor start this conversation at all.
Add products without adding logins.
Start with one, keep the rest of your stack running, and let the account tree, the identity and the invoice stay single as you grow into the others.