GoDravixA product byDigiWagon
Migration
Pricing
Book a demoSee the platform

In-app Copilot

Will answer "how do I do this here" from your manuals, on the screen you are on.

How it would work6 stages
Capability pipelineA staged pipeline showing how the capability moves from input to a proposal, with a named human approving before anything is committed.1Knowledge base buildThe role manuals, release notes, the platform'2Context captureWhen a question is asked, the Copilot will alrapproval gate3Retrieval and groundingRelevant manual passages and configuration val4Procedure walkthroughFor multi-step tasks the answer would be prese5EscalationWhen grounding fails, the Copilot will say it 6Gap reportingUnanswered questions and poorly rated answers
Nothing writes without a signature
AI proposes. A named human approves.Specified in detail, configured to your book

New staff learn a lending system by interrupting the one colleague who already knows it, and that colleague is usually the person with the least spare time. GoDravix ships a user manual per role with screenshots rather than one generic manual, which is better than most systems manage, and a manual is still read once during training and then forgotten at exactly the moment it is needed. In a system that moves money, procedural mistakes are not cosmetic: recomputing interest after a batch of back-dated repayments rather than between them produces wrong figures. The order sensitivity underneath that is a scheduled engine fix, and the interleaved recompute procedure is the interim operational answer until the fix lands.

How it works

The pipeline, stage by stage

Each stage names what goes in and what comes out, because a capability you cannot inspect is a capability you cannot audit.

  1. 01

    Knowledge base build

    The role manuals, release notes, the platform's configured policies and any standard operating procedures the lender supplies would be chunked, indexed and mapped to the screens and routes they describe.

  2. 02

    Context capture

    When a question is asked, the Copilot will already know the screen, the role, the record type in view and the deployment's configuration. The answer for someone on the disbursement screen is not the answer for a read-only reviewer on the ledger, and the design treats those as different questions.

  3. 03

    Retrieval and grounding

    Relevant manual passages and configuration values would be retrieved, and the answer composed only from what was retrieved, with the source manual and section named. Where retrieval returns nothing above the grounding threshold, that path is designed to end at step five rather than produce an answer anyway.

  4. 04

    Procedure walkthrough

    For multi-step tasks the answer would be presented as ordered steps tied to the actual screens and controls, including the ordering constraints that matter, such as the interleaved recompute procedure during a back-dated entry sequence.

  5. 05

    Escalation

    When grounding fails, the Copilot will say it does not have an answer and offer a support handoff carrying the question, the screen, the role and the deployment configuration. It will not compose a plausible procedure to fill the silence.

  6. 06

    Gap reporting

    Unanswered questions and poorly rated answers would become a documentation backlog, so the manuals improve at the points where users actually get stuck rather than where the writer expected them to.

Configuration

Shaped to your book, not shipped as one fixed version

These are the decisions you make and we build against. They are the reason two deployments of the same capability do not look alike.

  • Knowledge base contents

    Which of the six manuals apply, plus your own circulars, approval instructions and standard operating procedures layered on top of the standard set.

  • Deployment-specific procedures

    Where your process differs from the default, for example an internal rule that waivers above a threshold need a board reference before entry, the Copilot would answer with your rule rather than the generic one.

  • Languages

    Which languages officers ask in, with source sections named in their original language so a reviewer can always check the citation.

  • Record access policy

    Whether the Copilot may reference the user's own records to make an explanation concrete, or explain the screen only without reading data.

  • Escalation destination and hours

    Where a handoff goes, in what hours, and what context is attached to it.

  • Grounding threshold

    How confident retrieval must be before the Copilot answers rather than hands off, which decides how often your officers get an answer and how often they get a ticket.

What you supply

Inputs

  • Your standard operating procedures, circulars and approval instructions, which layer over the role manuals that ship with the platform
  • your support macros and known-issue notes
What you get

Outputs

ArtefactFormat
In-context answer with the named manual section and versionIn-app
Step-by-step procedure card tied to screens and controlsIn-app, printable PDF
Support handoff ticket with question, screen, role and configuration attachedTicket
Documentation gap report: unanswered and poorly rated questionsExcel
Adoption report by role, screen and question themePDF
Who does what

The duties this creates

Duties, not job titles. Each one below is a permission you grant, so you map them onto the roles you already have. Preparing, approving and configuring are separate by design, which is how you stop one person holding two of them.

  • Using it

    Anyone with a login, including the borrower. Answers are grounded in the documentation for that person's permissions and scoped to the data they can already see, so the Copilot never becomes a way around access control.

  • Configuring

    Decides which documentation each permission level draws on, and what the Copilot declines to answer.

  • Reviewing after the fact

    Reads the question log, which is the fastest signal of where the product or the training is confusing people.

Failure modes

What it will do when the data fights back

Any vendor can describe the happy path. These are the cases that decide whether a capability is safe to put near a loan balance. Designed behaviour in each case:

A question about a capability that is switched off in this deployment

It would state that the feature is not enabled in this deployment and name who to ask internally, rather than describing a screen the user does not have. Describing an unavailable feature is the fastest way to lose a user's trust in a help system.

A question that is really a financial question

"What is the balance on this loan" is not a help question. The Copilot would route to the record or the report that holds the figure and decline to state the number. It explains the system; it does not quote balances.

The manual is out of date after a release

Every answer would carry the manual version and the release date it was written against. Where the deployment is on a later release, a staleness note would appear with the answer, and the gap would go into the documentation backlog automatically.

"How do I fix this" asked against a live, part-completed record

The procedure would be given and would stop at the approval step, because the Copilot cannot act and should not imply that it can. Where the fix involves a correcting entry, it would say so and name the role authorised to make it.

A question in a language the knowledge base is not maintained in

It would answer in the asked language but name the source section in the original, so a supervisor or auditor can verify the citation against the document that actually exists.

Sequencing

Why it sits where it does

A second-wave build, the capability that starts from documentation that already exists. The knowledge base is already written. A manual per role ships with the platform, so this capability starts from documentation that exists rather than documentation that has to be commissioned first. It is the second wave rather than the first wave only because that work changes some of the procedures it would document.

Dependencies

What has to exist first

  • A maintained help centre, so the manuals stay a living knowledge base rather than a set of files
  • the deployment configuration model, so answers reflect what is switched on
  • a screen and route map
  • a named documentation owner, because a help system with an unmaintained knowledge base decays faster than no help system. Already in place: the role-based user manuals
Questions

What buyers actually ask about this

Only if you allow it, and it would be a configuration switch. The default is designed to explain screens, fields and procedures from the manuals without reading records. A lender that wants concrete answers referencing the record in view will be able to enable that, scoped by the same role and zone rules that govern the screen itself.

Two options, and you pick at deployment. Either the language component runs inside your boundary, in which case no question text leaves it, or it calls a hosted model, in which case the question text and the retrieved manual passage leave and your loan data does not. Because the Copilot answers from documentation rather than from records, the second option is open to lenders who would refuse it everywhere else.

Grounding. Answers would be composed only from retrieved manual passages and configuration values, and every answer would name its source section. When retrieval finds nothing above the threshold, it will say it does not know and offer a support handoff carrying the context. A confident wrong procedure in a money system is worse than a handoff, so the design prefers the handoff.

The same person and the same approval chain as any other action in the system, because the Copilot will not be able to act. Every financial step still passes through maker-checker with a named approver. What we commit to is that answers will be grounded in your documentation, cite their source, and stop at the approval boundary rather than implying the system will finish the job.

Both. Your circulars and standard operating procedures would be layered over the standard manuals so the Copilot would answer with your rule where yours differs. It would be enabled per role, so a borrower gets help on its own read-only screens while internal roles get the full procedural set, or switched off for a role entirely.

They would stay in your deployment for the retention period you set. The log would be useful to you as a training signal, showing which screens generate the most confusion. The same isolation applies here, and the security page sets out the detail. Where a gap points at our documentation rather than yours, we would ask before using it to improve the shared manuals.

The rest of the layer

Other capabilities

Next step

Shape this one around your book

Bring your document formats, your languages and your thresholds. We will show you what this looks like against your own data.

45 minutes | On the live deployment | A straight answer on sequence