Kinesis and contact trace records

Confirm before relying. Quotas, prices, and names change.

Kinesis is how the ecosystem listens

Agent events and contact trace records can go to Kinesis Data Streams or Firehose. Streams let several consumers read. Firehose is the buffered path to S3. One quiet five-minute stretch is the documented moment to look at delivery errors.

A single shard is a common starting size for agent events and a common cause of lag once WFM and a custom dashboard both read it.

• CTRs are near real time, not instant, and consumers must tolerate duplicates.
• Only one Firehose is the default CTR delivery. Fan out by consuming a stream.
• Join on ContactId. There is no other honest key.
• Agent events are the adherence feed. Historical reports are not.

Source: re:Post, integrate Kinesis

Read a CTR before you build a dashboard

Fields you should be able to point at: ContactId, Channel, InitiationMethod, the endpoints, queue duration, the agent timestamps, ACW, disconnect reason, attributes, and the recording location. Transfers create another contact. PreviousContactId and NextContactId are the chain.

Delivery to Firehose or a stream is near real time and can duplicate. Consumers must be idempotent. Five minutes of silence is when you check the error prefix.

• DisconnectReason is the first field when someone says the carrier dropped the call.
• Attributes are whatever you wrote. They are not infinite.
• A missing Recording.Location means recording was off or the write failed.
• Do not average a day from real-time screenshots.

Source: re:Post, Kinesis