From intent to specification
Business analysis for iGaming delivery
Most of what gets called a development problem in this industry starts as an unanswered question: what counts as a qualifying deposit, which products contribute what to wagering, what a support agent may override, what the regulator expects in the monthly return. Argon turns those into specifications your engineers can build from and your compliance team can point at later.
01
Where teams get stuck
- Every sprint starts with an argument
- Tickets that describe a screen rather than a rule force engineers to invent business logic, and the invention is only discovered when finance queries a number.
- The rules live in people
- Bonus mechanics, risk thresholds and payment routing exist as institutional memory. Nobody can safely change them and nobody can onboard into them.
- Reporting numbers do not agree
- Two dashboards, three definitions of an active player, and a GGR figure that depends on who ran the query. Almost always a definition problem, not a data problem.
iGaming consideration
Contribution percentages, qualifying bets, expiry, capping and stacking need defining to the decimal. Every gap is either a player complaint or a promotional loss.
02
What we do
- Stakeholder discovery
- Structured sessions with commercial, operations, risk, compliance, finance and support, surfacing the contradictions between them early rather than in acceptance testing.
- Process mapping
- How the work is really done today, including the spreadsheet and the manual step everyone forgot to mention, before anyone designs how it should be done.
- Requirements and specifications
- User stories with acceptance criteria, rule tables, state machines and edge cases. Written so an engineer can build without guessing and a tester can verify without asking.
- Integration specifications
- Supplier protocols mapped to your domain: field-level contracts, error and retry semantics, reconciliation expectations and what happens when the other side is wrong.
- Data and reporting definitions
- One agreed definition per metric, written down, with the source and the calculation. GGR, NGR, active player, bonus cost, first deposit, churn, all of them.
- Compliance requirement mapping
- Licence conditions and regulatory obligations translated into system requirements, each traceable to the control that satisfies it.
- Backlog shaping
- Requirements sliced into increments that deliver value in order, sequenced against dependencies and sized with the engineers who will build them.
- Change and impact analysis
- Before a rule changes, what it touches: existing campaigns, historical data, reports, live player entitlements and the automation that already depends on it.
03
What you receive
- Requirements documentation and a groomed, estimated backlog
- Process maps for current and target state
- Business rule tables and decision matrices for bonusing, risk and payments
- Data dictionary with one agreed definition and calculation per metric
- Integration specifications per supplier, field by field
- Traceability matrix from regulatory or commercial requirement to implemented control
04
How the work runs
01
Frame the problem
What decision or outcome this work serves. Requirements gathered without that frame expand without limit.
02
Discover
Interviews, existing documentation, the actual data and the actual code, because the code is the only unambiguous record of current behaviour.
03
Model
Processes, rules, states and data written down and played back to stakeholders until the contradictions are resolved on paper.
04
Specify
Stories, acceptance criteria and rule tables, reviewed with engineering and QA before they enter a sprint.
05
Support delivery
Available through the build to answer questions, adjudicate edge cases and keep the specification current as reality lands.
06
Verify
Acceptance against the criteria, and a documentation set that reflects what shipped rather than what was planned.
05
Why iGaming differs
- Bonus rules are the most expensive ambiguity
- Contribution percentages, qualifying bets, expiry, capping and stacking need defining to the decimal. Every gap is either a player complaint or a promotional loss.
- Regulatory reporting is a requirement, not a report
- If the monthly return needs a field the platform never captured, no amount of query work will produce it. Reporting obligations belong in the specification.
- Support and risk need documented authority
- What an agent can adjust, who approves what, and what gets logged. Undocumented authority is both an internal fraud risk and an audit finding waiting to happen.
06
Tools and methods
- Modelling
- BPMN · state machines · decision tables · C4 context
- Tools
- Jira · Confluence · Miro · Figma · Notion
- Data
- SQL · MongoDB aggregation · metric dictionaries
- Typical team
- Senior business analyst, domain specialist as needed
07
Questions
We are agile. Do we need documentation?
You need decisions recorded. Agile removes the hundred-page up-front specification, not the need for an unambiguous rule when money moves. We write the minimum that keeps the team from re-deciding the same question.
Can a business analyst work without a developer engagement?
Yes, and it is often the highest-value first step. A well-specified backlog makes any development team faster, including one you already employ.
Do you write the regulatory documentation?
We produce the technical and process documentation that supports it, and map obligations to controls. The legal and licence submissions themselves belong with your compliance function or your legal advisor.
How do you handle stakeholders who disagree?
Write both positions down, make the cost and the risk of each explicit, and escalate to a named decision maker with a deadline. Unresolved disagreement does not disappear, it just surfaces later in a defect.
Related
- Engagements
- Under NDA as standard
- People
- Background-checked engineers
- Data
- GDPR and DPA ready
- Infrastructure
- World-renowned cloud providers
Next step
Tell us what you are building, or what you are about to buy.
One working day to a reply, from an engineer rather than an account manager. Under NDA as standard, before anything is shared.