Team Collaboration

How to Use Team Collaboration Features in Openkoda PAS

Follow one hand-over end to end: a chat message carrying the policy, a task with an owner and a due date, and the notification that reaches the assignee.

Why Collaboration Belongs Inside the Policy System

Insurance work is handed between people constantly. An underwriter needs a second opinion, a claims handler needs a surveyor booked, somebody has to reprice a mid-term change before the customer rings back.

Almost none of that happens in the policy administration system. It happens in a chat app, in email, or by leaning across a desk, and the record never hears about any of it.

The cost is not the chatting. It is that the context lives somewhere the record cannot reach. Six months later the policy shows what was done and none of why, and the conversation that explains it is in a channel nobody can search any more.

Collaboration built into the system is three things, and they are worth keeping separate:

  • A conversation that can attach the record it is about. Not a policy number typed into a message, but a link the reader can click.
  • A commitment. A task with an owner, a due date and a typed link to the record, so work is queryable per record rather than remembered.
  • A notification that finds the person, so nobody has to chase and nobody has to watch.

The thread running through all three is that same link. A message that points at a policy, a task attached to a claim, a notification that opens the work. That is the difference between a chat app that happens to sit beside your system and collaboration that is part of it.

Before you start, you will need: two accounts in the same organization, so you can see both sides of a hand-over. The walkthrough below follows one: an administrator asks a colleague to price a mid-term endorsement, and the colleague finishes it.

There is a video version too, if you would rather watch than read. It runs under four minutes; the written steps below are the ones worth having open while you try it.

Team Collaboration in Openkoda PAS: Chat, Tasks and Notifications

Step 1 - Open the Channel That Follows You Around

A bubble sits in the corner of every page. Behind it is the organization’s team channel: one conversation, shared by everyone signed in.

The team chat panel open over a policy list, showing three messages from colleagues with reaction buttons and a composer
One channel for the organization, docked to the corner of whatever page you are on - the conversation sits next to the work rather than in another app.

The panel following you from page to page is the whole point: you do not leave the record to ask about the record.

Step 2 - Mention the Person You Need

Typing an at-sign brings up your colleagues.

The mention menu open in the chat composer, listing everyone and each colleague with their handle
An at-sign brings up your colleagues - or everyone, when the whole team needs to see it. The person you pick gets pinged.

A mention is not decoration. It is the difference between a message in a channel and a message somebody is told about. Use @all sparingly for the same reason you always have: a channel where everything is urgent is a channel people mute.

Step 3 - Attach the Record You Mean

The link button searches your actual records: submissions, quotes, policies, products.

The record search in the chat composer, with a record type selector and a search box
The link button searches your actual records - submissions, quotes, policies, products - so the message can point at one instead of describing it.

This is the habit worth enforcing on your team. “Can you look at POL-OK-HOME-5FBCB263” makes the reader search; a message carrying the policy makes them one click from it. The difference is small per message and enormous per week.

The sent message carrying a mention and a policy chip underneath it
Sent: a question, the colleague it is for, and the policy it is about - as a link anyone can click, not a number to copy.

Step 4 - What the Other Person Sees

In the colleague’s window the same message arrives, highlighted because she was named, and the chip takes her to the record.

The same conversation in the mentioned colleague's window, highlighted, with the policy open behind it and a reaction picker under the message
In Eva's window the message is highlighted because she was named, the policy chip took her straight to the record - and a reaction tells the sender she has picked it up.

The reaction is worth noticing as a piece of protocol rather than a toy. “Seen, mine, working on it” is most of what a hand-over needs, and a reaction says it without another message for everyone else to read. Anyone can react; your own messages you can edit or delete, and the channel says so rather than quietly rewriting history.

Step 5 - A Conversation Is Not a Commitment

Chat is where things get agreed and also where they get forgotten. A task is the commitment: an owner, a priority, a due date, a record.

The tasks list with priority, status, due date, assignee and linked record columns, filtered by scope and status
Tasks are the commitment a conversation is not: an owner, a priority, a due date and the record each one is about.

The sidebar carries a live count of what is open and turns red when something is overdue, and the same list can sit on a dashboard of your own. The filters are the three questions a team lead actually asks: what is mine, what have I handed out, what is everything.

Step 6 - Write the Task Down

The new task form with a title, a description, an assignee, a priority, a status, a due date and a linked-record search
What you would expect - title, detail, owner, urgency, due date - and the same record search again, so the task is linked to the policy rather than mentioning it.

Write the description as the instruction you would give aloud: what to confirm, what to change, and what to come back with. “Reprice the endorsement” is a label. “Confirm the sum insured, reprice the remaining term and come back with the additional premium” is a task somebody can finish without asking you a question first.

The created task showing its assignee, who raised it, the due date, the policy it is linked to and a comment box
The finished task: who owns it, who asked, when it is due, which policy it belongs to - and a place to answer it.

Step 7 - Or Start From the Record

The other direction works too: every claim, policy and submission carries its own task list.

The add-a-task dialog opened from a claim, already stating which claim it is linked to
Every claim, policy and submission carries its own task list - and raising one there fills the link in for you, because the system already knows what you are looking at.

Prefer this route when you are already on the record. The link is filled in for you, and a link filled in by the system is one that cannot point at the wrong policy.

Step 8 - The Assignee Is Told

Assigning a task writes the person an in-app notification. They did not have to be watching.

The notification dropdown in the assignee's window listing the two tasks just assigned to her, each with its detail and a link
Eva did not have to be watching. Assigning writes her an in-app notification, with the task's own words in it and a link straight to the work.

The notification carries the task’s own description, not just its title. That is enough to judge whether to open it now or after lunch, which is the difference between a notification and an interruption.

Step 9 - What Else the Bell Carries

Assignments are one source among several.

The full notification history listing task assignments, payments received and messages, each typed and timestamped
Assignments are one source among several: referrals, claim assignments, payments, overdue invoices and workflow milestones all arrive in the same place.

And workflows write to it themselves, which is the part that changes how a team runs.

A claim workflow whose steps create a task and send an in-app notification rather than an email
And workflows write to it themselves: this one raises a task when a claim is reported, and its message step is set to notify in-app rather than email.

Two steps in that workflow are worth pointing at. Create task means a claim arriving raises the triage work by itself, assigned and prioritized, with nobody reading a queue to notice it. And the Send message step’s channel is set to in-app notification rather than email, so the same step that emails a customer can instead put a line on a colleague’s bell. Chasing becomes something the system does.

Step 10 - Answer on the Task, Not in a Thread

The colleague picks it up from her own list, does the work, and answers on the task.

The assignee's comment on the task, recording the repriced premium and what happens next
The answer goes on the task itself - so the question, the answer and the record stay together for whoever reads this in six months.

This is the step teams skip, and it is the one that pays. The answer belongs where the question is, attached to the policy it concerns, not in a chat thread that will be unsearchable by the time anybody needs it.

The task list with the endorsement task now marked done
Then she marks it done, and it drops out of everybody's open count.

None of this is a chat app, a to-do list or a notification centre competing with the good ones you already have. It is the same three primitives with one property those cannot have: everything points at a record.

That property is what makes the history worth reading later. The message names the policy, the task hangs off it, the notification opens it, and the answer is filed against it, so the question “why did we reprice this mid-term, and who said so?” has an answer on the record itself rather than in somebody’s memory of a conversation.

See Openkoda in your context

Book a live, personalized demo with our product team - tell us your use case and see the platform work with your data. No commitment.