exclusive to Triage
composerID blog
Product & operations

Where a workforce request really starts

Workforce requests usually start before anyone opens a workforce system. Someone messages a manager, raises a ticket or asks a colleague for help. The important idea: make the decision before the destination system decides the shape of the request for you.

Blog

Nobody opens a vendor management system to ask for help. A workforce request starts as a message to a manager, a ticket, or a question to a colleague: can we get someone to sort out the reporting warehouse before the quarter closes? By the time that request reaches a formal system, it has usually already been forced into a shape: a requisition, a ticket category, a purchase request.

The idea behind Triage’s intake surfaces is to make the decision before the destination system decides the shape of the request for you.

Meeting the request where it starts

Triage asks its diagnostic questions in the places where requests already begin. In a chat tool, the questions arrive as ordinary messages with buttons; the requester answers without leaving the conversation, and once a question is answered it locks in place and the next appears. The requester never has to know which downstream system their request will eventually reach, because that is exactly what the questions are working out.

Where each surface stands

Being precise about status matters more than a long list of logos. Microsoft Teams is in beta with a design partner. Slack and Google Chat are on the roadmap: designed in detail, not live. ServiceNow is designed to host the same diagnostic as a portal widget, also on the roadmap. The conversations shown on the Where they are page are design mock-ups of these flows, not screenshots of live product.

Designed per platform, not copied across

One thing the design work taught us: the same question has to wear different clothes on each surface. A Teams card should look the way Teams cards look, with its bordered layout and its own controls. A Slack message is borderless, with the options sitting directly in the message stream. Google Chat follows Material design, where tapping an option is the answer. Nobody who uses these tools daily would believe a mock-up that drew the same card three times with different logos, so ours do not.

Then composer takes over

Once Triage has made the decision, composerID takes over the next job: publishing its reference into the systems involved. The requester who started in a conversation does not need to visit those systems to know the request is real. The reference is the thread connecting the message they sent to the records the business runs on.

Written with Claude. This post was drafted with Claude, Anthropic’s AI model, working from the composerID repository: the registry, the schemas, the reference sandbox and the vendor documentation it cites. Edited and published by the composerID team.

← How composerID fits with Triage todayResearch: system of engagement →