Frequently asked questions
The questions teams actually ask ✱
Straight answers about process documentation, automation readiness, and how the service works — including what it can’t do yet.
01 — PDD & SDD basics
What is a Process Design Document (PDD)?
A PDD describes, in full detail, how a business process works today: every step, the systems and screens involved, the business rules, the exceptions, and who does what. In automation projects it is the source of truth the developers build from. Some teams call it a process definition document — the market uses both names for the same thing.
What is the difference between a PDD and an SDD?
The PDD describes the process as it exists — the business view. The SDD (solution design document) describes how the automation will be built — the technical view: architecture, queues, exception handling, credentials, logging. The PDD comes first and is approved by the business; the SDD is written on top of the approved PDD.
Who writes the PDD, and who writes the SDD?
Traditionally, a business analyst writes the PDD by interviewing the people who do the work, and a solution architect or senior developer writes the SDD. In practice both roles are expensive and busy, which is why documentation is so often the bottleneck — and why we built a service around it.
What sections should a PDD contain?
A complete PDD covers: process overview and scope, the as-is step-by-step description, applications and screens used, business rules, exceptions and how they’re handled, input and output data, volumes and frequency, and roles involved. Ours adds something most templates skip: every claim the evidence couldn’t support is flagged in the text and turned into a numbered question.
How long does it take to create a PDD?
The traditional way — workshops and interviews — usually takes one to three weeks of a business analyst’s time per process, and the documents commonly run past 50 pages. We work from a recording instead of workshops: your expert records the process once, you review the drafts we send back, and one question session closes the gaps — instead of your senior people sitting through interview rounds.
Can you automate a process that isn’t documented?
You can try, and many teams do — the developer effectively becomes the analyst, discovering the process by trial and error inside the sprint. It works, but it’s the most expensive possible way to write a PDD. Documenting first is cheaper because discoveries happen on paper, not in code.
Why do RPA projects fail without proper documentation?
Because the robot does exactly what the spec says, including the parts the spec got wrong. Undocumented exceptions become production incidents, unstated business rules become rework, and knowledge trapped in one employee’s head becomes a single point of failure. Most post-mortems of stalled RPA projects trace back to gaps between how management thought the process ran and what actually happens on the front line.
How do you document exceptions and business rules?
From evidence, not from memory. Screen recordings show what really happens, including the workarounds people forget to mention in interviews. Every rule and exception in our documents traces to something visible in the source material — and where the recording shows a decision but not the rule behind it, that becomes a numbered question for your team instead of a guess.
02 — Automation readiness
Which processes are good candidates for RPA?
The consensus criteria: repetitive, rule-based, high enough in volume to matter, stable application screens, structured inputs, clear decision rules, low exception rates, and an accountable owner. A process doesn’t need all eight — but each missing one raises the cost and risk of automating it.
How do I know if a process is ready for automation?
Readiness has two sides that get confused: whether the process is suitable for automation (stable, rule-based, worthwhile volume) and whether it’s known well enough to automate (documented, owned, exceptions understood). A process can score high on one and fail on the other. An honest assessment measures both before anyone writes code.
Should we fix the process before automating it?
Sometimes. The three honest outcomes of looking closely at a process are: automate as-is, fix first, or choose a different approach entirely. Automating a broken process just produces mistakes faster. A good process document makes this call easy, because the waste and workarounds become visible on paper.
Why do RPA projects stall or underperform?
Industry analyses regularly attribute the majority of stalled RPA projects to poor preparation: processes chosen badly, documented badly, or both. The pattern is consistent — the failure is rarely in the robot technology and usually in what the robot was told to do.
Is RPA worth it for a small or medium company?
Often yes, with one caveat: smaller companies feel documentation gaps harder because there’s no army of analysts to absorb the rework. The economics work when the process is chosen well. It’s much cheaper to find out a process isn’t worth automating before the project starts — and a proper process document is how you find out.
What does process documentation cost?
Less than the alternative. The real comparison isn’t a fee versus zero — it’s a fee versus one to two consultant-days of workshop and drafting per process, plus the rework when the informal version turns out wrong. We agree the price per engagement, based on what you are documenting and how many processes are waiting. Ask us where things stand.
03 — The service & working with us
What do I need to start?
One thing is required: a screen or workshop recording of the process, made by the person who does the work. Two things are optional and make the result stronger: screenshots of the key screens, and plain-text supporting files (old documents, exports, notes). No access to your systems is needed — ever.
Is it fully automated, or does someone review it?
Review is the model, not a workaround. You receive each draft for review — you correct steps, add context, and answer the open questions before we move on. Our pipeline does the drafting; you stay the authority on what’s true. No output goes into a deliverable unseen.
What if the recording doesn’t show everything?
Then the document says so. Unverified claims are flagged in the text. Narrated moments with no matching screenshot are listed with their exact timestamp. What can’t be verified becomes a numbered question in the Gap & Question sheet — sorted into what a screenshot can resolve and what needs a decision from the process owner or SME. What never happens: a gap silently filled with plausible fiction.
What languages does it work in?
Recordings may be in any major European language. Deliverables are produced in English.
Which automation platforms does the SDD cover?
The Solution Design Document is written for your target platform: UiPath REFramework, Power Automate (cloud and desktop), or Blue Prism. Haven’t decided yet? Tell us — we handle it as undecided.
Is our data safe?
Before anything runs, you confirm that real data is masked. The masking list is concrete: names of people · personal identifiers (emails, phones, staff or customer numbers) · bank and payment details (IBANs, cards) · visible or spoken login credentials · special-category data (health, religion, ethnicity, trade-union membership, politics, sexual orientation) — which may not be processed at all. Processing runs on EU-based infrastructure, and we never connect to your systems.
How long do you keep our data?
Until you tell us to delete it — that’s the whole policy. Deletion is real: ask us and we delete, per process or everything we hold for you. What survives a deletion is narrow and stated plainly: the accounting records we are legally required to keep. The privacy notice spells it out.
Why not just do this with a chatbot ourselves?
You can, and for a rough first sketch it’s fine. The problem is that general chatbots are built to always produce a complete-looking answer, so gaps get filled with invented details that read as facts. Finding those inventions afterward costs more than writing the document properly would have. Our pipeline is built around the opposite rule: unclear input becomes a question for you, never a guess in the document.
What can’t it do yet?
An honest list, so you don’t discover it later: no video-link intake (you send the file itself) · no automatic frame extraction from video (where a moment needs a screenshot, we ask you for one against the flagged timestamp) · deliverables come in our document format — producing them in your own client template is not available yet. “Yet” means exactly that — not promised, not dated, just not available now.
What does it cost, and how do I start?
You can start now. Write to info@ballastprotocol.com or use the form on the product page — tell us what process you are working on, what files you have, and what you need the final documents for. Price is agreed per engagement before any work begins.
Didn’t find your question?
Send it over: info@ballastprotocol.com. If it’s a good one, it ends up on this page.