Best Tarief Office
Nine energy and telecom providers, one form.
A contract platform for a Belgian broker: one intake, nine providers' real PDF forms filled, signed with eID and pushed into the CRM.
Visit the site- providers integrated
- 9 providers integrated
- languages, end to end
- 3 languages, end to end
- signing and identity
- eID signing and identity
- Role
- Architecture, build, maintenance
- Period
- 2022 — now
- Stack
- Laravel 10 Vue 3 Horizon PDFtk AWS S3 amoCRM Mailgun
The problem
A broker switching a household's energy and telecom fills in the same customer details on nine different providers' forms, each with its own layout, its own fields and its own idea of what a connection request looks like. Done by hand it is an afternoon per customer and a typo per form. The forms themselves are not negotiable — they are the providers' own PDFs, and they have to come out the other end looking exactly as the provider expects.
How it works
One intake collects the customer once. Each provider is a contract class that knows how to map that customer onto its own PDF field names, and the filled documents are merged into a single packet to sign. Signing happens with the customer's eID; the signed packet is archived to S3, mailed out, and the whole thing is mirrored into amoCRM so the sales side sees it without anybody re-keying it.
What is in it
Nine providers, one intake
Engie, Luminus, Eneco, Mega, Octa+, Proximus, Telenet, Scarlet and Orange, plus energy transfers and connection requests. Each is a class with its own field map, so adding the tenth is a class rather than a rewrite.
Real provider PDFs, filled
The output is the provider's own form with its own fields populated — via PDFtk, not a lookalike regenerated in HTML. A provider that will only accept its own document gets its own document.
eID signing and archiving
Identity from the Belgian eID, signatures through the signing provider, and the completed packet stored on S3 with a scheduled job that removes the working files afterwards.
Three languages, one customer record
Dutch, French and English throughout, with translatable content on the models. In Belgium that is not a nice-to-have — a Walloon customer signs a French contract.
CRM without re-keying
amoCRM integration in both directions, so a contract created in the platform is a deal in the CRM and the sales team never types an address twice.
Queued, watched and resendable
PDF generation, merging and mail all run through Horizon-managed queues. A batch send is a job, a failed send is visible, and re-sending is a button rather than an afternoon.
A decision worth explaining
Every provider is its own model and its own field map, even where two forms look nearly identical. The temptation is one generic contract with a configuration table, and it survives exactly until a provider renames a field mid-year for one product only. Duplication that maps to a real external boundary is not duplication worth removing.
Something like this on your list?
The projects differ, the way of working does not. Tell me what you are trying to solve.
Taking on new work