From workbook to configured system.
Here is how Votis runs an implementation: what your consultant sets out, what your customer sees, what you sign off, and what leaves.
Your consultant sets it out once.
One specification for each system you implement. It holds what a good implementation of that system has to settle, in what order, and why. Every customer you put on that system runs from it, and what leaves at the end is exact to that system. Nobody writes questions: the agent composes the asking from what you set out.
Drop the workbook.
Upload the one you already use. Votis reads it and sorts what it finds into areas: 741 columns, 22 lists and 318 choices in the Harbourline example, 183 of them not yet placed. You rename, retype and drop what you don’t need.
The reasons, drawn.
Anything that waits on something else carries a sentence you wrote. When the agent explains to your customer why it is asking, or why it is waiting, it says that sentence. Six units of the finance specification, every link between them drawn, and the four sentences behind them.
When it isn’t sure.
The first thing an implementation lead asks is what happens when the agent gets something wrong. Here is what it does instead of guessing.
A decision the agent writes is not agreed until a person confirms it. It is shown as proposed, with who proposed it and why, and it stays in that state, visibly, until someone says yes. It never quietly counts as settled.
A row it cannot place is held, and named. It says which row and what stopped it, and the row waits there until a person deals with it. Nothing is guessed into a gap.
Something with no name yet cannot be pointed at. When a table would need it, the agent says which row is missing its name and asks for it, rather than drawing a row of blanks.
A structure that loops, or goes deeper than your consultant allowed, or has a row whose parent is gone, is refused, and the refusal says which rows. “Operations sits under Logistics, which sits under Operations” is a sentence, not an error code.
A document your customer sends has an outcome, and the outcome is recorded: it was applied, it added nothing, or it could not be read. A file never just disappears.
Nothing goes near the target system until a person signs it off. What the customer ruled out is recorded as ruled out, with the reason they gave, and that record is in front of the person who signs.
What leaves.
Once signed off, the configuration goes out in the format the target system expects, because the specification was written for that system in the first place. The same configuration as a file or straight in by API, byte for byte. Load it, or let Votis push it in.
See it on your own setup.
A 20-minute call. Bring the workbook you use today and we’ll show you what Votis reads from it.
See it on your setup