Added the Interaction API, which includes multiple endpoints that allow an interfacing application to interact with an existing claim.
Benefits of using this Addon
Clients who already use an internal CRM for managing disputes can leverage this API to improve their user experience and add functionality.
What does it replace?
This solution does not necessarily replace anything. It is truly an addon.
What phase is this recommended in?
Since this solution is targeted at non-QFD customers, it can be implemented at any time.
How long from phase kickoff can this be implemented?
This is almost entirely dependent on the client. The endpoints within the API are all clearly defined, so it is up to the client and its available resources to code to them.
Who is responsible for what to implement this addon? What information is required to implement this addon?
Quavo Responsibilities |
|
---|---|
Client Responsibilities |
|
Third Party Responsibilities |
What does a timeline look like for implementing this addon?
Weeks to completion/Responsibility mapping | |||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Party | Kickoff | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 |
Quavo | 1, 2 | 2 | 2 | 2 | 2 | 3 | 3 | 3 | 3 | ||||
Client | 1 | 1 2 3 | 1 2 3 | 1 2 3 | 1 2 3 |
How is pricing determined?
Metric | Description |
---|---|
API Call | A fee is assessed for each call to the API |
What success criteria should be met prior to going live?
Content generated should mirror all changes requested to the letter package. For each letter changed, generate a sample and test that the appropriate updates were made.
Any best practices for implementation or things to know after going live?
Many clients have difficulty obtaining the necessary approvals to updated content in a timely manner. Begin this effort very early in the process.