Your client's assistant has been answering on their website for a few months and it works. Now they want it on Telegram as well, because some of their customers live there, and they have asked you for a quote by Friday.
The part that answers questions should not change at all. The lookups, the rules about what it may and may not say, the way it refuses and hands over to a person: all of that should be shared, untouched, by every channel. What changes is everything at the edge, where the channel hands you a message and takes back a reply, and that edge is consistently larger than it looks in the first afternoon. We would quote the shared core as zero work and the edge as real work, and we would be specific with the client about why the second number is not small.
Why the core stays put
If the assistant's knowledge and rules live in one place, a second channel is a second door into the same room. That is worth checking before you quote. Some builds have the website version's behaviour partly baked into the website code: a greeting written into the widget, a menu of buttons that does half the routing, a prompt that assumes the reply will be shown as formatted text. Each of those has to be pulled back into the shared core first, or you end up keeping two assistants in step by hand. If you find this, it is the real cost of the job, and the client should hear it as such rather than discovering it later as two slightly different answers to the same question.
What changes at the edge
The first thing that changes is what comes in. A website chat box mostly receives typed text. A messaging app receives whatever people send to friends: photos, screenshots, a PDF of a referral letter, a photo sent as a file so it arrives uncompressed, five images in a row with no text, a voice note. Each of those needs a decision. Some can be read and answered, some should be acknowledged and passed to a person, and some are too big to send to the model at all. When we added a second channel to an assistant we run, most of the first week went here: an image sent as a document had to be treated like a photo, a burst of images had to stop overflowing the request to the model, and a request refused for being too large had to be retried without its attachments instead of failing silently.
Files also have a lifetime you do not control. Telegram's own Bot API documentation says a bot can download files of up to 20MB, and that the download link is only guaranteed for at least an hour, after which you have to ask for a new one. If staff open a conversation the next morning to see what the customer sent, the attachment has to come from your own store, or be fetched again. That is a small piece of plumbing, but nobody writes it until a receptionist clicks on a broken image.
The second thing is what goes out. Every channel has its own ceiling on message length (Telegram's is 4,096 characters per message), its own formatting rules, and its own way of showing a link. A reply that reads well as a formatted card on a website can arrive as a wall of asterisks on a phone. Long answers need splitting at sensible places, and anything that depended on a button needs a plain-text equivalent.
The third thing is who the person is and when you are allowed to talk to them. On WhatsApp you know the customer's phone number, and Meta limits free-form replies to a window after the customer last wrote, with approved templates outside it. On Telegram you may only have a username, the rules on who can start a conversation are different, and there is no phone number unless the customer chooses to share one. If the assistant's booking or follow-up steps assume a phone number, they will quietly break. If staff sometimes move a conversation from one channel to another, the assistant has to say so to the customer, plainly, so nobody wonders why the reply turned up somewhere else.
What to do first, and what to leave
Start by sending the new channel the twenty messages that caused the most trouble on the existing one, then add the things only a messaging app produces: an unreadable photo, a forwarded message, a long voice note, three attachments at once. Read every reply as the customer would see it on a phone. That afternoon tells you more about the size of the job than any specification.
Check, early, how the new channel fails. Every messaging platform will at some point tell you to slow down or wait, sometimes for minutes. Decide what the assistant does then: retry with a cap, queue the reply, or tell staff. A failure that is retried forever is as bad as one that is swallowed.
Leave channel-specific features for later. Inline buttons, stickers and rich cards are tempting in the demo and they are where the two channels start to drift apart. Get plain text right on both first.
Questions to ask before you quote
- Does any of the current assistant's behaviour live in the website code rather than the shared core?
- What does the client's team need to see when a customer sends a photo, and for how long?
- What identifies a customer on the new channel, and which steps currently assume a phone number?
- What happens when the platform asks you to wait, or a reply fails to send?
- Who on the client's side reads conversations from the new channel in the first month, and where?
- Whose account owns the bot or number on the new channel, and who can rotate its credentials if someone leaves?
The honest limitation
Testing before launch will catch the obvious cases and miss the ones customers invent. People will use a new channel differently from the old one, and you will only learn how by reading the conversations once it is live. We would put a few hours a week of reading into the first month of the quote as a named line, with someone on the client's side who can say whether an answer was right. If the client pushes back on that line, it is worth asking who they expect to notice when the assistant gets something wrong on a channel nobody on their team uses themselves.
Keeping a clinic's AI assistant answering correctly on every channel it runs on is what we do, for clinics directly and for agencies who would rather not own that job. If you are scoping a second channel, talk to us.