Summary

  • Alianza has acquired Skribby, adding meeting-bot and transcription technology for planned integration into Crux in the first quarter of 2027.
  • Existing Skribby documentation separates entering a meeting, starting a recording and finishing processing. Those distinctions matter more to downstream applications than a simple success label.

An acquisition at the meeting door

A meeting assistant can leave with a perfectly processed record of an imperfectly captured conversation. That is the operating problem behind Alianza's September 10 acquisition of Skribby. The deal adds a route into Microsoft Teams, Google Meet and Zoom to a company building AI services around communications networks. It does not make every conversation inside those platforms available to a buyer or its developers.

Alianza expects Skribby's functionality to enter Crux in the first quarter of 2027, before the platform's broader commercial availability in the first half. The separate Crux launch announcement, dated September 9 in its release text, describes a controlled-availability phase already under way. An acquired component and a generally available combined service are therefore different milestones. The purchase price is not disclosed.

The acquisition supplies more than another transcription model. Skribby manages meeting bots and offers a choice of transcription providers. Its integration can spare developers some meeting-specific infrastructure work. Alianza still has to show how that capability fits a platform organised around subscriber identity, call state, entitlements and policy.

Inside the room is not the same as recording it

Skribby's bot lifecycle documentation makes the distinction unusually concrete. A bot may be denied admission. In manual-start mode it may also be inside a meeting, supplying participant, chat and status context, while capturing no media and producing no transcription. If the recording-start instruction never arrives before the timeout, it leaves without a recording.

Even a finished task needs interpretation. The documented stopping reasons include a participant removing the bot, a manual stop and an interrupted breakout-room transition, as well as the meeting ending. Processing can finish normally on the material available without certifying that the bot heard the entire meeting.

For an application that turns speech into commitments, missing coverage changes the meaning of the output. A summary can preserve a proposal and miss the later withdrawal. That is an illustrative risk, not a reported Skribby failure. The useful acceptance question is how the captured interval and stopping reason compare with the conversation the customer intended to record. Technical admission alone should not be treated as proof of every required participant permission.

A result and its notification are different things

The webhook guide adds another boundary: Skribby makes one delivery attempt per event and does not automatically retry failed notifications. An application that misses a completion notice should not immediately classify the transcription itself as failed. Applications need a way to reconcile delivery state with the underlying bot record; this documentation does not establish how the future Crux integration will do that.

Nor does model choice settle data handling. Skribby's privacy guidance explicitly separates a transcription provider's processing and retention from Skribby's own recording and transcript retention. A no-training policy is not a claim that every layer stores nothing.

The new asset is a mechanism for participating in meetings. Its market value depends on whether developers can understand what was captured, why capture stopped and where usable results went. The announcement establishes an acquisition and an integration timetable, not measured gains in coverage or customer outcomes.