A number produced without questions should be treated as a red flag rather than good service. A competent team returns clarifying questions before any number: swift development services about users and volumes. A supplier that quotes before understanding the scope is simply guessing, and that guess will be corrected later — at your expense.
Watch for a mismatch between the engineers on the sales call and the people who will code. Insist on the names and python development experts CVs of the actual team in house vs outsourced development team the statement of work, with a clause about substitutions. A vendor that will only describe abstract roles and will not commit to specific engineers is reserving its own flexibility at your cost.
Ask for commit-level visibility from day one. A partner that hands over a build only at the end of each phase is asking you to accept a black box. Daily commits reveal who is really on the project far better than a weekly report. The same applies to the build and deployment setup: if nothing runs automatically, promises about quality are unverifiable.
Vague phrasing around IP is never a formality. The document should state explicitly that all outputs produced under it belong to your business process automation company as they are paid for. Look too at the governing law and the payment schedule: a request for most of the money up front with no milestone tied to it takes away the only leverage you have.
Last, examine how they communicate. Confirm what overlap the teams will share each day, who is expected to answer day-to-day questions and on what response times. Four hours of overlap is normally sufficient; none at all turns each small question into a lost day. Unclear written communication in the sales phase will not improve under delivery pressure.