ACT 00BOOT SEQUENCE
Telegram work accounts as company‑owned business assets
Companies run on Telegram. They do not own what happens there.
Nicegram Business puts a company's Telegram work under the company's control: the conversation archive, contacts and relationship graph stay with the business when the person who built them leaves.
Built for the teams that already live in Telegram — starting with crypto and Web3 operators
- OTC desk@acme_otcCompany-owned
- Community ops@acme_communityDelegated
- BD — APAC@acme_bd_leadDelegate offboarding
- Support@acme_supportDelegated
00Status
Pre-launch, and specific about it
The product is not shipped. What exists is a locked v1 scope, a server layer built against a mocked session service, and a decision record deep enough that the build has no open architectural questions.
- v1scope lockedPhased delivery: a core slice, then groups and personal-connect.
- 3services, three repositoriesDashboard and backend, session vault, account provisioning.
- 0customers, pilots or revenueFirst pilots gate on a signed DPA and recorded employee consent.
Where the build actually is
The session service is a scaffold today. The dashboard's server layer — schema, tenant isolation, audit, the message store, retrieval with citations, the metrics engine, the automation rules — is built and runs against a mock of it. No screen is finished. We would rather show you that map than a demo that implies otherwise.
ACT 01The gap
The company's most valuable conversations sit in accounts it does not own.
Sales threads, OTC deals, investor relationships, KOL pipelines, community admin rights and support history run through personal Telegram logins. When the person leaves, the company can lose the account, the history, the contacts and the revenue context in a single afternoon.
No standard layer attaches a work account to a company, hands it over without losing the record, or leaves anything behind that a business can search, audit or hand to the next person.
- Personal accounts
- History on one device
- Contacts leave with the rep
- Ex-employee still signed in
- Shared password
- Screenshot handover
- CRM empty
- No record
Same Telegram. Different layer underneath.
01Thesis
Telegram became the workspace. Nothing made it a company asset.
For a large class of businesses the revenue conversation already happens in Telegram. The company still has no claim on it.
- 01The account is the assetNot the CRM record. The account, its chats, its contacts and its standing with the people on the other side.
- 02Ownership is undefinedA work account is registered to a person. There is no layer that says it belongs to the company.
- 03Knowledge leaves with peopleHistory, relationships, agreed terms and the promise made two quarters ago walk out with the person who made it.
- 04There is nothing to hand overA successor starts from zero on a relationship the company has been paying for since before they arrived.
- 05And nothing to readNo searchable record, so no analytics, no compliance answer and no useful AI — because there is no corpus to point one at.
We make Telegram work durable: owned, delegatable, searchable and survivable.
ACT 02The product
Nobody owns the category
There is no clean incumbent for “the Telegram account as a company asset.” The adjacent tools each solve a different problem and leave this one open.
Session managers and multi-account tooling solve scale, not ownership, archive or handover — and much of that market is the gray zone we deliberately stay out of. Telegram-CRM tools bolt a pipeline onto chats without touching the account itself. General CRMs own the pipeline and ignore the account and the relationship graph living inside it.
The wedge is the union none of them cover: an owned, delegatable, revocable account plus a durable archive, the graph, analytics and AI over it — kept deliberately narrow.
| Dimension | Session managers | Telegram CRMs | General CRM | Nicegram Business |
|---|---|---|---|---|
| Account as a company asset | — | — | — | Yes |
| Durable archive after exit | — | Partial | — | Yes |
| Delegation and handover | — | — | — | Yes |
| Relationship graph from chats | — | Partial | — | Yes |
| Consent and data-rights posture | — | — | Yes | Yes |
Category comparison, not a feature audit of named products.
02Seat lifecycle
Four steps, and the fourth is the product
- 01
The company connects an account it owns
An admin authorizes a work account against the session vault. Exactly one Telegram authorization per account is held by the backend — not by the employee, and not on a personal device.
Account enters the company inventory.
Company-owned - 02
The account's work is recorded
The backend reads the account's own connection and stores messages, chats and contacts. Nothing is collected before the scope is chosen — a connected account with no selection collects nothing at all.
Archive begins. Edits append versions; deletions stay marked.
Collecting · scope applied - 03
A person is given the account to work
The employee accepts through a single-use link and their client is authorized as a Telegram session of its own. No phone number and no login code of ours ever reaches them.
Delegate works the account and inherits the whole archive.
Delegated · full history - 04
The person leaves and the business does not
The grant is removed and the device authorization is terminated through Telegram. That part depends on Telegram and the device honouring it. The archive, contacts and graph do not — they are already the company's.
Successor opens the account with the history already there.
Grant removed · archive retainedAudit log
- 10:42Access grant removed
- 10:42Device authorization terminated
- 10:43Removed from 6 business groups
- 10:43Account reassigned to successor
The durable guarantee is the archive, the contacts and the graph surviving offboarding — not control of the account itself, which the person who holds the number can always contest.
02The product
One narrow layer around Telegram business accounts
Deliberately not a CRM, a helpdesk or a workflow builder. Status is shown per module because the product is pre-launch and the difference matters.
- 01Account inventoryCompany-owned accounts, their state and who holds each oneIn build
- 02Session vaultOne Telegram authorization per account, encrypted, held by the backendDesigned
- 03Delegation & offboardingHand an account to a person, take it back, keep the recordDesigned
- 04Conversation archiveMessages, versions, contacts — edits appended, deletions markedIn build
- 05Ask the archiveRetrieval with a citation contract: no sources, no answerIn build
- 06AnalyticsA published metrics dictionary; nothing renders that is not definedIn build
- 07Groups & automationsCompany groups, and the sweep that removes a leaver from all of themIn build
- 08Account agentCollect, Analyse or Act — capability configured per account, never ambientDesigned
- 09Agent & tool surfaceExternal agents over MCP, scoped and auditedDesigned
“In build” means code exists and runs against a mocked session service. “Designed” means specified in the decision record and not yet built.
02The archive
The asset is the record
Every managed account's conversations land in a store the company owns — and the answers drawn from it have to show their sources.
A message edited in Telegram appends a version rather than overwriting. A message deleted in Telegram stays in the archive, marked and dated. For the beachhead that last one is close to the whole point: a disputed number is the incident, and it is the thing the other side has an incentive to remove.
THE RULES IT RUNS UNDER
- Answers cite the messages they came from, or they do not render
- A post-generation check drops citations that were not retrieved
- Questions about work are answered; questions asking the model to judge a person are refused
- Retention is 30 days for every organization, and depth is quoted with it or the offer is misleading
- AskWhat did we agree with this counterparty on price?
- CitedAnswer links to the three messages it came from.
- SurvivesThe rep who negotiated it left in March.
ACT 03The business
An agent attached to an account, not let loose on it
Capability is configured onto an account in advance and audited per call. A tool that is not on the account cannot be called; there is no ambient capability.
Model-agnostic by design. The defensible layer is the controlled Telegram context an agent runs on, not the model it uses.
Level one: attached, and doing nothing
An agent can be attached to an account and read nothing, because “an agent is attached” and “an agent is acting” need to be different facts a customer can point at.
Level two: reads the archive, answers, drafts
It can answer from the record and draft a reply. It cannot send. This is where most of the value is and most of the risk is not.
- Can you send terms for 50 accounts?
- Draft prepared, cited to the last quote we sent.
Level three: uses the tools it was given
Only the tools the organization configured onto that account, only on company-owned accounts, every invocation audited with its arguments and outcome.
- Customer toolCRM write, declared parameters
- Customer toolLookup call, scoped
- AuditTool, arguments and outcome recorded
And a level it will not do
The model refuses to judge a person — character, competence, comparative ranking. That refusal is enforced before retrieval runs, not asked for in a prompt.
The agent levels and the external agent surface are specified in the decision record and do not ship in the first iteration.
03Integrations
Where it plugs in later
An external-agent surface and outbound events are fully specified — scoped read tools, per-account token binding, per-call audit — and are deliberately out of the first iteration. They are shown here as roadmap, not as a shipping capability.
Read tools
List accounts and chats, read messages, search, pull analytics — read-first by design.
handshake · row written to Read tools
03In the field
Choose a segmentWhere the pain is sharpest
Crypto & Web3
Investor chats, OTC negotiations, KOL relationships and community admin rights stay with the company when an operator leaves.
- 09:02Counterparty disputes a price agreed last month
- 09:03The archive returns the message, and the edit before it
- 09:04Deleted message still there, marked and dated
- 09:05The rep who agreed it left in March
03Trust boundary
The refusals are the strategy
Built for
- Company-owned work accounts, with ownership affirmed and recorded
- Employee consent recorded per connected account, before anything is collected
- A standing screen that tells the employee what is collected about them
- A signed data-processing agreement before the first pilot account
Out of scope
- No automated appraisal of people — the model refuses and the refusal is enforced
- No enrichment of counterparties from outside sources
- No covert collection — pausing or resuming is always disclosed
- No gray-market session resale or spam automation
- 01OffboardedThe operator marks the delegate as leaving
- 02Access removedGrant revoked, device authorization terminated
- 03Record keptArchive, contacts and graph stay with the company
This is a managed-account product, not monitoring software. The employee-facing transparency screen is the argument that closes a room — and refusing to score people is a stronger position in a procurement review than any feature we could put in its place.
03The ecosystem
Built by the team inside the ecosystem
Nicegram is an established third-party Telegram client with tens of millions of installs and millions of active users, and years of experience monetizing Telegram power users. Nicegram Business is the B2B layer built on that understanding and that distribution — not a dashboard bolted on from outside.
03Business model
Priced per managed account, not per seat
Ten people reading one archive cost what one person reading it costs. Seats, roles and team members are not metered — the account is the unit, because the account is the asset.
Business account
$10per account / month
- The account, collection and the archive
- Dashboard, analytics, groups and automations
- 90 days of history depth
No AI at this tier.
+ AI
$25per account / month
- Everything in Business account
- An agent attached to the account
- 12 months of history depth, raised storage
AI is an upgrade, not an inclusion.
Scale
$50per account / month
- Everything in + AI
- The largest limits
- Full history depth
No free tier at any point.
- Designed margin40 / 30 / 20%Narrowing as the tier rises — deliberately, so the expensive tiers carry their own cost.
- Retention30 daysThe same for every organization; history depth is the plan dimension, and the two are always quoted together.
- Billable unitManaged accountNot seats. A team growing on one account does not change the bill.
03The business
The work moved. The tooling did not follow.
Business-critical conversation moved into a messenger with no company layer, and every year more of the relationship value accumulates somewhere the company cannot read. The gap is not shrinking on its own, and the first product to define the category gets to name it.
04The round
Raising $5M at a $30M valuation
The capital buys the distance between a locked design and a product with paying customers on it — and the first commercial proof that the category is real.
- Raising$5M
- Valuation$30M
- StageSeed round
Use of fundsIndicative allocation.
- Development45%
Finish the session and ingestion service, build the fifty screens over the server layer that already exists, and take the product through its first pilots to general availability.
- Marketing30%
Take a defined category to the segment that feels the pain first, and own the language for it before an adjacent tool does.
- Business development25%
Convert design partners into paid pilots in crypto and Web3 operations, then open the agency wave — the segments where offboarding loss is measured in deals, not inconvenience.
- 01First pilotsA signed processing agreement and recorded employee consent per account — the gate we hold ourselves to before a single outside account connects.
- 02Commercial proofDesign partners committing at or above the price floor, and re-provisioning after a real offboarding event.
- 03General availabilityOpen intake, gated on the completed data-protection assessment rather than on demand.
03Questions
Common questions
01What is actually built today?
The dashboard's server layer — schema, tenant isolation, audit, the message store, retrieval with citations, the metrics engine and the automation rules — is built and runs against a mock of the session service. The session service itself is a scaffold, and no screen is finished. The v1 scope is locked and the decision record is complete enough that the remaining work is execution rather than design.
02Do you have customers or revenue?
No. No pilots, no letters of intent and no revenue. First pilots are gated on a signed data-processing agreement and recorded employee consent per account, and we would rather hold that gate than book an early logo.
03Can a company really keep an account the employee registered?
The durable, deliverable guarantee is that the archive, contacts and relationship graph survive offboarding. Retaining the account itself is best-effort: whoever controls the phone number can contest it. We sell the part we can actually deliver, and say so in writing.
04Is this employee monitoring?
No, and the product is built to make that answer checkable. Consent is recorded per connected account, the employee has a standing screen showing what is collected, pausing or resuming collection is always disclosed, and the model refuses to assess people — enforced before retrieval runs, not requested in a prompt.
05What is the regulatory position?
Processing runs on a designed GDPR basis with a data-protection impact assessment in progress; it does not gate the first contracted pilots and is a hard gate on general availability. There are no security certifications today and we do not claim any. EU hosting is the design, with the exception that transactional email metadata sits with a US provider.
06How does it make money?
Per managed account, per month: $10 for the account, collection, archive, dashboard and analytics; $25 to attach an agent and deepen history; $50 for the largest limits and full history. Seats are not metered. Margin is designed to narrow as the tier rises so the expensive tiers carry their own cost.
07What is the biggest risk?
Unit economics on account provisioning, and the possibility that a data-protection finding forces a change to something already shipped. Both are written into the plan rather than discovered later, and the durable value — the archive and the graph — holds independently of how an account was created.
08Why is this defensible?
No incumbent owns the account-as-company-asset position, the wedge is a union of capabilities no adjacent tool covers, and the trust posture is a moat rather than a cost: the things we refuse to build are what make the product buyable by the customers who feel this pain most.
ACT 04The round
Talk to us about the round
We are raising a $5M seed at a $30M valuation. Tell us who you are and we will share the full data room, the decision record and a walkthrough of what is built.
Goes to the founders. No list, no newsletter.